
Комментарии 35
Теперешний MFC - это старый MFC на стероидах. Когда-то Microsoft взяла библиотеку BCG Control Bar от https://bcgsoft.com/, которая была по сути была просто MFC Extension, и добавила её в саму MFC. Там у большинства классов просто префикс в названиях поменяли с CBCG* на CMFC* :-)
Вот поэтому для работы с интерфейсом Windows использую C# =)
Не знаю, насколько всё хорошо на данный момент, но пару лет назад WinForm умели хорошенько подвисать при большом количестве элементов.
Может быть, WinForms и не самый лучший вариант, но ведь есть и WPF.
(del)
Видимо нет, потому что дальше продолжили метания UWP, Avalonia, MAUI, WinUI, ... или может Веб =)
Возможности не ниже, чем у WinForms, но полностью нативно, позволяет создавать собственные библиотеки кастомных компонент, которые нормально обрабатываются линкером (а не как в C#, когда при использовании одного-единственного виджета в сборку добавляется вся библиотека целиком), очень быстро работает и не требует монструозного фреймворка.
Всё остальное по сравнению с VCL выглядит какими-то убогими студенческими поделками.
Теперешний MFC - это старый MFC на стероидах. Когда-то Microsoft взяла библиотеку BCG Control Bar от https://bcgsoft.com/, которая была по сути была просто MFC Extension, и добавила её в саму MFC. Там у большинства классов просто префикс в названиях поменяли с CBCG* на CMFC* :-)
BGC куда лучше выглядит по сей день, но и требует монету.
Там не самая большая цена, особенно для компании. При этом большой плюс, что библиотека поставляется с исходниками.
А ещё была (есть?) конкурирующая библиотека CodeJock Extreme Toolkit
А тут уже объясняем, в чём не прав стандартный конструктор MFC
Несколько раз перечитал раздел, но не нашел никакого объяснения...
Когда-нибудь я перестану использовать псевдо "твитовый" сленг. В общем, Ribbon верстается визуально, однако набор компонентов для этого дела сильно ограничен. Есть несколько вариантов - добавлять ручками (что тоже запарно), либо делать хак с забиванием поля "Keys" юзердатой и верстать по ней элементы, перегружаю функцию констракта.
Никогда офис не использовал MFC для GUI. Подозреваю что Vusual Studio - тоже
На самом деле MFC удобен тем, что это решение из коробки. Не нужно заморачиваться со всякими сторонними решениями, тем более, что его редактор уже по умолчанию встроен в MSVC, да и динамическая линковка позволяет добиться минимального размера программы. А все нужные библиотеки уже стоят у большинства клиентов, в крайнем случае поставят redistributable c++ и все должно заработать.
Привет от ImGUI в 1 файл
Да согласен, но повторюсь тут вариант из коробки. Так то всегда можно QT, или MXToolkit или ещё множество других вариантов.
На рабочем проекте была задача написать редактор на MFC.
По-моему, именно здесь источник проблем. Нужен ли сам редактор, это отдельный вопрос, а насчет MFC, мнение сложилось давно. Его нужно, по возможности, избегать.
В свое время, MFC мне нравился, и я писал на нем свои проекты и даже публиковал статьи на codeproject.com и sql.ru. Но, к моему удивлению, всегда встречал комментарии, почему MFC? Ибо он такой, сякой и т.п. Главные обвинения – сложный и непрозрачный, особенно, если хочешь отклониться от генеральной линии. На что я отвечал, да, но зато мозги тренирует, заставляет изворачиваться и изощряться. В то время не были опубликованы исходники MFC, думаю, мне бы тогда они сильно помогли. А сейчас они уже не интересны.
Однако, «капля камень точит» и я тоже, постепенно, пришел к мнению, что в MFC что-то не так. Начал искать альтернативу: Qt, wxWidgets, Win32xx, WTL, WinApi. Все эти фрейморки весьма хороши для своих целей, но лично мне более всего подходят последние два.
Поэтому, главный вопрос это как уйти от MFC? Ну, или «колоться и продолжать есть кактус».
До сих пор крупнейшие проекты пишутся на MFC
MFC В 2022