Конвертировать MFC Doc / View в? - PullRequest
3 голосов
/ 20 марта 2010

Мой вопрос будет сложно сформулировать, но для начала:

У меня есть приложение MFC SDI, над которым я работал довольно долго, и казалось, что оно никогда не подходило для архитектуры Doc / View. То есть в доке нет ничего полезного Он многопоточный, и мне нужно больше работать с потоками и т. Д.

Я мечтаю также перенести его на Linux X Windows, но пока ничего не знаю об этой среде программирования. Может быть, Mac тоже.

Мой вопрос: куда идти?

Я думаю, что хотел бы перейти с MFC Doc / View на простой Win Win API с циклами сообщений, оконными процедурами и т. Д. Но эта задача кажется огромной.

Использует ли среда Linux X Windows аналогичный тип цикла сообщений, архитектуру оконных процедур?

Могу ли я пойти частично? Как конвертировать немного за раз, не делая мою программу непригодной для длительной работы?


Добавлено позже:

Моя программа - это программа сравнения файлов (звучит достаточно просто.) Итак, говоря о моей путанице простым способом, обычно документ может иметь несколько представлений, но в этом приложении у меня одно представление с несколькими (двумя) документами ( файлы). У меня есть «механизм сравнения», который я впервые написал в дни DOS, это сердце программы, и представление просто смотрит на результаты этой процедуры. Иногда я думаю, что часть моего кода «представления» может иметь смысл в классе «документа», но я не знаю, с чего начать разделять его на несколько классов. Я недавно начал читать "Программирование Windows" 5-е изд. Чарльз Петцольд (я знаю, что это довольно устарело (C) 1998) в надежде получить лучшее понимание прямого программирования Windows.

Я поражен распространением таких опций, как C #, NET, MFC, MVC, Qt, wxWidgets и т. Д.

Я часто застреваю, пытаясь понять, что происходит в среде MFC, потому что что-то в моем коде не работает так, как кажется, но проблема в том, что я не совсем понимаю, как MFC обрабатывает вещи на заднем фоне. Вот почему я пытаюсь научиться «прямому программированию Windows», где моя программа содержит весь код передачи сообщений, который я пишу. Надеюсь, это поможет мне лучше понять мой вопрос, чтобы кто-нибудь помог мне со мной.

1 Ответ

2 голосов
/ 20 марта 2010

X работает достаточно по-разному, чтобы обычная программа Windows и исходная программа X, вероятно, вообще не могли бы совместно использовать большой код пользовательского интерфейса.

Если вы хотите переносимости между ними, вполне вероятно, что вы захотите использовать что-то вроде Qt или wxWidgets. Из этих двух, wxWidgets больше похож на MFC, поэтому, вероятно, потребует меньше переписывания, но будет поддерживать (более или менее) тот же «разрыв», который вы видите между тем, что вы хотите, и тем, что он предоставляет.

Не зная больше о вашем приложении и о том, почему оно не подходит для MFC, невозможно догадаться, подойдет ли Qt лучше или нет. Непосредственное предположение будет "вероятно, нет".

MFC использует архитектуру «документ / представление», где Qt использует оригинальную архитектуру Model-View-Controller. По большей части класс Document MFC эквивалентен, в основном, модели и контроллеру, объединенному в один - поэтому, если ваш документ не содержит ничего полезного, в Qt вы, очевидно, имеете и модель, и контроллер, ни один из которых не сделал много, что было полезно.

Тем не менее, мне нужно поднять вопрос о том, почему ваш Документ в настоящее время мало что делает. Шаблон MVC оказался применимым к широкому кругу проблем, поэтому, хотя возможно, что он не будет хорошо работать для вашей проблемы, также возможно, что он может работать хорошо, и вы просто его не используете. Не зная больше о том, что ты делаешь, невозможно даже догадываться об этом.


Редактировать: Хорошо, разъяснение очень помогает. Первое, что нужно понять, это то, что Document не обязательно приравнивается к файлу. Напротив, документ может вполне разумно относиться к произвольному количеству файлов.

Например, рассмотрим веб-браузер. Все данные, необходимые для составления страницы, отображаемой в данный момент, будут разумно включены в один и тот же документ. В зависимости от вашей точки зрения, это либо ноль файлов, либо целая куча файлов (они будут начинаться как произвольное количество файлов, поступающих с сервера (ов), но вовсе не обязательно будут храниться как файлы локально). Хранение любого из них в виде файла локально будет (более или менее) случайным побочным продуктом кэширования, и в основном не связано с просмотром как таковым.

В вашем случае вы, вероятно, считываете два (или три?) Файла в память и сохраняете их вместе с некоторой структурой данных для хранения результата сравнения. После того, как сравнение завершено, вы можете или не можете отказаться от содержимого самих файлов. Я думаю, можно с уверенностью сказать, что «нормальное» разделение обязанностей было бы для этих данных и кода, который создает эти данные, для включения в Документ.

Представление должно содержать только код для извлечения результата из этой структуры данных и отображения его на экране. Почти единственными данными, которые вы обычно хотите сохранить в представлении, являются вещи, связанные с тем, как данные представлены (например, такие как уровень масштабирования или текущая позиция прокрутки). Аналогично, код в представлении должен относиться только к отображению результата и реагированию на ввод пользователя, а не к «созданию» данных в первую очередь.

Как таковая, я думаю, что ваша программа может быть переписана для более эффективного использования шаблона Document / View или может быть переписана для использования MVC. Это, в свою очередь, означает, что порт для Qt мог бы / мог бы работать просто отлично - при условии, что вы готовы потратить некоторое время и усилия на понимание того, как он должен работать, а затем внести в ваш код довольно существенные изменения, чтобы работать так, как задумано.

Как я уже говорил ранее, wxWidgets больше похож на MFC в этом отношении - он использует Document и View, а не Model, View и Controller. Это также сработает лучше всего, если вы будете переписывать, чтобы разделить обязанности так, как это было задумано. Хорошим моментом является то, что, вероятно, немного проще сделать это по одному шагу: переписать код в MFC, который вам уже знаком, а затем перенести его на wxWidgets - но с учетом сходства между ними, что «Порт», вероятно, будет немного больше, чем незначительное редактирование - часто достаточно просто поменять некоторые имена с C * на wx *. Насколько я помню, единственное место, где я много работал, было создание меню - с помощью MFC они обычно обрабатываются с помощью ресурсов, но (по крайней мере, несколько лет назад, когда я его использовал), wxWidgets обычно напрямую отображал код, который создал пункты меню.

Портирование на Qt, вероятно, будет более трудоемким - вам, скорее всего, придется изучать новую платформу, и существенно реорганизуют ваш код одновременно. Хорошим моментом является то, что когда вы закончите, результат, вероятно, будет несколько чище, хотя, учитывая то, что вы делаете, разница может быть довольно незначительной. В документе / представлении представление отображает данные и реагирует на ввод пользователя. В модели / представлении / контроллере представление отображает только данные, но пользовательский ввод (который изменяет базовые данные) проходит через контроллер. Поскольку вы (предположительно) не ожидаете изменения базовых данных, единственный пользовательский ввод, вероятно, принадлежит представлению в любом случае (например, такие как прокрутка). Едва ли возможно, что у вас может быть несколько вещей, которые вы можете поместить в документ / модель, которые будут открыты для изменения (например, такие вещи, как текущий шрифт или цвета, выбранные пользователем).

...