Pull to refresh

Comments 35

PinnedPinned comments

Теперешний MFC - это старый MFC на стероидах. Когда-то Microsoft взяла библиотеку BCG Control Bar от https://bcgsoft.com/, которая была по сути была просто MFC Extension, и добавила её в саму MFC. Там у большинства классов просто префикс в названиях поменяли с CBCG* на CMFC* :-)

Вот поэтому для работы с интерфейсом Windows использую C# =)

Не знаю, насколько всё хорошо на данный момент, но пару лет назад WinForm умели хорошенько подвисать при большом количестве элементов.

Может быть, WinForms и не самый лучший вариант, но ведь есть и WPF.

Видимо нет, потому что дальше продолжили метания UWP, Avalonia, MAUI, WinUI, ... или может Веб =)

Пока что самое крутое из всего, что когда-либо существовало для разработки GUI под винду — это VCL (например, в связке с C++ Builder).
Возможности не ниже, чем у WinForms, но полностью нативно, позволяет создавать собственные библиотеки кастомных компонент, которые нормально обрабатываются линкером (а не как в C#, когда при использовании одного-единственного виджета в сборку добавляется вся библиотека целиком), очень быстро работает и не требует монструозного фреймворка.
Всё остальное по сравнению с VCL выглядит какими-то убогими студенческими поделками.

Возможности не ниже, чем у WinForms

Но ниже, чем у XAML, QML фреймворков

Теперешний MFC - это старый MFC на стероидах. Когда-то Microsoft взяла библиотеку BCG Control Bar от https://bcgsoft.com/, которая была по сути была просто MFC Extension, и добавила её в саму MFC. Там у большинства классов просто префикс в названиях поменяли с CBCG* на CMFC* :-)

BGC куда лучше выглядит по сей день, но и требует монету.

Там не самая большая цена, особенно для компании. При этом большой плюс, что библиотека поставляется с исходниками.

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

А ещё была (есть?) конкурирующая библиотека CodeJock Extreme Toolkit

UFO just landed and posted this here
UFO just landed and posted this here

Потому что Borland как был помойкой для олдов, так ей и остаётся.

UFO just landed and posted this here

Ну, политика минусов на хабре - это норма. Пора уже просто свыкнуться. А в плане визуальной составляющей.. VCL всё равно проигрывает тому же ImGui. Так что...

UFO just landed and posted this here

А тут уже объясняем, в чём не прав стандартный конструктор MFC

Несколько раз перечитал раздел, но не нашел никакого объяснения...

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

Никогда офис не использовал MFC для GUI. Подозреваю что Vusual Studio - тоже

После этих слов мне захотелось пореверсить Office

На самом деле MFC удобен тем, что это решение из коробки. Не нужно заморачиваться со всякими сторонними решениями, тем более, что его редактор уже по умолчанию встроен в MSVC, да и динамическая линковка позволяет добиться минимального размера программы. А все нужные библиотеки уже стоят у большинства клиентов, в крайнем случае поставят redistributable c++ и все должно заработать.

Да согласен, но повторюсь тут вариант из коробки. Так то всегда можно QT, или MXToolkit или ещё множество других вариантов.

Qt разнесёт размер приложения до неприличия. Хотя писать да, удобно.

Плюс Qt из-за его pep архитектуры отлаживать не удобно. Но это уже так, личные заморочки.

Я в отладку попадаю, только когда в кишках Qt Creator копаться приходится. Пока проблем с отладкой не замечал. А что такое PEP архитектура?

На рабочем проекте была задача написать редактор на MFC.

По-моему, именно здесь источник проблем. Нужен ли сам редактор, это отдельный вопрос, а насчет MFC, мнение сложилось давно. Его нужно, по возможности, избегать.

В свое время, MFC мне нравился, и я писал на нем свои проекты и даже публиковал статьи на codeproject.com и sql.ru. Но, к моему удивлению, всегда встречал комментарии, почему MFC? Ибо он такой, сякой и т.п. Главные обвинения – сложный и непрозрачный, особенно, если хочешь отклониться от генеральной линии. На что я отвечал, да, но зато мозги тренирует, заставляет изворачиваться и изощряться. В то время не были опубликованы исходники MFC, думаю, мне бы тогда они сильно помогли. А сейчас они уже не интересны.

Однако, «капля камень точит» и я тоже, постепенно, пришел к мнению, что в MFC что-то не так. Начал искать альтернативу: Qt, wxWidgets, Win32xx, WTL, WinApi. Все эти фрейморки весьма хороши для своих целей, но лично мне более всего подходят последние два.

Поэтому, главный вопрос это как уйти от MFC? Ну, или «колоться и продолжать есть кактус».

MFC простой и прозрачный для тех, кто учил WinAPI. Всё

Он прозрачный, пока не пытаешься в его модернизацию. Я только что перегрузил 4 класса, ради возможности изменить Ribbon Category.

Так риббон уже не WinAPI, а COM. И появился гораааздо позже. Потому прилеблен сбоку бантиком к MFC в т.ч.

Сути не меняет. Входит в стандартный пакет. Так что...

Sign up to leave a comment.

Articles