Мысли об MFC
От: AlexGin Беларусь  
Дата: 28.04.17 17:04
Оценка: 3 (2) +5
Всё приведенное ниже, это лично мои соображения по самой библиотеке MFC и по поводу места данного продукта в современном мире
Кроме того, здесь: http://rsdn.org/forum/cpp.qt/6769008.1
Автор: MasterZiv
Дата: 27.04.17
— я обещал товарищу MasterZiv вернуться к теме
обсуждения MFC (только уже в данном разделе, а не в разделе по Qt).

Я начал заниматься на MFC в 1999 году. Точнее скажу, что это была первая освоенная мной библиотека классов.
После неё было: Borland C++ Builder (VCL); .NET (C#) и, наконец, Qt. Посему — вроде как есть с чем сравнить.
Впрочем — сравнивать C# и MFC как-то нелогично (разные базовые языки), поэтому оставим только то, что на C++
Попутно замечу, что для некоторых проектов я применяю MFC и на сегодняшний день.

ДОСТОИНСТВА:
1) Легковесность. Так как MFC — это относительно небольшая объектно-ориентированная (впрочем — об этом чуть ниже)
надстройка над WIN API, то она весит совсем не много. По современным меркам — практически ничего.

2) Интуитивная ясность библиотеки MFC для разработчиков, владеющих WIN API. Библиотека классов MFC представляет
набор классов и методов для тех сущностей, которые составляют основу оконного интерфейса Windows, что упрощает
понимание сущностей, определенных в библиотеке MFC.

3) Большой объем наработок — как в интернете (codeguru, codeproject и т.д.), так и в старых репозиториях разработчиков,
посему — возможность быстро получить ответ (в т.ч. и здесь — на КЫВТе) по самым различным аспектам применения.

4) За счёт простоты, благодаря наличию исходников и уже указанным наработкам — большая кастомизируемость
(возможность сделать то, что хочет левая пятка Заказчика).

5) Следует отметить, что MFC развивается (правда экстенсивно) — MFC Feature Pack позволает разрабатывать
приложения с довольно современным GUI. Тот факт, что в оставку MSVC2015 вернули MBCS — Multi Byte Character Set
(которую уже выбросили из MSVC2013) — также несомненно свидетельствует о некоторой популярности MFC в наши дни.

НЕДОСТАТКИ (как всегда — обратная сторона достоинств):
a) Достаточно простые на сегодняшний день вещи, оказывается сделать совсем не просто. Конечно, если работал с MFC
долгие годы, то выход найдёшь. Но это уже совсем другая история
Так, например, ComboBox в составе тулбара: в Qt несколько строк; на MFC — куча кода
Ладно, оставим GUI. Посмотрим в сторону поддержки популярных СУБД. Однако, тут картина и того хуже. Если VCL и Qt
имеют приличную поддержку СУБД, то для MFC — приходится искать и приспосабливать разные костылики, чтобы
выполнить совсем не сложный SQL запрос.

b) Коды C++ проектов на Qt куда более читабельны и лаконичны, нежели на MFC. Программируя на MFC, разработчик
всегда связан с избыточными (техническими) сущностями, которые вполнее возможно было бы вынести из прикладного кода.
Даже простое диалоговое приложение (без Doc/View), изобилует ненужными в 99% ситуаций сущностями.
Так, вызовы DDX_Control(...), изобилующие в DoDataExchange — также на сегдня представляются мне избыточными
техническими сущностями.

c) Перенос готового класса из старого в новый проект — это для MFC также пляска с бубном!
Если я хочу перенести окно (в смысле — наследник CWnd), то пеернести файлы заголовочника (*.h) и исходника (*.cpp)
оказывается явно недостаточно. Необходимо 'выковыривать' как ресурсы, так и идентификаторы ресурсов и ручками
переносить их на новое место. Конфликт по идентификаторам ресурсов — это отдельная проблема, нет желания её касаться,
просто отмечу — что она есть и портит жизнь разработчика (как всегда в самый неподходящий момент).
В Qt, да и в VCL, перенос — это простое копирование файлов, после чего их прописываем проект — и забываем о б этом!

d) Архаичная архитектура Doc/View (Документ/Вид) также вводит лишнюю, абсолютно неактуальную для XXI века сущность.
Если в 1990-е, для текстового редактора это было актуально, то теперь — это просто избыточная сущность, на которую
тем не менее, завязана вся библиотека MFC. Это усложнение, которое просто приходится обходить в современных проектах —
напрмер, оставляяя пустой класс документа — просто для поддержки Doc/View

e) Понятие ООП в MFC какое-то половинчатое. Допускаю, что для 1990-х это было вполне даже нормально.
Например — паттерн observer для обработки сообщений реализован макросами BEGIN_MESSAGE_MAP/END_MESSAGE_MAP
Это решение в стиле старого доброго ANSI C, но никак не в стиле современного C++
Если я в диалоговое окно (средствами студии) добавляю новый контрол, то этот новый member класса...
... с какого-то перепугу объявляется как public — вместо private (или на худой конец protected).
Тот факт, что абстрактные классы в MFC не являются интерфейсами, а содержат реализацию, также представляет
отступление от идей нормального объектно-ориентированного дизайна.

Я прекрасно понимаю, что есть требования совместимости со старым кодом, но ведь могли же ввести, наряду с поддержкой старого, и какие-либо
новые варианты — соответствующие сегодняшнему уровню развития технологий...
Или же M$ уже собралась хоронить MFC

Вывод: применение MFC на сегодняшний день имеет смысл в простых проектах, где важна именно легкость.
Нередко это просто диалоговое окно со статически прилинкованной библиотекой MFC.
Для более сложных проектов — очевиден выбор Qt.
Для старых проектов, где этому MFC сто лет, и нет возможности/финансов перейти на что-то новое, также актуально применение MFC.

Благодарю всех, у кого хватило терпения дочитать до этой строчки!
И еще более благодарю тех, кто выразит свои мысли по данному поводу!
Отредактировано 28.04.2017 17:51 AlexGin . Предыдущая версия . Еще …
Отредактировано 28.04.2017 17:43 AlexGin . Предыдущая версия .
Отредактировано 28.04.2017 17:10 AlexGin . Предыдущая версия .
Re[2]: Мысли об MFC
От: Stanislav V. Zudin Россия  
Дата: 28.04.17 19:03
Оценка: 8 (1) +3
Здравствуйте, sergey2b, Вы писали:

S>Дайте пожалуйста совет по какой ниги лучше изчучать MFC так как сейчас впервый разв в жизни стал использовать MFC для GUI


В своё время неплохой была книжка Д.Круглински. Piter Press издавало её на русском.
Сейчас может чего-то новое появилось.
За исключением версии Студии и "нового" Feature Pack книжка по-прежнему актуальна.
_____________________
С уважением,
Stanislav V. Zudin
Re[2]: Мысли об MFC
От: AlexGin Беларусь  
Дата: 28.04.17 20:07
Оценка: 12 (2)
Здравствуйте, sergey2b, Вы писали:

S>Здравствуйте, AlexGin, Вы писали:


S>Дайте пожалуйста совет по какой ниги лучше изчучать MFC так как сейчас впервый разв в жизни стал использовать MFC для GUI


Раньше было немало книг по MFC. Перечислю некоторые, наиболее удачные, из них:
1) Круглински Д., Уингоу С., Шеферд Дж. — Программирование на Microsoft Visual C++ 6.0 для профессионалов
2) Jeff Prosise — Programming Windows with MFC, Second Edition (нет в русском переводе, я скачал англоязычную)
3) Кейт Грегори — Использование Visual C++ 6
Где найти сейчас эти книги — не знаю. Может удасться скачать где-либо.
Re: Мысли об MFC
От: Evgeniy Skvortsov Россия  
Дата: 29.04.17 18:17
Оценка: 10 (2)
Здравствуйте, AlexGin, Вы писали:

AG>И еще более благодарю тех, кто выразит свои мысли по данному поводу!


К плюсам MFC ещё можно добавить кучу визардов для VS, которые позволяют без ручного кодинга быстро и достаточно удобно добавлять новые методы, обработчики событий, переопределять виртуальные функции.
Так же хорошая поддержка COM.
Ну и мне всегда нравился класс CSocket для простеньких сетевых приложений. Для сложных вещей конечно этот класс использовать не надо.
Re: Мысли об MFC
От: qaz77  
Дата: 04.05.17 10:38
Оценка: +2
Здравствуйте, AlexGin, Вы писали:

AG>d) Архаичная архитектура Doc/View (Документ/Вид) также вводит лишнюю, абсолютно неактуальную для XXI века сущность.

AG> Если в 1990-е, для текстового редактора это было актуально, то теперь — это просто избыточная сущность, на которую
AG> тем не менее, завязана вся библиотека MFC. Это усложнение, которое просто приходится обходить в современных проектах -
AG> напрмер, оставляяя пустой класс документа — просто для поддержки Doc/View

Вот здесь не соглашусь.
Апп визард и в 6.0, и в современных студиях позволял отказаться от Doc/View.
При этом класса документа не создавалось вообще, а вместо CView подставлялся просто CWnd.
Это и в MDI работало, и в SDI.

Единственная известная мне фича, жестко завязанная на Doc/View, это предварительный просмотр печати (который CPreviewView, кажется).
Если им пользоваться, то да, только фейковые документы, док-темплейты и вьюшки.

Сам я в Doc/View от MFC много толку не вижу.
Там все слишком ориентированно на файлы и сложно под свою задачу кастомизировать.
Мне всегда было проще свой Model/View замутить.
Re[6]: Мысли об MFC
От: Nikolaz Германия www.nikeware.com
Дата: 05.05.17 14:08
Оценка: 6 (1)
Здравствуйте, qaz77, Вы писали:

Q>Там в апп визарде опция "Document/View architecture support" присутствует.

Да она там испокон веков присутствует. На моей памяти ещё с версии Visual C++ 1.5 (Да вот такой я старый ).
Document/View поддерживается на уровне MFC, а МDI (CreateMDIWindow()) "вшит" в Windows на уровне API.
Это то самое серое окно, точнее область MDI Main Window, на котором "пасутся" MDIChild.

А MFC Feature Pack — это купленная у питерской фирмы BCG библиотека контролов поверх обычного MFC, ранее называлась BCGControlBar.
Я эту BCGControlBar знаю ещё с тех времён, когда она на codeproject бесплатной была. Тогда я на нее плотно подсел, потому как из подобных "расширений" MFC — это было на тот момент самое путное, что я тогда видел. Похоже, что не ошибся . Те, кто хорошо знает BCGControlBar, в MFC Feature Pack разберутся без проблем, там почти все названия классов остались прежними, просто заменили CBCG**** на CMFC****. Свои проекты на BCG я простой заменой имен классов перевел на MFC Feature Pack (ну почти ).
--
www.nikeware.com — "To merge or not to merge?"
Re[5]: Мысли об MFC
От: peterbes Россия  
Дата: 22.05.17 08:51
Оценка: 6 (1)
Здравствуйте, AlexGin, Вы писали:

AG>Однако, на сегодня MFC не выглядит таким инновационным, как это было примерно 15 лет назад


Он и 15 лет назад не был инновационным и свежим, сейчас и подавно.
Свежим и инновационным был борландовский OWL, в четвертой и пятой студии на MFC без слез смотреть было невозможно.
OWL родился на граблях и косяках турбовижн, так что опыт графического интерфейсостоения уже был. MS просто переписали OWL, выкинув попутно убогие борландовские контейнерные классы, заменив их своими, Таблицу реакций обозвали Картой событий и получили свой первый MFC. Если посмотреть, то все структуры классов в первых MFC в точности повторяли структуры точно таких же классов OWL.
Единственное достоинство MFC, это долголетняя поддержка и более и менее постоянный программный интерфейс, старые и не самые большие проекты еще как-то можно пересобрать на новых студиях, тогда как Борланд еле-еле съехал с 16 бит и закончил свою жизнь в VCL
Отредактировано 22.05.2017 9:25 peterbes . Предыдущая версия .
Re[4]: Мысли об MFC
От: bnk Австрия http://unmanagedvisio.com/
Дата: 28.04.17 22:28
Оценка: 4 (1)
Здравствуйте, sergey2b, Вы писали:

bnk>>Нелегко тебе однако. Йоханнесбург?


S>нет США


Кто-то тут недавно, кажется, об отсталости/закостенелости Америки говорил? Вот, еще один наглядный пример

По сути, — я присоединюсь к Круглински.
Если до этого вообще дела с ужасом, летящим на крыльях ночи MFC, не имел, можешь firststeps.ru глянуть
Re[2]: Мысли об MFC
От: AlexGin Беларусь  
Дата: 30.04.17 18:26
Оценка: 1 (1)
Здравствуйте, Evgeniy Skvortsov, Вы писали:

ES>К плюсам MFC ещё можно добавить кучу визардов для VS, которые позволяют без ручного кодинга быстро и достаточно удобно добавлять новые методы, обработчики событий, переопределять виртуальные функции.

+100500
Это, конечно несомненно так, студия много чего (в плане заготовок для новых приложений) умеет сделать сама.
Мне часто кажется, что M$ снабдила свою студию таким набором визардов для MFC, для того,
чтобы скрыть все непрстые особонности применения дянной библиотеки. Типа: "а у на это — прямо из коробки, и вот это, и вот то..." —
в общем некоторое решение, может даже неплохое, чтобы как-то компенсировать разбухание прикладного C++ кода.

ES>Так же хорошая поддержка COM.

Да, COM — хорошая штука, но на уровне современных решений это довольно сложная вещица.
На сегодняшний день востребованы более простые для прикладного применения решения.
Re[2]: Мысли об MFC
От: bnk Австрия http://unmanagedvisio.com/
Дата: 28.04.17 21:20
Оценка: +1
Здравствуйте, sergey2b, Вы писали:

S> сейчас впервый разв в жизни стал использовать MFC для GUI


Нелегко тебе однако. Йоханнесбург?
Re[3]: Мысли об MFC
От: MasterZiv СССР  
Дата: 04.05.17 06:01
Оценка: +1
Здравствуйте, AlexGin, Вы писали:


AG>Мне, почему-то не припомнится аналог DoDataExchange для WindowsForms. Значит всё-таки что-то в консерватории (в M$) подправили.


Ну так там концепция другая, там published — свойства объектов, и объекты из сохранённых образов объектной системы восстанавливаются.


AG>А в Qt — что является аналогом DoDataExchange? ИМХО его там просто нет — так как он там не нужен, т.к. там всё это "за кадром" (весь

AG>автоматически сгенерированный код, там вынесен в отдельные файлы, в отличие от MFC, где "всё в одной большой куче").

.ui файлы там. По сути тоже аналог того решения, что сделано в WinFOrms.
Да, это вынесено из исходного кода, но зато если нужно что-то массово подправить -- сложнее.
Если не хочешь пользоваться визардами и средствами проектирования UI -- тоже сложнее, хотя не намного.
Но в целом, так на так и выходит, есть и плюсы, и минусы. Сравнивать это вряд ли можно, слишком разные решения.


AG>Насчёт DoDataExchange и прочих низкоуровневых штуковин: все они уходят корнями в стрый добрый WinAPI.


Да ладно, ну совсем никак не связано. Совершенно новая концепция именно в MFC для связи контролов WinAPI с контролами
формы и для связи данных из диалога с данными в форме на MFC/C++.
Где ты там корни WinAPI увидел -- сложно понять...
Ращве что только что это код, а не данные, хотя если абстрагироваться, можно DDX не воспринимать как код, а
воспринимать как специальный декларативный DSL, призваный описать какие-то аспекты работы формы. В принципе
в идеале он и должен быть таким, чисто декларативным.



MZ>>Но я могу сказать, что эти проблемы достаточно легки, потому что всё это делается механически.

AG>Если в солюшене порядка 50-ти проектов, это уже превращается в нехилый геморрой
Ну ты же не будешь переделывать сразу все 50 проектов... По одному,

AG>>d) Архаичная архитектура Doc/View (Документ/Вид) также вводит лишнюю, абсолютно неактуальную для XXI века сущность.

MZ>>Здрасти, приехали... В QT Doc/View вводят (в 4.5 кажется) -- это прогрессивно, а тут -- архаично ?
MZ>>Странная логика...
AG>Model/View для Qt — это совсем другое, идеология Model/View для Qt — это вариант развития, он ненавязчив, в отличии от Doc/View для MFC

Ну-ну. С каого это совсем другое? Это оно и есть, MVC, Subject/Observer, классика из GoF.
Совершенно разные реализации и подходы, это да, в MVC идея взята в более чистом виде, в QT сделали
много стандартных повторноиспользуемых моделей данных, список, таблица и таблица с иерархией.
(мне кстати не очень нравится, достаточно неуклюже сделано, чистого Subject/Observer нет вообще).

AG>Пример: в MFC Doc/View навязан всегда (для MDI и даже для SDI конструкции),


Нет, не навязан он всегда, есть Dialog based приложения.

Ну да, он немного более сильно чем нужно встроен в ядро MFC, это да, и я про это уже писал.
В том числе несчастный MDI.

AG>при этом он не связан с каким либо паттерном проектирования — он

AG>просто представляет собой атавизм, актуальный разве что для текстовых редакторов
AG>Для Qt — Model/View это вариант архитектуры проекта (он помогает согласовать изменение данных для паттерна MVC в проекте) —
AG>в самом простом случае можно обойтись и без него, создав полноценное (SDI,MDI,диалоговое) приложение с современным GUI.

Я ещё раз говорю, у тебя странная логика. Одно и то же решение, один и тот же паттерн тебе в одном случае нравится, принимается
за инновацию, в другом случае кажется архаичным и неправильным. И это при том, что в MFC Doc/View был с самого начала, с 90-ы, а
в QT появился только в 21 веке, потому что ну видимо все уже разработчики тыкали их носом в какашки и ругались, а где же у вас
Doc/View или MVC.

AG>Насчёт документ/вид — вопрос: Почему ТЕ ЖЕ ЛЮДИ не оставили эту идею в .NET?

AG>Ведь ни в WinForms, ни в WPF этой навязчивой идеи Doc/View не наблюдается.
AG>В ASP.NET MVC — приняты совсем иные идеи, которые куда более перспективны и удобны для прикладного программера, нежели документ/вид в MFC...

MFC и WinForms были сделаны для разных целей. MFC -- для создания Word-ов и Excel-ей, WInFOrms -- на замену VisualBasic, для создания корпоративных
приложений, состоящих в основном из таких концепций UI, как "форма". Ну, не нужны там Doc/View.

(для того же -- убить VisualBasic- создавалась и Delphi, автор идеи которой делал и WinFOrms).


AG>Ну, если говорить с некоторой натяжкой, то может это и Observer, но также довольно странный.


Без натяжек, это он и есть.

AG>Моё представление об ООП сформировалось из анализа тех решений, что есть в современных ЯВУ и прежде всего в .NET.

AG>Но даже в современном C++, эти решения уже ушли от того, что принято в MFC (ушли далекооо).

Кто тебе сказал, что .net -- это образцовый ООП?
Кто тебе сказал, что современный C++ -- это ООП (только ООП)?

AG>Похоже, что MFC появился до внедрения STL — вот и объяснение.


Он появился задолго даже до момента появления мысли о STL.



AG>В общем — дискуссии нашей пора в КСВ


Re[3]: Мысли об MFC
От: qaz77  
Дата: 04.05.17 15:06
Оценка: +1
Здравствуйте, AlexGin, Вы писали:
AG>Как это может реально работать, если и SDI, и MDI проекты в InitInstance создают и 'регистрируют' шаблон документа?

Ну вот работает — и все.
Сейчас под рукой MSVC 2013, делаем New project->MFC->MFC Application.
Там же, где выбирается MDI/SDI/Dialog based, есть опция "Document/View architecture support".
Если галочку снимаем, то никакие шаблоны документов и проч. не генерируются, ни в InitInstance, ни где-то еще.
ChildView делается просто наследником CWnd.

AG>Ещё интересная фича:

AG>
AG> virtual BOOL SaveModified( );
AG>

AG>переопределив этот метод, можем заменить сообщение о том, что юзер забыл сохранить документ.

"Сохранить документ" — это то же файлами отдает. А если у нас БД или просто на лету куда-то пишется?
К тому же есть простая альтернатива — return из OnClose окна-рамки до вызова родительской реализации.
Re[3]: Мысли об MFC
От: MasterZiv СССР  
Дата: 05.05.17 08:41
Оценка: +1
Здравствуйте, qaz77, Вы писали:

Q>В MSVC 6.0 класс визард и редактор ресурсов работали вполне сносно и его использование могло ускорить разработку.

Q>Потом MS все испортил и теперь больше сил уходит на борьбу с последствиями.
Q>В результате сейчас в 2013 студии класс визардом не пользуюсь вообще.


MSVC 6.0 вообще была лучшей версией студии. Начиная со следующей (2000+) её переписали на формсах,
и всё испортили (IMHO).
Re[7]: Мысли об MFC
От: AlexGin Беларусь  
Дата: 05.05.17 14:44
Оценка: +1
Здравствуйте, Nikolaz, Вы писали:

N>Здравствуйте, qaz77, Вы писали:


N>Document/View поддерживается на уровне MFC, а МDI (CreateMDIWindow()) "вшит" в Windows на уровне API.

N>Это то самое серое окно, точнее область MDI Main Window, на котором "пасутся" MDIChild.
+100500

N>А MFC Feature Pack — это купленная у питерской фирмы BCG библиотека контролов поверх обычного MFC, ранее называлась BCGControlBar.

Совершенно верно!
Я помню занимался с BCGControlBar на проектах очень старой работы ещё в 2001

N>Я эту BCGControlBar знаю ещё с тех времён, когда она на codeproject бесплатной была. Тогда я на нее плотно подсел, потому как из подобных "расширений" MFC — это было на тот момент самое путное, что я тогда видел. Похоже, что не ошибся .


Эта разработка опередила своё время — лет на пять, если не больше.

N>Те, кто хорошо знает BCGControlBar, в MFC Feature Pack разберутся без проблем, там почти все названия классов остались прежними, просто заменили CBCG**** на CMFC****. Свои проекты на BCG я простой заменой имен классов перевел на MFC Feature Pack (ну почти ).

Да, там небольшие различия были, но в общем можно было так делать вполне.
Re[2]: Мысли об MFC
От: AlexGin Беларусь  
Дата: 07.05.17 17:29
Оценка: -1
Здравствуйте, savitar, Вы писали:

S>Здравствуйте, AlexGin, Вы писали:


AG>>...


S>WTL — еще более легковесна, еще ближе к WinAPI

Да, но вот продираться через её 'дебри' ещё более геморройно

P.S. На дворе 2017-й — на компах (даже стареньких) летают программы, разработанные на .NET и Java!
Мы, апологеты C++, сегодня рискуем — в погоне за легковесностью, мы можем вполне превратиться в "рабов машины"
Можем оптимизировать то, что СОВСЕМ не требует никакой оптимизации...

Ну в действительности — какая разница:
обновление головного окна пройдёт за 0.3 sec или за 0.5 sec — если, например, период этого обновления 5 sec???
Отредактировано 07.05.2017 17:31 AlexGin . Предыдущая версия .
Re: Мысли об MFC
От: sergey2b ЮАР  
Дата: 28.04.17 17:58
Оценка:
Здравствуйте, AlexGin, Вы писали:

Дайте пожалуйста совет по какой ниги лучше изчучать MFC так как сейчас впервый разв в жизни стал использовать MFC для GUI
Re[3]: Мысли об MFC
От: sergey2b ЮАР  
Дата: 28.04.17 22:18
Оценка:
Здравствуйте, bnk, Вы писали:

bnk>Здравствуйте, sergey2b, Вы писали:


S>> сейчас впервый разв в жизни стал использовать MFC для GUI


bnk>Нелегко тебе однако. Йоханнесбург?


я уехал оттуда в 11 году
нет США
Re[3]: Мысли об MFC
От: AlexGin Беларусь  
Дата: 29.04.17 05:12
Оценка:
Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>В своё время неплохой была книжка Д.Круглински. Piter Press издавало её на русском.

+100500
Да, это была очень классная книга!
Где-то у меня она ещё есть, изданая на русском в Питер-пресс.

SVZ>Сейчас может чего-то новое появилось.

К сожалению, теперь ничего по MFC нового нет

SVZ>За исключением версии Студии и "нового" Feature Pack книжка по-прежнему актуальна.

Ну Feature Pack — я изучал по интернету (гуглением) лет пять назад.
Вот неплохие ресурсы:
http://www.codeguru.com/cpp/cpp/cpp_mfc/tutorials/article.php/c14929/MFC-Feature-Pack-An-Introduction.htm
https://www.codeproject.com/Articles/217588/Porting-a-legacy-MFC-app-to-MFC-Feature-Pack
http://ntcoder.com/bab/tutorial_mfc_feature_pack1_part1
Кроме того, помогает простое гугление по названию функции/метода/имени_класса — по Feature Pack инфы не так много,
как п оклассическому MFC, но при желани — найти можно.
Да и сайт MSDN — в качестве справочника по классам и их методам.
Отредактировано 29.04.2017 5:16 AlexGin . Предыдущая версия .
Re[3]: Мысли об MFC
От: rumit7  
Дата: 29.04.17 07:24
Оценка:
Здравствуйте, AlexGin, Вы писали:

AG>Раньше было немало книг по MFC. Перечислю некоторые, наиболее удачные, из них:

AG>1) Круглински Д., Уингоу С., Шеферд Дж. — Программирование на Microsoft Visual C++ 6.0 для профессионалов
AG>2) Jeff Prosise — Programming Windows with MFC, Second Edition (нет в русском переводе, я скачал англоязычную)
AG>3) Кейт Грегори — Использование Visual C++ 6
AG>Где найти сейчас эти книги — не знаю. Может удасться скачать где-либо.

если не найдутся, у моего друга вроде как были, скину если надо будет
Re[4]: Мысли об MFC
От: AlexGin Беларусь  
Дата: 29.04.17 07:41
Оценка:
Здравствуйте, rumit7, Вы писали:

R>если не найдутся, у моего друга вроде как были, скину если надо будет

Спасибо, уважаемый rumit7, у меня всё по MFC есть
Это спрашивал sergey2b, у которого возникла необходимость в изучении MFC.
Re: Мысли об MFC
От: MasterZiv СССР  
Дата: 03.05.17 12:47
Оценка:
Здравствуйте, AlexGin, Вы писали:

AG>Всё приведенное ниже, это лично мои соображения по самой библиотеке MFC и по поводу места данного продукта в современном мире

AG>Кроме того, здесь: http://rsdn.org/forum/cpp.qt/6769008.1
Автор: MasterZiv
Дата: 27.04.17
— я обещал товарищу MasterZiv вернуться к теме

AG>обсуждения MFC (только уже в данном разделе, а не в разделе по Qt).

Ну, тогда не могу не поучаствовать в топике

AG>1) Легковесность. Так как MFC — это относительно небольшая объектно-ориентированная (впрочем — об этом чуть ниже)


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

AG> Ладно, оставим GUI. Посмотрим в сторону поддержки популярных СУБД. Однако, тут картина и того хуже. Если VCL и Qt

AG> имеют приличную поддержку СУБД, то для MFC — приходится искать и приспосабливать разные костылики, чтобы
AG> выполнить совсем не сложный SQL запрос.

Да нужно просто сразу сказать, что в MFC поддержки программирования с СУБД просто нет. То лихое поделие, что
туда вставили во времена 6.0 годится только для галочки в маркетинговых статьях.


AG>b) Коды C++ проектов на Qt куда более читабельны и лаконичны, нежели на MFC.


Не согласен. Очень зависит от того, какой проект, какой код, как написан и т.п.
Например, мой лично код на MFC всегда был конфеткой...

Программируя на MFC, разработчик
AG> всегда связан с избыточными (техническими) сущностями, которые вполнее возможно было бы вынести из прикладного кода.
AG> Даже простое диалоговое приложение (без Doc/View), изобилует ненужными в 99% ситуаций сущностями.
AG> Так, вызовы DDX_Control(...), изобилующие в DoDataExchange — также на сегдня представляются мне избыточными
AG> техническими сущностями.

Не согласен. Очень сильно не согласен.

AG>c) Перенос готового класса из старого в новый проект — это для MFC также пляска с бубном!

AG> Если я хочу перенести окно (в смысле — наследник CWnd), то пеернести файлы заголовочника (*.h) и исходника (*.cpp)
AG> оказывается явно недостаточно. Необходимо 'выковыривать' как ресурсы, так и идентификаторы ресурсов и ручками
AG> переносить их на новое место. Конфликт по идентификаторам ресурсов — это отдельная проблема, нет желания её касаться,
AG> просто отмечу — что она есть и портит жизнь разработчика (как всегда в самый неподходящий момент).
AG> В Qt, да и в VCL, перенос — это простое копирование файлов, после чего их прописываем проект — и забываем о б этом!

Ну, ресурсы -- это отдельная тема и собственно с MFC или QT оно слабо связано.
Но я могу сказать, что эти проблемы достаточно легки, потому что всё это делается механически.

AG>d) Архаичная архитектура Doc/View (Документ/Вид) также вводит лишнюю, абсолютно неактуальную для XXI века сущность.


Здрасти, приехали... В QT Doc/View вводят (в 4.5 кажется) -- это прогрессивно, а тут -- архаично ?
Странная логика...

Вот MDI архаичен, вот это -- да, на 100%, и очень плохо, что эта архитектура фреймов врезана в самый что ни на есть
позвоночник MFC. Вот это -- реально очень плохо и негибко.

AG> Если в 1990-е, для текстового редактора это было актуально, то теперь — это просто избыточная сущность, на которую

AG> тем не менее, завязана вся библиотека MFC. Это усложнение, которое просто приходится обходить в современных проектах -
AG> напрмер, оставляяя пустой класс документа — просто для поддержки Doc/View

Ну... Не прав на 100%.

AG>e) Понятие ООП в MFC какое-то половинчатое. Допускаю, что для 1990-х это было вполне даже нормально.

AG> Например — паттерн observer для обработки сообщений реализован макросами BEGIN_MESSAGE_MAP/END_MESSAGE_MAP

Это не Observer
Observer -- это как раз Doc/View ...
А это -- реализация контроллеров в MVC, которые везде, во всех системах теперь отмирают за ненадобностью.
И это -- очень хорошее , декларативное решение. Например, в QT такого нет, точнее тоже есть, но оно там
спрятано из кода вообще.

AG> Это решение в стиле старого доброго ANSI C, но никак не в стиле современного C++

AG> Если я в диалоговое окно (средствами студии) добавляю новый контрол, то этот новый member класса...
AG> ... с какого-то перепугу объявляется как public — вместо private (или на худой конец protected).

Да объяви его как хочешь, он вытерпит....


AG> Тот факт, что абстрактные классы в MFC не являются интерфейсами, а содержат реализацию, также представляет

AG> отступление от идей нормального объектно-ориентированного дизайна.

Ну и что, валидное архитектурное решение, ничего страшного. Свет клином на интерфейсах не сошёлся. В классах с COM/OLE там
наоборот интерфейсов додури.
В общем, у тебя привратное, однобокое представление об ООП, так что, ну, можно конечно тебя послушать на эту тему, но
это не интересно. MFC -- это самый что ни на есть ООП.

Код MFC тем не менее достаточно архаичен, там почти не используются шаблоны и generic programming, там не испльзуется STL,
и ещё много чего.

AG>Вывод: применение MFC на сегодняшний день имеет смысл в простых проектах, где важна именно легкость.

AG>Для более сложных проектов — очевиден выбор Qt.
AG>Для старых проектов, где этому MFC сто лет, и нет возможности/финансов перейти на что-то новое, также актуально применение MFC.

Да нет же, всё не так. Если нужно программирование desktop UI под Windows, то фактически альтернативы MFC как не было, так и нет.
Не зависимо от сложности проекта. Дело в другом, что и UI только под Win уже мало кто хочет, и вообще Desktop мало кто хочет.
Вот в таких условиях MFC точно пасует. Не потянет.
Re[2]: Мысли об MFC
От: AlexGin Беларусь  
Дата: 03.05.17 16:46
Оценка:
Здравствуйте, уважаемый MasterZiv, Вы писали:

MZ>Ну, тогда не могу не поучаствовать в топике

Рад приветствовать, уважаемый MasterZiv

AG>1) Легковесность. Так как MFC — это относительно небольшая объектно-ориентированная (впрочем — об этом чуть ниже)


MZ>Ну, очень удивительно слышать такое, но я тебя понимаю. В смысле, я бы сказал так же, но многие разработчики это не

MZ>понимают. Для многих MFC -- это огромный и страшный монстр.
Стараюсь быть объективным. Это скорее маленькая рабочая лошадка

AG>b) Коды C++ проектов на Qt куда более читабельны и лаконичны, нежели на MFC.

MZ>Не согласен. Очень зависит от того, какой проект, какой код, как написан и т.п.
MZ>Например, мой лично код на MFC всегда был конфеткой...

Всё дело в том, что на MFC очень много чего лишнего приходится делать руками.
Пример: ProgressBar или ComboBox в составе ToolBar-a головного окна (для проекта MFC Feature Pack) — для MFC куча всякого кода,
дополнительные классы с переопределёнными вирт-методами и т.д.
То же самое для Qt — несколько скромных (весьма простых) строчек кода.
Замечу, что здесь не следует воспринимать что-либо как обиду (не наезжаю я на твой код), просто констатирую очевидный факт для MFC.
И мой, и твой, и самого господина Гейтса код на MFC, будет обладать всеми особенностами того, чем обладает любой мфц-шный проект.

AG>Программируя на MFC, разработчик

AG>всегда связан с избыточными (техническими) сущностями, которые вполнее возможно было бы вынести из прикладного кода.
AG>Даже простое диалоговое приложение (без Doc/View), изобилует ненужными в 99% ситуаций сущностями.
AG>Так, вызовы DDX_Control(...), изобилующие в DoDataExchange — также на сегдня представляются мне избыточными
AG>техническими сущностями.
MZ>Не согласен. Очень сильно не согласен.

Мне, почему-то не припомнится аналог DoDataExchange для WindowsForms. Значит всё-таки что-то в консерватории (в M$) подправили.
А в Qt — что является аналогом DoDataExchange? ИМХО его там просто нет — так как он там не нужен, т.к. там всё это "за кадром" (весь
автоматически сгенерированный код, там вынесен в отдельные файлы, в отличие от MFC, где "всё в одной большой куче").

Насчёт DoDataExchange и прочих низкоуровневых штуковин: все они уходят корнями в стрый добрый WinAPI.
Они уходят корнями туда, даже в тех случаях, когда вроде как нет аналогичной глобальной апи-шной функции (абсолютного аналога).
Да, для конца 1990-х и начала 2000-х это было шикарно. Однако, на сегодняшний день это уже не так.

AG> Необходимо 'выковыривать' как ресурсы, так и идентификаторы ресурсов и ручками

AG> переносить их на новое место. Конфликт по идентификаторам ресурсов — это отдельная проблема, нет желания её касаться,
AG> просто отмечу — что она есть и портит жизнь разработчика (как всегда в самый неподходящий момент).
AG> В Qt, да и в VCL, перенос — это простое копирование файлов, после чего их прописываем проект — и забываем о б этом!

MZ>Ну, ресурсы -- это отдельная тема и собственно с MFC или QT оно слабо связано.

Организация 'виджетов' в Qt кардинально отличается от WinAPI — отсюда ИМХО и "ноги растут".

MZ>Но я могу сказать, что эти проблемы достаточно легки, потому что всё это делается механически.

Если в солюшене порядка 50-ти проектов, это уже превращается в нехилый геморрой

AG>d) Архаичная архитектура Doc/View (Документ/Вид) также вводит лишнюю, абсолютно неактуальную для XXI века сущность.

MZ>Здрасти, приехали... В QT Doc/View вводят (в 4.5 кажется) -- это прогрессивно, а тут -- архаично ?
MZ>Странная логика...
Model/View для Qt — это совсем другое, идеология Model/View для Qt — это вариант развития, он ненавязчив, в отличии от Doc/View для MFC
Пример: в MFC Doc/View навязан всегда (для MDI и даже для SDI конструкции), при этом он не связан с каким либо паттерном проектирования — он
просто представляет собой атавизм, актуальный разве что для текстовых редакторов
Для Qt — Model/View это вариант архитектуры проекта (он помогает согласовать изменение данных для паттерна MVC в проекте) —
в самом простом случае можно обойтись и без него, создав полноценное (SDI,MDI,диалоговое) приложение с современным GUI.

Насчёт документ/вид — вопрос: Почему ТЕ ЖЕ ЛЮДИ не оставили эту идею в .NET?
Ведь ни в WinForms, ни в WPF этой навязчивой идеи Doc/View не наблюдается.
В ASP.NET MVC — приняты совсем иные идеи, которые куда более перспективны и удобны для прикладного программера, нежели документ/вид в MFC...

MZ>Вот MDI архаичен, вот это -- да, на 100%, и очень плохо, что эта архитектура фреймов врезана в самый что ни на есть

MZ>позвоночник MFC. Вот это -- реально очень плохо и негибко.
MDI иногда позволяет решить проблему, а иногда создаёт проблемы. Здесь всё зависит от проекта.

AG>e) Понятие ООП в MFC какое-то половинчатое. Допускаю, что для 1990-х это было вполне даже нормально.

AG> Например — паттерн observer для обработки сообщений реализован макросами BEGIN_MESSAGE_MAP/END_MESSAGE_MAP

MZ>Это не Observer

Просто одна из его (не весьма удачных) реализаций. Скажу так — Observer, но изуродованный до полной неузнаваемости

MZ>Observer -- это как раз Doc/View...

Ну, если говорить с некоторой натяжкой, то может это и Observer, но также довольно странный.
Во всяком случае, этот Observer подобен "Демьяновой ухе" — его навязывают практически без необходимости.

AG> Тот факт, что абстрактные классы в MFC не являются интерфейсами, а содержат реализацию, также представляет

AG> отступление от идей нормального объектно-ориентированного дизайна.

MZ>В общем, у тебя привратное, однобокое представление об ООП, так что, ну, можно конечно тебя послушать на эту тему, но

MZ>это не интересно. MFC -- это самый что ни на есть ООП.

Моё представление об ООП сформировалось из анализа тех решений, что есть в современных ЯВУ и прежде всего в .NET.
Но даже в современном C++, эти решения уже ушли от того, что принято в MFC (ушли далекооо).

MZ>Код MFC тем не менее достаточно архаичен, там почти не используются шаблоны и generic programming, там не испльзуется STL,

MZ>и ещё много чего.
+100500
Похоже, что MFC появился до внедрения STL — вот и объяснение.

MZ>Да нет же, всё не так. Если нужно программирование desktop UI под Windows, то фактически альтернативы MFC как не было, так и нет.


Ну давай смотреть, какие есть альтернативы и для чего:
1) .NET:
1.1. WindowsForms;
1.2. WPF;
2) Qt (здесь как под-вариант QML);
3) Java (да, несколько не нативно, но тем не менее).
MZ>Не зависимо от сложности проекта. Дело в другом, что и UI только под Win уже мало кто хочет, и вообще Desktop мало кто хочет.
В определенной нише — много (даже очень много) кто хочет!
MZ>Вот в таких условиях MFC точно пасует. Не потянет.
Конечно же, документооборот теперь почти весь на Web-е (что-то есть на .NET-е и что-то на Java).
Львиная доля современных технических desktop проектов — на Qt.

P.S. На сегодня desktop — это и управление IoT системами, и научные расчёты, и индустрия развлечений.

В общем — дискуссии нашей пора в КСВ
Отредактировано 03.05.2017 20:48 AlexGin . Предыдущая версия . Еще …
Отредактировано 03.05.2017 20:43 AlexGin . Предыдущая версия .
Отредактировано 03.05.2017 17:23 AlexGin . Предыдущая версия .
Отредактировано 03.05.2017 17:16 AlexGin . Предыдущая версия .
Отредактировано 03.05.2017 17:04 AlexGin . Предыдущая версия .
Re[2]: Мысли об MFC
От: AlexGin Беларусь  
Дата: 04.05.17 11:56
Оценка:
Здравствуйте, qaz77, Вы писали:

Q>Здравствуйте, AlexGin, Вы писали:


AG>d) Архаичная архитектура Doc/View (Документ/Вид)

AG> Это усложнение, которое просто приходится обходить в современных проектах -
AG> напрмер, оставляяя пустой класс документа — просто для поддержки Doc/View

Q>Вот здесь не соглашусь.

Q>Апп визард и в 6.0, и в современных студиях позволял отказаться от Doc/View.
Q>При этом класса документа не создавалось вообще, а вместо CView подставлялся просто CWnd.
Q>Это и в MDI работало, и в SDI.
Как это может реально работать, если и SDI, и MDI проекты в InitInstance создают и 'регистрируют' шаблон документа?
Ниже приведен пример из одного из моих старых проектов: переопределенный метод InitInstance:
m_pPhoneBookTemplate = new CMultiDocTemplate(IDR_PhoneBookTYPE,
        RUNTIME_CLASS(CPhoneBookDoc),
        RUNTIME_CLASS(CChildFrame), // настраиваемая дочерняя рамка MDI
        RUNTIME_CLASS(CPhoneBookView));
    if (!m_pPhoneBookTemplate)
        return FALSE;
    AddDocTemplate(m_pPhoneBookTemplate);

Вот такие есть шаблоны документов:
CMultiDocTemplate: https://msdn.microsoft.com/en-us/library/58d94y2f.aspx
CSingleDocTemplate: https://msdn.microsoft.com/en-us/library/7yha6tek.aspx
Каждый из них определяет набор: документ/окно_рамки/вид для каждого дочернего MDI (или же для единственного SDI) окна.
Этот механизм встроен в самое ядро MFC, посему его обойти, увы, не так-то просто (когда-то я экспериментировал с этим).
В реальности — проще оставить 'фейковый' (пустой) класс документа, нажели пытаться обойти фундаментальную архитектуру Doc/View

Q>Единственная известная мне фича, жестко завязанная на Doc/View, это предварительный просмотр печати (который CPreviewView, кажется).

Q>Если им пользоваться, то да, только фейковые документы, док-темплейты и вьюшки.
Да, это одна из фич, завязанных на Doc/View.
Ещё интересная фича:
 virtual BOOL SaveModified( );

переопределив этот метод, можем заменить сообщение о том, что юзер забыл сохранить документ.
Другое дело, что все эти фичи НЕ стоят тех усложнений и ограничений, что дополнительно вносит Doc/View

Q>Сам я в Doc/View от MFC много толку не вижу.

+100500
Да, именно поэтому данная архитектура и не сохранилась, по крайней мере в таком виде как в MFC, для современных фреймворков.
Q>Там все слишком ориентированно на файлы и сложно под свою задачу кастомизировать.
Q>Мне всегда было проще свой Model/View замутить.
Совершенно верно! У меня точно такая же проблема.
ИМХО все равно, потребуется разрабатывать свою бизнес-логику (включая свою реализацию "документа"), посему Doc/View от MFC и теряет смысл.
Отредактировано 04.05.2017 12:27 AlexGin . Предыдущая версия . Еще …
Отредактировано 04.05.2017 12:01 AlexGin . Предыдущая версия .
Отредактировано 04.05.2017 12:01 AlexGin . Предыдущая версия .
Re[2]: Мысли об MFC
От: qaz77  
Дата: 05.05.17 07:09
Оценка:
Здравствуйте, Evgeniy Skvortsov, Вы писали:

ES>К плюсам MFC ещё можно добавить кучу визардов для VS, которые позволяют без ручного кодинга быстро и достаточно удобно добавлять новые методы, обработчики событий, переопределять виртуальные функции.


К сожалению, в современных версиях студии добавление чего-либо в исходники с помощью визардов сильно испортили.
Раньше добавлялись метки //{{AFX_... для вставки в строго отведенные места.
Сейчас такие метки не добавляются, все лепится в конец.

С namespace это добро никогда нормально не работало.
Определения функций-членов лепились за закрывающей скобкой namespace и приходилось руками переносить.

Крайне неудобно добавлять файлы (визард Add class), если файл проекта лежит не в корне папки с исходниками.
Файлы всегда норовят создаваться рядом с файлом проекта.
Для мня это актуально, т.к. одноименные .vcproj под разные версии студии лежат в подпапках.

Не много не в тему. Наболело про редактор ресурсов.
Редактирование таблицы строк в новых студиях — это просто песня. В VC6 был вполне удобный.
Импорт ресурса из файла, например иконки, добавляет в проект "res/my_icon.ico" и "../res/my_icon.ico".

Вывод такой.
В MSVC 6.0 класс визард и редактор ресурсов работали вполне сносно и его использование могло ускорить разработку.
Потом MS все испортил и теперь больше сил уходит на борьбу с последствиями.
В результате сейчас в 2013 студии класс визардом не пользуюсь вообще.
Re[4]: Мысли об MFC
От: AlexGin Беларусь  
Дата: 05.05.17 09:04
Оценка:
Здравствуйте, MasterZiv, Вы писали:

MZ>MSVC 6.0 вообще была лучшей версией студии. Начиная со следующей (2000+) её переписали на формсах,

MZ>и всё испортили (IMHO).
+100500
Похоже, что в те годы, когда не было .NET (не было ни WinForms, ни WPF), руководство M$ видело MFC как основной инструмент
для разработки desktop applications. Однако, с середины 2000-х ситуация изменилась: эта библиотека перестала (почти полностью) развиваться,
студия (точнее — её автор M$) отнеслась к MFC как 'злая мачеха'

P.S. Ещё раз хочу подчеркнуть: я не собираюсь здесь вести дискуссию в стиле КСВ — типа есть только правильные и НЕправильные вещицы
Нет, я хочу здесь наоборот — изложить мою точку зрения и помочь разобраться по существу коллегам (и в чём-то даже мне самому)
с достоинствами и недостатками, присущими современному MFC!

P.P.S. Если эта тема сможет открыть мне и другим старожилам форума MFC что-либо новое, то можно будет смело сказать,
что — наши старания не пропали за зря!!!
Отредактировано 05.05.2017 9:46 AlexGin . Предыдущая версия . Еще …
Отредактировано 05.05.2017 9:36 AlexGin . Предыдущая версия .
Отредактировано 05.05.2017 9:31 AlexGin . Предыдущая версия .
Re[4]: Мысли об MFC
От: AlexGin Беларусь  
Дата: 05.05.17 09:22
Оценка:
Здравствуйте, qaz77, Вы писали:

Q>Ну вот работает — и все.

Q>Сейчас под рукой MSVC 2013, делаем New project->MFC->MFC Application.
Q>Там же, где выбирается MDI/SDI/Dialog based, есть опция "Document/View architecture support".
Q>Если галочку снимаем, то никакие шаблоны документов и проч. не генерируются, ни в InitInstance, ни где-то еще.
Q>ChildView делается просто наследником CWnd.

Кстати, да!
Даже работает!
Проверил на MSVC 2015 (CE Update 3) — удивительное рядом! Можно не 'таскать' за собой "документ"
К сожалению, это не отменяет некоторый overhead по кодам: так сгенерированы CMainFrame (наследник CMDIFrameWndEx),
и CChildFrame (наследник CMDIChildWndEx), также делаются некоторые действия технического характера с этими (лишними???) сущностями.
Но это вполне в стиле технологий, принятых в 1990-е, тогда это было в тренде.

Однако, тем не менее, это уже приятный для программера шаг вперед
Отредактировано 05.05.2017 9:43 AlexGin . Предыдущая версия . Еще …
Отредактировано 05.05.2017 9:24 AlexGin . Предыдущая версия .
Re[5]: Мысли об MFC
От: qaz77  
Дата: 05.05.17 12:21
Оценка:
Здравствуйте, AlexGin, Вы писали:
AG>Однако, тем не менее, это уже приятный для программера шаг вперед

Это не шаг вперед, а просто эту возможность еще не сломали.

Сейчас не поленился, запустил MSVC 6.0 под виртуалкой XP.
Там в апп визарде опция "Document/View architecture support" присутствует.
Re[4]: Мысли об MFC
От: AlexGin Беларусь  
Дата: 05.05.17 13:12
Оценка:
Здравствуйте, MasterZiv, Вы писали:

AG>Если в солюшене порядка 50-ти проектов, это уже превращается в нехилый геморрой

MZ>Ну ты же не будешь переделывать сразу все 50 проектов...

Если у меня есть солюшн с 50-ю проектами, и вот в один из них мне надо добавить диалоговое окошко — притом такое,
какое я делел несколько лет назад в совсем другом проекте ExternalProject (ну или нашёл его на codeguru/codeproject).
Казалось бы — просто скопируй файлы диалога в свой проект и пропиши в файлах проекта...
Вот здесь и начнется вся пляска с бубнами:
I. Первый раунд — вытащить из файла ExternalProject.rc все нужные мне ресурсы и перенести в файл *.rc
требуемого проекта в моём пятидесятипроектном солюшене
Это — только первая часть ручной кропотливой работы.
II. Идентификаторы — это вторая часть.
Здесь надо следить , чтобы ID из этого 'нового' для моего пятидесятипроектного солюшена окна не пересекался с существующим.
Если же будет пересекаться, то возможно два варианта:
1) UB со всеми прелестями (глюками, вылетами и т.д.);
2) всё пройдет нормально и не страшно для работы приложения.
Замечу, что в иднтификаторах ресурсов есть несколько категорий:
#define _APS_NEXT_RESOURCE_VALUE        224
#define _APS_NEXT_COMMAND_VALUE         32901
#define _APS_NEXT_CONTROL_VALUE         1150
#define _APS_NEXT_SYMED_VALUE           101

ИМХО здесь важно чтобы по всем этим категориям ничего не пересекалось.
И все идентификаторы, во всех 50-ти проектов надо сравнивать с 'новым' окошком...


В Qt — см выше: просто скопируй файлы диалога в свой проект и пропиши в файлах проекта...
...и никаких плясок, и не нужен бубен...
Отредактировано 05.05.2017 13:28 AlexGin . Предыдущая версия . Еще …
Отредактировано 05.05.2017 13:25 AlexGin . Предыдущая версия .
Отредактировано 05.05.2017 13:22 AlexGin . Предыдущая версия .
Отредактировано 05.05.2017 13:19 AlexGin . Предыдущая версия .
Re[5]: Мысли об MFC
От: bnk Австрия http://unmanagedvisio.com/
Дата: 05.05.17 13:48
Оценка:
Здравствуйте, AlexGin, Вы писали:

AG>1) UB со всеми прелестями (глюками, вылетами и т.д.);

AG>2) всё пройдет нормально и не страшно для работы приложения.
AG>Замечу, что в иднтификаторах ресурсов есть несколько категорий:
AG>
AG>#define _APS_NEXT_RESOURCE_VALUE        224
AG>#define _APS_NEXT_COMMAND_VALUE         32901
AG>#define _APS_NEXT_CONTROL_VALUE         1150
AG>#define _APS_NEXT_SYMED_VALUE           101
AG>

AG>ИМХО здесь важно чтобы по всем этим категориям ничего не пересекалось.
AG>И все идентификаторы, во всех 50-ти проектов надо сравнивать с 'новым' окошком...

В прошлой жизни это решалось через RiverBlade ResOrg

А вообще я слышал (ОБС), что чел, отвечающий за работу с Resources в Visual Studio в детстве спас жизнь Биллу Гейтсу,
поэтому уволить или как-то наказать его невозможно
Re[5]: Мысли об MFC
От: qaz77  
Дата: 05.05.17 13:49
Оценка:
Здравствуйте, AlexGin, Вы писали:
AG>Да как бы ID контрола в составе этого окошка не пересёкся...
AG>Если же будет пересекаться, то возможно два варианта:
AG>1) UB со всеми прелестями (глюками, вылетами и т.д.);
AG>2) всё пройдет нормально и не страшно для работы приложения.
AG>Замечу, что в иднтификаторах ресурсов есть несколько категорий:
AG>
AG>#define _APS_NEXT_RESOURCE_VALUE        224
AG>#define _APS_NEXT_COMMAND_VALUE         32901
AG>#define _APS_NEXT_CONTROL_VALUE         1150
AG>#define _APS_NEXT_SYMED_VALUE           101
AG>

AG>ИМХО здесь важно чтобы по CONTROL_VALUE ничего не пересекалось.

ID контрола должен быть уникальным только в пределах родительского окна.
Если есть два диалога, то ID их контролов могут пересекаться без последствий.

Я, например, использую простые имена типа IDC_NAME, IDC_COMMENT в разных окошках.
Предустановленные же идентификаторы не вызывают конфликтов: IDOK, IDCANCEL.
Чем кастомные хуже?

Даже в более сложных случаях (child dialog, property page) с дублированием ID нет никаких проблем.
Допустим у меня есть шаблон child диалога в 2-мя редакторами и кнопкой: IDC_ZEDIT1, IDC_ZEDIT2, IDC_ZBUTTON.
Вставляем сколько угодно экземпляров такого дочернего диалога в popup диалог, все будет работать ок.

Я вижу только одну возможность конфликта. Когда один из новоприобретенных IDC_... уже есть в resource.h с другим значением.
Как ты новые IDC_... в resource.h добавляешь?
Я бы вставил блоком в конец и запустил компиляцию.
Если компилятор начнет кричать про macro redefinition, то только тогда начинать беспокоиться...
Re[6]: Мысли об MFC
От: AlexGin Беларусь  
Дата: 05.05.17 14:03
Оценка:
Здравствуйте, qaz77, Вы писали:

Q>Я вижу только одну возможность конфликта. Когда один из новоприобретенных IDC_... уже есть в resource.h с другим значением.

Q>Как ты новые IDC_... в resource.h добавляешь?
Вручную — стараюсь подобрать номер, которого нет.
Да, вставляю в конец resource.h, однако, если в другом проекте солюшена есть уже равные ему значения в его файле resource.h?
Тогда ищу, корректирую ID нового контрола — чтобы не было конфликтов.

Q>Я бы вставил блоком в конец и запустил компиляцию.

Аналогично, вставляю в конец.
Re[7]: Мысли об MFC
От: Nikolaz Германия www.nikeware.com
Дата: 05.05.17 14:13
Оценка:
Здравствуйте, AlexGin, Вы писали:

AG>Тогда ищу, корректирую ID нового контрола — чтобы не было конфликтов.

Для Visual Studio 6.0 у меня была макро написана, которая позволяла выделенные строки перенумеровать с номера, который был у первой выделенной строки.
--
www.nikeware.com — "To merge or not to merge?"
Re: Мысли об MFC
От: Went  
Дата: 05.05.17 20:51
Оценка:
Здравствуйте, AlexGin, Вы писали про MFC.
Также не соглашусь по Document/View. По-моему, вы просто не научились их хорошо готовить или используете не там, где они требуются. Для создания разнообразных редакторов это просто то, что доктор прописал. А если требуется что-то другое, то создается Dialog Based и там вы вольны делать все что захочется. Я бы сказал иначе — стандартные средства MFC "из коробки" не поощряют некоторые подходы, однако не запрещают их. Например, никто не мешает создать многооконное приложение вообще без упоминания документов и видов. Реализуйте свои упрощенные фреймы, благо, исходники стандартных MS поставляет.
Re[2]: Мысли об MFC
От: AlexGin Беларусь  
Дата: 06.05.17 06:20
Оценка:
Здравствуйте, уважаемый Went, Вы писали:

W>Также не соглашусь по Document/View. По-моему, вы просто не научились их хорошо готовить или используете не там, где они требуются. Для создания разнообразных редакторов это просто то, что доктор прописал.

Да, это именно так. Писать редактор текста/картинок/видео — идеально на MFC.
Но, например, для SCADA системы, это уже не актуально.
У нас была разработка SCADA на MFC. Получилось в общем неплохо (даже конкуренто-пригодно), но очень многое в библиотеке MFC оказалось просто излишним.

W>А если требуется что-то другое, то создается Dialog Based и там вы вольны делать все что захочется. Я бы сказал иначе — стандартные средства MFC "из коробки" не поощряют некоторые подходы, однако не запрещают их.

Dialog Based — это хорошо. Но только для относительно не больших утилит.
Я в курсе, что Dialog Based может иметь и Menu, и ToolBar, и StatusBar (всё в одном). При этом диалоговое окно может быть разделено сплиттерами.
Получается в общем-то современный дизайн GUI. Был у нас такой проект лет пять назад (телеф-книга).
Однако, все приличные современные приложения обычно MDI + Dockable (в плане GUI).
Организация хранения данных — на MS SQL Server-е или на ORACLE сервере.
Вот с этих позиций и получается, что MFC фактически 'остался' на уровне примерно 10...15 летней давности

W>Например, никто не мешает создать многооконное приложение вообще без упоминания документов и видов. Реализуйте свои упрощенные фреймы, благо, исходники стандартных MS поставляет.

К сожалению, здесь уже IMHO для MFC "поезд ушёл"
Точнее — осталось только, пожалуй, Dialog Based, как вариант с минимальным оверхедом
Всё остальное на C++ имеет смысл разрабатывать используя Qt.
Отредактировано 06.05.2017 6:29 AlexGin . Предыдущая версия . Еще …
Отредактировано 06.05.2017 6:24 AlexGin . Предыдущая версия .
Re: Мысли об MFC
От: savitar  
Дата: 06.05.17 19:32
Оценка:
Здравствуйте, AlexGin, Вы писали:

AG>...


WTL — еще более легковесна, еще ближе к WinAPI
Re[2]: Мысли об MFC
От: prog123 Россия  
Дата: 06.05.17 21:12
Оценка:
Здравствуйте, sergey2b, Вы писали:

S>Здравствуйте, AlexGin, Вы писали:


S>Дайте пожалуйста совет по какой ниги лучше изчучать MFC так как сейчас впервый разв в жизни стал использовать MFC для GUI


У меня была такая: Visual C++ и MFC
Вроде бы неплохая, но сравнить не с чем, других не было)) Плюсы: дешевая и можно скачать в pdf.
Re[3]: Мысли об MFC
От: Evgeniy Skvortsov Россия  
Дата: 10.05.17 09:08
Оценка:
Здравствуйте, AlexGin, Вы писали:

S>>WTL — еще более легковесна, еще ближе к WinAPI

AG>Да, но вот продираться через её 'дебри' ещё более геморройно

Имхо, нет в WTL никаких дебрей, там главное её концепцию понять. Тут на кывте есть две отличные статьи по потрохам WTL, я по ним и разбирался.
Совсем тонкая надстройка над WINAPI, прекрасно подходит для написания небольших приложений с не очень сложным интерфейсом.
К тому же изначально она поддерживала все версии виндовс и мобильную систему тех лет(как там она звалась Windows CE что ли)
Сейчас это всё неактуально, но если надо написать какую-то мелкую утилитку то вполне можно использовать, ибо кодить на голом винапи это же чистый ад.

Плюс она в основном для GUI предназначена, там остальных классов то практически и нет.
Re[3]: Мысли об MFC
От: Went  
Дата: 19.05.17 06:15
Оценка:
Здравствуйте, AlexGin, Вы писали:

AG>Но, например, для SCADA системы, это уже не актуально.

AG>У нас была разработка SCADA на MFC. Получилось в общем неплохо (даже конкуренто-пригодно), но очень многое в библиотеке MFC оказалось просто излишним.
Я бы не сказал, что избыточность библиотеки для некоторого класса задач делает ее плохой. Основная проблема MFC (если не брать ее неактуальное состояние), это излишняя "прибитость гвоздями" к некоторым концепциям. Например, документ жестко завязан на то, что он будет храниться в файле. Когда нужно сделать некоторый "абстрактный" документ, начинаются "сопли". Фрейм завязан на то, чтобы хранить "вид", который завязан на то, чтобы отображать именно "документ". Все это можно обходить, но обходится не очень красиво.

AG>Однако, все приличные современные приложения обычно MDI + Dockable (в плане GUI).

У меня на MFC именно такое приложение, полет нормальный. Выглядит довольно современно. И панели докаются, и ribbon, и диспетчер свойств. Жизнь портит только некоторая "сырость" Feature Pack-а.

AG>Точнее — осталось только, пожалуй, Dialog Based, как вариант с минимальным оверхедом

Не соглашусь. См п.1. — приложения-редакторы пишутся на MFC довольно удобно.

AG>Всё остальное на C++ имеет смысл разрабатывать используя Qt.

Ну зачем мне QT для разработки windows-vs-only редактора?
Re[4]: Мысли об MFC
От: AlexGin Беларусь  
Дата: 21.05.17 17:09
Оценка:
Здравствуйте, Went, Вы писали:

W>Я бы не сказал, что избыточность библиотеки для некоторого класса задач делает ее плохой. Основная проблема MFC (если не брать ее неактуальное состояние), это излишняя "прибитость гвоздями" к некоторым концепциям. Например, документ жестко завязан на то, что он будет храниться в файле. Когда нужно сделать некоторый "абстрактный" документ, начинаются "сопли". Фрейм завязан на то, чтобы хранить "вид", который завязан на то, чтобы отображать именно "документ". Все это можно обходить, но обходится не очень красиво.

+100500
Это именно то, о чем шла речь в первоначальном моём сообщении.
Отсутствие гибкости, при избыточности — это то, что можно именовать как "прибитость гвоздями" к некоторым концепциям

AG>>Однако, все приличные современные приложения обычно MDI + Dockable (в плане GUI).

W>У меня на MFC именно такое приложение, полет нормальный. Выглядит довольно современно. И панели докаются, и ribbon, и диспетчер свойств. Жизнь портит только некоторая "сырость" Feature Pack-а.
У меня также есть приложения такого рода, с MDI + Dockable с применением MFC Feature Pack (ранее известный как BCG Library).
Вопрос ведь совсем не в этом. Ведь никто не утверждает здесь, что это не возможно
Однако, никто и не собирается спорить, о том что всё вышеуказанное в MFC + (MFC Feature Pack) делается с большим оверхедом.
Этот оверхед имеет место на уровне кодов проекта, а не на уровне каких-то дополнительных (технических, автогенерируемых) файлов.

AG>>Точнее — осталось только, пожалуй, Dialog Based, как вариант с минимальным оверхедом

W>Не соглашусь. См п.1. — приложения-редакторы пишутся на MFC довольно удобно.
Какова актуальность очередного велосипеда редактора в 2017-ом?
Конечно же, когда MFC появился, подобная актуальность была значительно выше.

AG>>Всё остальное на C++ имеет смысл разрабатывать используя Qt.

W>Ну зачем мне QT для разработки windows-vs-only редактора?
Вот в том-то и дело, что на уровне кодов проекта, даже тот же самый редактор (например текстов) сделанный на Qt, окажется более компактным и читабельным, чем его же собрат от MFC.
Да, в Qt будут автоматически сгенерированные файлы, но сложности проекта это НЕ ДОБАВИТ, так как это является отдельной технической сущностью, которая "живёт" не в кодах проекта. Прикладному программисту эта сущность не осложняет жизнь, для него она вообще практически не заметна (она существует где-то "за кадром").

P.S. Совсем не хочу умалять значимости MFC в мире IT!
При помощи MFC сделано немало хороших проектов.
К некоторым из них, я имел честь приложить мозги и руки
Однако, на сегодня MFC не выглядит таким инновационным, как это было примерно 15 лет назад
Отредактировано 21.05.2017 17:18 AlexGin . Предыдущая версия . Еще …
Отредактировано 21.05.2017 17:17 AlexGin . Предыдущая версия .
Re[5]: Мысли об MFC
От: Went  
Дата: 22.05.17 08:20
Оценка:
Здравствуйте, AlexGin, Вы писали:

AG>Однако, на сегодня MFC не выглядит таким инновационным, как это было примерно 15 лет назад

Однозначно. Он выглядит просто архаичным, а с Feature Pack — еще и глючно-сырым. Танцы с MBСS vs UNICODE вообще умиляют. Но мне для работы нужна именно MFC-подобная библиотека, тонкая, прозрачная, вшитая, интегрированная, чтобы "пиф-паф, и в студии все закрутилось, а на другие платформы плевать".
Re[6]: Мысли об MFC
От: aloch Россия  
Дата: 03.06.17 12:54
Оценка:
Здравствуйте, peterbes, Вы писали:

P>Здравствуйте, AlexGin, Вы писали:


AG>>Однако, на сегодня MFC не выглядит таким инновационным, как это было примерно 15 лет назад


P>Он и 15 лет назад не был инновационным и свежим, сейчас и подавно.

P>Свежим и инновационным был борландовский OWL, в четвертой и пятой студии на MFC без слез смотреть было невозможно.
P>OWL родился на граблях и косяках турбовижн, так что опыт графического интерфейсостоения уже был. MS просто переписали OWL, выкинув попутно убогие борландовские контейнерные классы, заменив их своими, Таблицу реакций обозвали Картой событий и получили свой первый MFC. Если посмотреть, то все структуры классов в первых MFC в точности повторяли структуры точно таких же классов OWL.
P>Единственное достоинство MFC, это долголетняя поддержка и более и менее постоянный программный интерфейс, старые и не самые большие проекты еще как-то можно пересобрать на новых студиях, тогда как Борланд еле-еле съехал с 16 бит и закончил свою жизнь в VCL

что то с историей у тебя плохо

Из английской Википедии

In the early 1990s, Borland dominated the C++ market. In 1991, Borland introduced Borland C++ 3.0 which included OWL 1.0. At that time, C++ was just beginning to replace C for development of commercial software, driven by the rising of the Windows platform. During this period, OWL was a popular choice for Windows application development
In 1992, Microsoft introduced MFC as part of Microsoft C/C++ 7.0. As a similar C++ application framework for Windows, MFC immediately became OWL's primary competitor in the C++ application development market.
OWL 1.0 depended on Dynamic Dispatch Virtual Tables (DDVT), a proprietary extension to C++ that allowed the programmer to bind Windows messages (events) to functions (event handlers) in a simple manner and with little run-time overhead. MFC, on the other hand, used a solution that did not require a language extension.
In 1993, Borland launched Borland C++ 2.0 which included OWL 2.0. In this version of OWL, the proprietary DDVT extension was replaced by response tables, a macro-based solution compatible with standard C++ and similar to MFC in use. A conversion tool (OWLCVT) was included to migrate code from OWL 1.0 to OWL 2.0.


OWL 1 на каждый новый класс-окно Windows создавал новую таблицу виртуальных функций, с количеством функций большим, чем событий в Windows. Память это жрало как не в себя, но ведь это очень по С++ совски
МФЦ создавала для нового класса-окна создавалась небольшая карта событий, добавлявшаяся к базовой карте. В МФЦ обработчики событий — не виртуальные функции. В ОВЛ 2 (появившейся _ПОСЛЕ_ МФЦ 1) от виртуальных функций отказался и Борланд, сделав нечто по мотивам макросов МФЦ. Потом вообще лицензировал МФЦ для поставки.


http://files.rsdn.org/1366/MCP(rgb).jpg
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.