Mfc что это за программа

Содержание

Лекция 4. Обзор библиотеки MFC

Microsoft Foundation Classes (сокращенно MFC) – это библиотека классов на языке Си++, разработанная фирмой Microsoft в качестве объектно-ориентированной оболочки для Windows API. Существуют и другие библиотеки классов для Windows, но преимущество MFC в том, что она написана компанией-разработчиком ОС. MFC постоянно развивается, чтобы соответствовать возможностям новых версий Windows.

MFC содержит около 200 классов, представляющих практически все необходимое для написания Windows-приложений: от окон до элементов управления ActiveX. Одни классы можно использовать непосредственно, а другие – в качестве базовых для создания новых классов. Некоторые классы MFC очень просты, например, класс CPoint для хранения двумерных координат точки.

Другие классы являются более сложными, например, класс CWnd инкапсулирует функциональность окна Windows. В приложении MFC напрямую вызывать функции Windows API приходится редко. Вместо этого программист создает объекты классов MFC и вызывает их функции-члены.

Изучаем С++ MFC Часть 1

В MFC определены сотни функций-членов, которые служат оболочкой функций API, и часто их имена совпадают с именами соответствующих функций API. Например, для изменения местоположения окна в API есть функция SetWindowPos. В MFC это действие выполняется с помощью функции-члена CWnd::SetWindowPos.

MFC является не просто библиотекой классов, она также предоставляет программисту каркас приложения. Это заготовка приложения, содержащая набор классов и функций для выполнения типичных операций приложения Windows, например, по созданию главного окна, работе с главным меню и т.п. Программист может разрабатывать собственное приложение, перегружая виртуальные функции классов каркаса и добавляя в него новые классы. Центральное место в каркасе приложения MFC занимает класс-приложение CWinApp. В нем скрыты самые общие аспекты работы приложения, например, главный цикл обработки сообщений.

В каркасе приложения MFC есть понятия высокого уровня, которых нет в Windows API. Например, архитектура «документ/вид» является мощной инфраструктурой, надстроенной над API и позволяющей отделить данные программы от их графического представления. Эта архитектура отсутствует в API и полностью реализована в каркасе приложения с помощью классов MFC.

1.1 Преимущества использования Си++/MFC по сравнению с Си/Windows API

При разработке программ для Windows на языке Си с использованием функций API возникает ряд сложностей. Функций и сообщений Windows очень много, их тяжело запомнить. Оконные процедуры на Си принимают характерную и трудно читаемую форму в виде обширных операторов switch, часто вложенных друг в друга.

Объектно-ориентированное проектирование имеет ряд преимуществ по сравнению со структурным при разработке больших проектов: легче создавать повторно используемые компоненты, есть более гибкие средства скрытия данных и процедур.

Применительно к программированию для Windows можно сказать, что без готовой библиотеки классов ООП дает весьма незначительное уменьшение количества исходного текста, который должен написать программист. Основные преимущества ООП проявляются при использовании библиотеки классов – т.е. набора повторно используемых компонент. Эти компоненты облегчают решение типичных задач, например, для добавления в приложение MFC стыкуемой панели инструментов можно использовать класс CToolBar, которому надо только указать параметры кнопок панели. Использовать сложные технологии Windows, например, технологии ActiveX (в том числе COM и OLE) без готовых классов практически невозможно.

M&C Платформа ставки на спорт Обзор и Регистрация МС

Еще одно преимущество, предоставляемое MFC, – это готовый каркас приложения. Он устроен таким образом, что объекты Windows (окна, диалоговые окна, элементы управления и др.) выглядят в программах как объекты классов Си++.

Основные задачи проектирования MFC

При проектировании MFC перед разработчиками Microsoft стояли две основных задачи:

1) MFC должна служить объектно-ориентированным интерфейсом для доступа к API операционных систем семейства Windows с помощью повторно используемых компонент – классов.

2) накладные расходы по времени вычислений и по объему памяти при использовании MFC должны быть минимальны.

Для достижения первой цели были разработаны классы, инкапсулирующих окна, диалоговые окна и другие объекты операционной системы. В этих классах было предусмотрено много виртуальных функций, которые можно перегружать в производных классах и таким образом модифицировать поведение объектов ОС.

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

Эта информация скрыта от приложений, которые работают с окнами исключительно посредством дескрипторов (переменных типа HWND). В MFC «оболочкой» окна является класс CWnd. Но в нем нет переменных-членов, дублирующих все свойства окна с заданным HWND. В классе CWnd хранится только дескриптор окна. Для этого заведена открытая переменная-член CWnd::m_hWnd типа HWND.

Когда программист запрашивает у объекта CWnd какое-нибудь свойство окна (напр., заголовок), то этот объект вызывает соответствующую функцию API, а затем возвращает полученный результат.

Описанная схема применяется в MFC для реализации практически всех классов, служащих оболочками объектов Windows, т.е. внутри этих классов хранятся только дескрипторы объектов.

1.3 Архитектура «документ/вид»

В устройстве каркаса приложения MFC важнейшую роль играет архитектура «документ/вид». Это такой способ проектирования приложения, когда в нем отдельно создаются объекты-документы, ответственные за хранение данных приложения, и объекты-виды, ответственные за отображение этих данных различными способами. Базовыми классами для документов и видов в MFC служат классы CDocument и CView. Классы каркаса приложения CWinApp, CFrameWnd и др. работают совместно с CDocument и CView, чтобы обеспечить функционирование приложения в целом. Сейчас пока рано обсуждать детали архитектуры «документ/вид», но вы должны, как минимум, знать термин «документ/вид», часто упоминаемый при рассмотрении MFC.

Приложения MFC можно писать и без использования документов и видов (например, при изучении основ MFC). Но доступ к большинству возможностей каркаса возможен только при поддержке архитектурs «документ/вид». В действительности это не является жестким ограничением структуры приложения, и большинство программ, обрабатывающих документы какого-либо типа, могут быть преобразованы в эту архитектуру. Не следует думать (по аналогии с термином «документ»), что эта архитектура полезна только для написания текстовых редакторов и электронных таблиц. «Документ» – это абстрактное представление данных программы в памяти компьютера. Например, документ может быть просто массивом байт для хранения игрового поля компьютерной игры, или он действительно может быть электронной таблицей.

Приложения MFC для рабочего стола

Библиотека Microsoft Foundation Class (MFC) предоставляет объектно-ориентированную программу-оболочку для многих API Win32 и COM. Хотя ее можно использовать для создания очень простых классических приложений, в наибольшей степени она полезна при разработке сложных пользовательских интерфейсов с многочисленными элементами управления. MFC 11.0 можно использовать для создания приложений с пользовательскими интерфейсами в стиле Office. документацию по самой платформе Windows см. в документации по Windows. сведения о создании Windows приложений на C++ без MFC см. в разделе сборка настольных Windows приложений с помощью API Win32.

Справочник по MFC описывает классы, глобальные функции, глобальные переменные и макросы, составляющие библиотеку MFC.

Отдельные диаграммы иерархии, поставляемые с каждым классом, полезны для обнаружения базовых классов. Справочник MFC обычно не описывает наследуемые функции-члены или наследуемые операторы. Сведения об этих функциях см. в базовых классах, описанных в диаграммах иерархий.

Документация для каждого класса содержит общие сведения о классах, сводку элементов по категориям и разделы для функций-членов, перегруженных операторов и данных-членов.

Открытые и защищенные члены класса фиксируются документально, только если они стандартно используются в прикладных программах или производных классах. См. файлы заголовков классов для получения полного списка членов класса.

классы MFC и их члены нельзя использовать в приложениях, которые выполняются в среде среда выполнения Windows.

Библиотеки MFC (DLL) для кодирования многобайтовых символов (MBCS) больше не включается в Visual Studio, однако доступны как дополнительный компонент Visual Studio. Дополнительные сведения см. в разделе надстройка MFC MBCS DLL.

в этом разделе

Иерархическая диаграмма
Визуально представляет связи класса в библиотеке классов.

Общие сведения о классах
Перечисляет классы в библиотеке MFC по категориям.

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

Технические примечания
Содержит ссылки на разделы, которые специализированные командой разработки MFC, в библиотеке классов.

Настройка для MFC
Предоставляет советы по пользовательской настройке приложения MFC.

Классы
Предоставляет ссылки и данные файла заголовка для классов MFC.

Внутренние классы
Для внутреннего использования в MFC. В данном разделе эти внутренние классы описываются с целью предоставления полной информации, но они не предназначены для непосредственного использования в коде.

Макросы и глобальные объекты
Предоставляет ссылки на глобальные функции и макросы в библиотеке MFC.

Структуры, стили, обратные вызовы и схемы сообщений
Предоставляет ссылки на структуры, стили, обратные вызовы и схемы сообщений, используемых библиотекой MFC.

Мастера и диалоговые окна MFC
Руководство по функциям и компонентам в Visual Studio для создания приложений MFC.

Работа с файлами ресурсов
Использование файлов ресурсов для управления данными статического пользовательского интерфейса, такими как строки пользовательского интерфейса и макеты диалоговых окон.

Связанные разделы

Категории иерархических диаграмм
Описывает диаграммы иерархии MFC по категориям.

Общие классы ATL и MFC
Предоставляет ссылки на классы, которые совместно используются MFC и библиотекой ATL.

Примеры MFC
Содержит ссылки на примеры использования MFC.

Справочные материалы по библиотекам Visual C++
Содержит ссылки на различные библиотеки, входящие в состав Visual C++, включая шаблоны ATL, MFC, OLE DB, библиотеку времени выполнения языка C, а также стандартную библиотеку C++.

Отладка в Visual Studio
Ссылки на разделы, описывающие использование отладчика Visual Studio для устранения логических ошибок в приложениях и хранимых процедурах.

Источник: learn.microsoft.com

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. Но если же вы хотите сделать нечто следующее:

Убийца #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.fmt |= HDF_FIXEDWIDTH; GetHeaderCtrl().SetItem(0, > void SetLeftColumnWidth(int cx) < m_nLeftColumnWidth = cx; AdjustLayout(); >void OnSize(UINT f, int cx, int cy) < EndEditItem(); if (cx >50) m_nLeftColumnWidth = cx — 50; // 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 resourcen»); return FALSE; >XRibbonConstructor constr(info); constr.ConstructRibbonBar(*this); return TRUE; >

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

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

CMFCRibbonBaseElement* XRibbonConstructor::CreateElement(const CMFCRibbonInfo::XElement if (info.GetElementType() == CMFCRibbonInfo::e_TypeButton_Check) < 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 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 я перевёл в общий стандарт и опубликовал по ссылке ниже. Скорее всего, данный репозиторий будет со временем пополняться. Надеюсь, кому-то данная библиотека решений сократит пару десятков часов.

Источник: habr.com

Библиотека классов MFC

Аннотация: В данной лекции подробно рассматривается иерархия классов MFC, описывается и разбирается процесс обработки сообщений в MFC, осуществляется знакомство с элементами управления, диалогами и графикой, в заключении приводится пример разработки Windows-приложения с использованием всех полученных знаний и навыков.

Microsoft Foundation Classes (MFC). Иерархия классов

MFC – это библиотека классов, написанных на языке C++. MFC является оболочкой для Win32 API и содержит многоуровневую иерархию классов. Не все функции Win32 API включены в MFC . С другой стороны, эта библиотека классов охватывает большую часть функциональных возможностей Windows , и предоставляет разработчику ряд дополнительных механизмов для проектирования и создания программных продуктов.

На вершине иерархии MFC находится единственный базовый класс – CObject. Все остальные классы библиотеки MFC можно условно разбить на две группы: производные и не производные от него. Чаще всего, создание нового MFC -приложения поручается мастеру MFC Application Wizard . Мастер генерирует основной скелет приложения, который впоследствии заполняется нужным кодом, давая готовое приложение .

Основные классы MFC

Некоторые классы MFC порождаются непосредственно от CObject . Наиболее широко используемыми среди них являются CCmdTarget, CFile, CDC , CGDIObject и CMenu . Класс CCmdTarget предназначен для обработки сообщений. Класс CFile предназначен для работы с файлами. Класс CDC обеспечивает поддержку контекстов устройств. В этот класс включены практически все функции графики GDI.

CGDIObject является базовым классом для различных GDI-объектов, таких как перья, кисти, шрифты и другие. Класс СMenu предназначен для работы меню.

Класс CCmdTarget

От класса CCmdTarget порождается очень важный класс CWnd . Он является базовым для создания всех типов окон, включая масштабируемые («обычные») и диалоговые, а также различные элементы управления. Наиболее широко используемым производным классом является CFrameWnd . В большинстве программ главное окно создается с помощью именно этого класса. От класса CCmdTarget , через класс CWinThread , порождается единственный из наиболее важных классов, обращение к которому в MFC-программах происходит напрямую, это класс CWinApp . Это один из фундаментальных классов, поскольку предназначен для создания самого приложения. В каждой программе имеется один и только один объект этого класса. Как только он будет создан, приложение начнет выполняться.

Класс CWinApp

Класс CWinApp является базовым классом, на основе которого образуют обязательный объект – приложение Windows. Основными задачами объекта этого класса являются инициализация и создание главного окна, а затем опрос системных сообщений. Иерархия класса CWinApp : CObject -> CCmdTarget -> CWinThread -> CWinApp

Класс CFrameWnd («окна-рамки») и производные от него классы определяют окна-рамки на мониторе. Элементы управления, создаваемые при проектировании интерфейса пользователя, принадлежат семейству классов элементов управления.

Появляющиеся в процессе работы приложения диалоговые окна – это объекты классов, производных от CDialog . Классы CView, CFrameWnd, CDialog и все классы элементов управления наследуют свойства и поведение своего базового класса CWnd («окно»), определяющего, по существу, Windows-окно. Этот класс, в свою очередь, является наследником базового класса CObject («объект»). Как правило, структура приложения определяется архитектурой Document-View (документ-вид). Это означает, что приложение состоит из одного или нескольких документов – объектов, классы которых являются производными от класса CDocument (класс «документ»). С каждым из документов связаны один или несколько видов – объектов классов, производных от CView (класс «вид» ), и определяющих методы обработки объектов класса документа.

Соглашение об именах MFC

В качестве префикса, обозначающего имя класса, библиотека MFC использует заглавную букву «C» (от слова «class»), за которой идет имя, характеризующее назначение класса. Например:

CWinApp – класс, определяющий приложение;
CWnd – базовый класс для всех оконных объектов;
CDialog – класс диалога.

При определении имен функций-членов классов используется три варианта:

Имя объединяет глагол и существительное – DrawText (нарисовать текст).
Имя состоит только из существительного – DialogBox (блок диалога).
Для функций, предназначенных для преобразования одного типа в другой, используются такие имена, как XtoY (из X в Y).

Для членов классов библиотеки MFC используется следующий способ назначения имен: обязательный префикс m_ (от class member – член класса), за которым идет префикс, характеризующий тип данных, и завершается все заданием содержательного имени переменной. Например, m_pMainWnd – указатель на класс главного окна. Для переменных, которые не являются членами класса, m_ не ставится.

Включаемые файлы

AFXWIN.H – содержит описание основных классов библиотеки и сводит воедино все включаемые файлы, необходимые для работы MFC.

AFX.H – содержит описания классов общего назначения, макросы, базовые типы данных MFC.

AFXRES.H – подключает стандартные идентификаторы ресурсов.

Обработка сообщений в MFC

Операционная система Windows взаимодействует с приложением, посылая ему сообщения. Таким образом, обработка сообщений является ядром всех приложений. В традиционных приложениях Windows (написанных с использованием только API ), каждое сообщение передается в качестве аргументов оконной функции . В оконной функции , с помощью оператора switch , определяется тип сообщения , извлекается информация и производятся нужные действия. Используя библиотеку MFC , все это можно сделать проще.

Карта сообщений

Для создания стандартного окна в приложении должен наследоваться класс от CFrameWnd . Он содержит конструктор и макрос DECLARE_MESSAGE_MAP() . Макрос декларирует карту сообщений, которая определяет, какая член-функция класса должна вызываться в ответ на сообщение Windows. Этот макрос применяется для любого окна, в котором обрабатываются сообщения. Он должен быть последним в декларировании класса, использующего карту сообщений. В конце программы помещается реализация карты сообщений:

BEGIN_MESSAGE_MAP(CMainWnd /*класс окна*/, CFrameWnd /* класс-предок */) END_MESSAGE_MAP()

Первый макрос всегда имеет два параметра, первый – класс окна, второй – класс, от которого порожден класс окна. В данном примере карта сообщений пустая, то есть все сообщения обрабатывает MFC.

В библиотеке MFC все возможные сообщения разделены на три основные категории:

сообщения Windows;
извещения элементов управления;
командные сообщения (команды).

В первую категорию входят сообщения, имена которых начинаются с префикса WM_ , за исключением WM_COMMAND . Во вторую категорию входят извещения ( notification messages ) от элементов управления и дочерних окон, направляемых родительским окнам. Третья категория охватывает все сообщения WM_COMMAND , называемых командами (командными сообщениями), от объектов интерфейса пользователя, который включает меню, кнопки панелей инструментов и акселераторы.

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

Включить в карту сообщений программы команду соответствующего сообщения.
Включить прототип функции-обработчика в описание класса, ответственного за обработку данного сообщения.
Включить в программу реализацию функции-обработчика.

Включение макрокоманд в карту сообщений

Чтобы программа могла ответить на сообщение, в карту сообщений должна быть включена соответствующая макрокоманда. Названия макрокоманд соответствуют именам стандартных сообщений Windows, но дополнительно имеют префикс ON_ и заканчиваются парой круглых скобок. Из этого правила есть исключение: сообщению WM_COMMAND соответствует макрокоманда ON_COMMAND(. ) . Причина в том, что это сообщение обрабатывается особым образом. Чтобы включить макрокоманду в очередь сообщений, необходимо поместить ее между командами BEGIN_MESSAGE_MAP(…) и END_MESSAGE_MAP() . Например, если необходимо обработать в программе сообщение WM_CHAR , то очередь должна выглядеть так:

BEGIN_MESSAGE_MAP(CMainWnd, CFrameWnd) ON_WM_CHAR() END_MESSAGE_MAP()

В очереди может находиться более одной макрокоманды. Сообщение WM_CHAR генерируется при нажатии алфавитно-цифровой клавиши на клавиатуре.

Включение обработчиков сообщений в описание класса Каждое сообщение, явно обрабатываемое в программе, должно быть связано с одним из обработчиков.

Обработчик – это член-функция класса, вызываемая приложением в ответ на сообщение, связанное с ней с помощью карты сообщений.

Прототипы для обработчиков всех сообщений заранее заданы в MFC. Например, объявим класс с обработчиком сообщения WM_PAINT . Это сообщение посылается окну, когда оно должно перерисовать свою клиентскую область.

Class CMainWnd: public CFrameWnd

Спецификатор afx_msg означает объявление обработчика сообщения. На данный момент он не используется и представляет собой пустой макрос. Но в будущем возможны расширения. Поэтому использование спецификатора нужно считать обязательным. Для каждого обработчика должна быть описана его реализация.

В ней могут производиться самые разные действия, которые требуются по логике работы программы.

Сообщение WM_PAINT

Операционная система Windows устроена таким образом, что за обновление содержимого окна отвечает программа. Например, если часть окна была перекрыта другим окном, а затем вновь открыта, или минимизированное окно было восстановлено, то окну посылается сообщение WM_PAINT . В ответ на него окно должно обновить свою клиентскую область. Прототип обработчика WM_PAINT следующий:

afx_msg void OnPaint();

Макрокоманда называется ON_WM_PAINT() .

Для примера создадим обработчик, который выводит строку «Использование OnPaint()» в клиентскую область по координатам x = 25, y = 25:

afx_msg void CMainWnd::OnPaint()

В обработчике WM_PAINT нужно всегда пользоваться классом CPaintDC , который представляет собой класс клиентской области, но предназначенный для использования именно с этим сообщением. Это обусловлено архитектурой самой Windows. Функция TextOut(…) предназначена для вывода текста в контекст устройства (в данном случае – в окно).

При ее использовании, по умолчанию первые два параметра определяют координаты верхнего левого угла текстовой строки. По умолчанию координаты представляют собой реальные пиксели, ось x направлена слева направо, ось y – сверху вниз. Эта функция перегруженная, наиболее удобный для нас вариант – когда третий параметр имеет тип CString . Этот класс входит в MFC и является очень удобной заменой для строк, завершаемых нулем. Большинство реальных окон (за исключением диалогов) должны обрабатывать сообщение WM_PAINT . Более того, если Вы хотите написать корректную программу, то весь вывод в окно должен осуществляться только в обработчике WM_PAINT . В случае получения контекста из обработчика WM_PAINT с помощью класса CPaintDC , Windows гарантирует наличие свободного контекста.

Источник: intuit.ru