MFC В 2022

Зачем и почему

Как бы мне не хотелось ответить на этот вопрос… Но ответа я не знаю. На рабочем проекте была задача написать редактор на MFC. Да, да… На MFC. Для тех, кто не знает, MFC — графическая библиотека от Microsoft, на которой стояли Microsoft Office и Visual Studio до 2010 года и выглядит примерно вот так:

Документация

Хоть и компания Microsoft любит делать подробную документацию для своих творений, но с MFC ситуация оказалась иная. Хоть он и имеет в районе 100 страниц на msdn (я знаю, что сайт переехал, но привычки не меняются), но это только на первый взгляд. Как только вам приходится делать что-то серьёзное, касаемо самих контролов, можете о ней забыть. Придётся выкачивать символы и исходный код данной библиотеки и разбираться в отладчике, вникая в аспекты UI библиотеки построенной на событиях. Ладно, у меня слишком много накипело и вводную я могу писать вечно, так что перейдём к сути.

Убийца #1 — Visual Manager

Если кто-то заходил дальше диалоговых окон, то знает что есть режимы SDI и MDI, которые представляют собой полноценное окно с табами(и без них). И их визуализацией занимается как раз таки Visual Manager (нет), у которого даже есть множество тем, начиная с WinXP и заканчивая Windows 7. (+VS и MSOffice)

На самом деле VisualManager выполняет весьма скудную роль в этом деле. Он контролирует Ribbon, PropertyGrid, MDI Tabs, Toolbar (который CMFCToolbar. Их там несколько, ребят), Header и Caption Bar. Но если же вы хотите сделать нечто следующее:

То вам придётся знакомится с событиями WM_PAINT, WM_CLRCTL (а ещё и иногда с *_NC_ аналогами этих событий) и перегружать все наши любимые кнопки, текстбоксы и статики. Помимо этого, добавлять в DocablePane функции, которые будут указывать для DC цвет текста и фона для CTreeCtrl.

Убийца #2 — PropertyGrid

Думаю, всем известно, что пропы это весьма обширная UI часть и везде нам не нравится их реализация. Помните, я говорил, что Visual Manager отвечает за их отрисовку? В данном случае, лучше бы он этого не делал. Почему? Представьте что вам нужен кастомный проп, в котором должна быть кнопка, или несколько… Но… У пропа всего 1 hwnd, что не позволяет вам быстрой перегрузкой докинуть кнопку в его содержимое. И тут уже идёт магия с созданием алгоритмов просчёта позиции.

Ситуация 2: Диалоговые окна.
К несчастью, при использовании CMFCPropertyGridCtrl в диалоговых окнах, можно встретить неправильный width:

Данная проблема решается перегрузкой класса следующим образом:

 class CDialogPropertyGridControl : public CMFCPropertyGridCtrl { public:     CDialogPropertyGridControl()     {         m_nLeftColumnWidth = 100;     }      void make_fixed_header()     {         HDITEM hdItem = { 0 };         hdItem.mask = HDI_FORMAT;         GetHeaderCtrl().GetItem(0, &hdItem);         hdItem.fmt |= HDF_FIXEDWIDTH;         GetHeaderCtrl().SetItem(0, &hdItem);     }      void SetLeftColumnWidth(int cx)     {         m_nLeftColumnWidth = cx;         AdjustLayout();     }      void OnSize(UINT f, int cx, int cy)     {         EndEditItem();         if (cx > 50)             m_nLeftColumnWidth = cx - 50; //<- 2nd column will be 50 pixels         AdjustLayout();     }      DECLARE_MESSAGE_MAP() };

Честно говоря, быстрее выйдет написать свой PropertyGrid, если Вам придётся часто с ним работать. Т.к. если не брать в расчёт предыдущие аспекты, сам по себе он вызывает очень громоздкий код, который придётся обвешивать get/set на каждый чих. За два вечера я смог написать базовый проп под свои нужды, который работает напрямую с передаваемой переменной и имеет тот же функционал:

Убийца #3 — RibbonBar

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

Шаг 1 — Новый класс для Ribbon

Для начала надо объяснить MFC, что мы будем использовать кастомый конструктор для Ribbon. Перегружаем функцию LoadFromResource

BOOL XRibbonBar::LoadFromResource(LPCTSTR lpszXMLResID, LPCTSTR lpszResType /*= RT_RIBBON*/, HINSTANCE hInstance /*= NULL*/) { ASSERT_VALID(this);  CMFCRibbonInfo info; CMFCRibbonInfoLoader loader(info);  if (!loader.Load(lpszXMLResID, lpszResType, hInstance)) { TRACE0("Cannot load ribbon from resource\n"); return FALSE; }  XRibbonConstructor constr(info); constr.ConstructRibbonBar(*this);  return TRUE; }

Шаг 2 — Конструктор

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

  CMFCRibbonBaseElement* XRibbonConstructor::CreateElement(const CMFCRibbonInfo::XElement& info) const { if (info.GetElementType() == CMFCRibbonInfo::e_TypeButton_Check) { const CMFCRibbonInfo::XElementButtonCheck& infoElement = (const CMFCRibbonInfo::XElementButtonCheck&)info;  // RadioBox if (strstr(info.m_strKeys, "RB")) { // Make friends list string TryStr = info.m_strKeys.operator LPCSTR(); TryStr = TryStr.substr(2); int ID = atoi_17(TryStr);  XRibbonRadioBox* pNewElement = new XRibbonRadioBox(infoElement.m_ID.m_Value, infoElement.m_strText);  ConstructBaseElement(*pNewElement, info); return pNewElement; } }  return CMFCRibbonConstructor::CreateElement(info); } 

strstr(info.m_strKeys, «RB») — Это флаг в визуальном редакторе, благодаря которому мы можем впихнуть кучу UserInfo

P.S.

Хочется сказать большое спасибо людям с CodeProject и StackOverflow за огромное количество подсказок при глубокой работе с данным UI API.

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

https://github.com/ForserX/XMFC