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[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[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[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: Мысли об 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[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[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[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 . Предыдущая версия .
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.