Comments 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* :-)
А тут уже объясняем, в чём не прав стандартный конструктор MFC
Несколько раз перечитал раздел, но не нашел никакого объяснения...
Когда-нибудь я перестану использовать псевдо "твитовый" сленг. В общем, Ribbon верстается визуально, однако набор компонентов для этого дела сильно ограничен. Есть несколько вариантов - добавлять ручками (что тоже запарно), либо делать хак с забиванием поля "Keys" юзердатой и верстать по ней элементы, перегружаю функцию констракта.
Никогда офис не использовал MFC для GUI. Подозреваю что Vusual Studio - тоже
На самом деле MFC удобен тем, что это решение из коробки. Не нужно заморачиваться со всякими сторонними решениями, тем более, что его редактор уже по умолчанию встроен в MSVC, да и динамическая линковка позволяет добиться минимального размера программы. А все нужные библиотеки уже стоят у большинства клиентов, в крайнем случае поставят redistributable c++ и все должно заработать.
На рабочем проекте была задача написать редактор на MFC.
По-моему, именно здесь источник проблем. Нужен ли сам редактор, это отдельный вопрос, а насчет MFC, мнение сложилось давно. Его нужно, по возможности, избегать.
В свое время, MFC мне нравился, и я писал на нем свои проекты и даже публиковал статьи на codeproject.com и sql.ru. Но, к моему удивлению, всегда встречал комментарии, почему MFC? Ибо он такой, сякой и т.п. Главные обвинения – сложный и непрозрачный, особенно, если хочешь отклониться от генеральной линии. На что я отвечал, да, но зато мозги тренирует, заставляет изворачиваться и изощряться. В то время не были опубликованы исходники MFC, думаю, мне бы тогда они сильно помогли. А сейчас они уже не интересны.
Однако, «капля камень точит» и я тоже, постепенно, пришел к мнению, что в MFC что-то не так. Начал искать альтернативу: Qt, wxWidgets, Win32xx, WTL, WinApi. Все эти фрейморки весьма хороши для своих целей, но лично мне более всего подходят последние два.
Поэтому, главный вопрос это как уйти от MFC? Ну, или «колоться и продолжать есть кактус».
До сих пор крупнейшие проекты пишутся на MFC
MFC В 2022