mfc类库大全编程频道|福州电脑网

2024年3月6日发(作者：)

1. MFC概述

1. MFC是一个编程框架

MFC (Microsoft Foundation Class Library)中的各种类结合起来构成了一个应用程序框架，它的目的就是让程序员在此基础上来建立Windows下的应用程序，这是一种相对SDK来说更为简单的方法。因为总体上，MFC框架定义了应用程序的轮廓，并提供了用户接口的标准实现方法，程序员所要做的就是通过预定义的接口把具体应用程序特有的东西填入这个轮廓。Microsoft Visual C++提供了相应的工具来完成这个工作：AppWizard可以用来生成初步的框架文件（代码和资源等）；资源编辑器用于帮助直观地设计用户接口；ClassWizard用来协助添加代码到框架文件；最后，编译，则通过类库实现了应用程序特定的逻辑。

1. 封装

构成MFC框架的是MFC类库。MFC类库是C++类库。这些类或者封装了Win32应用程序编程接口，或者封装了应用程序的概念，或者封装了OLE特性，或者封装了ODBC和DAO数据访问的功能，等等，分述如下。

（1）对Win32应用程序编程接口的封装

用一个C++ Object来包装一个Windows Object。例如：class

CWnd是一个C++ window object，它把Windows window(HWND)和Windows window有关的API函数封装在C++ window

object的成员函数内，后者的成员变量m_hWnd就是前者的窗口句柄。

（2）对应用程序概念的封装

使用SDK编写Windows应用程序时，总要定义窗口过程，登记Windows Class，创建窗口，等等。MFC把许多类似的处理封装起来，替程序员完成这些工作。另外，MFC提出了以文档-视图为中心的编程模式，MFC类库封装了对它的支持。文档是用户操作的数据对象，视图是数据操作的窗口，用户通过它处理、查看数据。

（3）对COM/OLE特性的封装

OLE建立在COM模型之上，由于支持OLE的应用程序必须实现一系列的接口（Interface），因而相当繁琐。MFC的OLE类封装了OLE API大量的复杂工作，这些类提供了实现OLE的更高级接口。

（4）对ODBC功能的封装

以少量的能提供与ODBC之间更高级接口的C++类，封装了ODBC API的大量的复杂的工作，提供了一种数据库编程模式。

2. 继承

首先，MFC抽象出众多类的共同特性，设计出一些基类作为实现其他类的基础。这些类中，最重要的类是CObject和CCmdTarget。CObject是MFC的根类，绝大多数MFC类是其派生的，包括CCmdTarget。CObject 实现了一些重要的特性，包括动态类信息、动态创建、对象序列化、对程序调试的支持，等等。所有从CObject派生的类都将具备或者可以具备CObject所拥有的特性。CCmdTarget通过封装一些属性和方法，提供了消息处理的架构。MFC中，任何可以处理消息的类都从CCmdTarget派生。

针对每种不同的对象，MFC都设计了一组类对这些对象进行封装，每一组类都有一个基类，从基类派生出众多更具体的类。这些对象包括以下种类：窗口对象，基类是CWnd；应用程序对象，基类是CwinThread；文档对象，基类是Cdocument，等等。

程序员将结合自己的实际，从适当的MFC类中派生出自己的类，实现特定的功能，达到自己的编程目的。

3. 虚拟函数和动态约束

MFC以“C++”为基础，自然支持虚拟函数和动态约束。但是作为一个编程框架，有一个问题必须解决：如果仅仅通过虚拟函数来支持动态约束，必然导致虚拟函数表过于臃肿，消耗内存，效率低下。例如，CWnd封装 Windows窗口对象时，每一条Windows消息对应一个成员函数，这些成员函数为派生类所继承。如果这些函数都设计成虚拟函数，由于数量太多，实现起来不现实。于是，MFC建立了消息映射机制，以一种富有效率、便于使用的手段解决消息处理函数的动态约束问题。

这样，通过虚拟函数和消息映射，MFC类提供了丰富的编程接口。程序员继承基类的同时，把自己实现的虚拟函数和消息处理函数嵌入MFC的编程框架。MFC编程框架将在适当的时候、适当的地方来调用程序的代码。本书将充分的展示MFC调用虚拟函数和消息处理函数的内幕，让读者对MFC的编程接口有清晰的理解。

4. MFC的宏观框架体系

如前所述，MFC实现了对应用程序概念的封装，把类、类的继承、动态约束、类的关系和相互作用等封装起来。这样封装的结果对程序员来说，是一套开发模板（或者说模式）。针对不同的应用和目的，程序员采用不同的模板。例如，SDI应用程序的模板，MDI应用程序的模板，规则DLL应用程序的模板，扩展DLL应用程序的模板，OLE/ACTIVEX应用程序的模板，等等。

这些模板都采用了以文档-视为中心的思想，每一个模板都包含一组特定的类。典型的MDI应用程序的构成将在下一节具体讨论。

为了支持对应用程序概念的封装，MFC内部必须作大量的工作。例如，为了实现消息映射机制，MFC编程框架必须要保证首先得到消息，然后按既定的方法进行处理。又如，为了实现对DLL编程的支持和多线程编程的支持，MFC内部使用了特别的处理方法，使用模块状态、线程状态等来管理一些重要信息。虽然，这些内部处理对程序员来说是透明的，但是，懂得和理解MFC内部机制有助于写出功能灵活而强大的程序。

总之，MFC封装了Win32 API，OLE API，ODBC API等底层函数的功能，并提供更高一层的接口，简化了Windows编程。同时，MFC支持对底层API的直接调用。

MFC提供了一个Windows应用程序开发模式，对程序的控制主要是由MFC框架完成的，而且MFC也完成了大部分的功能，预定义或实现了许多事件和消息处理，等等。框架或者由其本身处理事件，不依赖程序员的代码；或者调用程序员的代码来处理应用程序特定的事件。

MFC是C++类库，程序员就是通过使用、继承和扩展适当的类来实现特定的目的。例如，继承时，应用程序特定的事件由程序员的派生类来处理，不感兴趣的由基类处理。实现这种功能的基础是C++对继承的支持，对虚拟函数的支持，以及MFC实现的消息映射机制。

2. MDI应用程序的构成

本节解释一个典型的MDI应用程序的构成。

用AppWizard产生一个MDI工程t（无OLE等支持），AppWizard创建了一系列文件，构成了一个应用程序框架。这些文件分四类：头文件（.h），实现文件(.cpp)，资源文件(.rc)，模块定义文件(.def)，等。

1. 构成应用程序的对象

图1-1解释了该应用程序的结构，箭头表示信息流向。

从CWinApp、CDocument、CView、CMDIFrameWnd、CMDIChildWnd类对应地派生出CTApp、CTDoc、CTView、CMainFrame、CChildFrame五个类，这五个类的实例分别是应用程序对象、文档对象、视对象、主框架窗口对象和文档边框窗口对象。主框架窗口包含了视窗口、工具条和状态栏。对这些类或者对象解释如下。

（1）应用程序

应用程序类派生于CWinApp。基于框架的应用程序必须有且只有一个应用程序对象，它负责应用程序的初始化、运行和结束。

（2）边框窗口

如果是SDI应用程序，从CFrameWnd类派生边框窗口类，边框窗口的客户子窗口(MDIClient)直接包含视窗口；如果是MDI应用程序，从CMDIFrameWnd类派生边框窗口类，边框窗口的客户子窗口(MDIClient)直接包含文档边框窗口。

如果要支持工具条、状态栏，则派生的边框窗口类还要添加CToolBar和CStatusBar类型的成员变量，以及在一个OnCreate消息处理函数中初始化这两个控制窗口。

边框窗口用来管理文档边框窗口、视窗口、工具条、菜单、加速键等，协调半模式状态（如上下文的帮助(SHIFT+F1模式)和打印预览）。

（3）文档边框窗口

文档边框窗口类从CMDIChildWnd类派生，MDI应用程序使用文档边框窗口来包含视窗口。

（4）文档

文档类从CDocument类派生，用来管理数据，数据的变化、存取都是通过文档实现的。视窗口通过文档对象来访问和更新数据。

（5）视

视类从CView或它的派生类派生。视和文档联系在一起，在文档和用户之间起中介作用，即视在屏幕上显示文档的内容，并把用户输入转换成对文档的操作。

（6）文档模板

文档模板类一般不需要派生。MDI应用程序使用多文档模板类CMultiDocTemplate；SDI应用程序使用单文档模板类CSingleDocTemplate。

应用程序通过文档模板类对象来管理上述对象（应用程序对象、文档对象、主边框窗口对象、文档边框窗口对象、视对象）的创建。

2. 构成应用程序的对象之间的关系

这里，用图的形式可直观地表示所涉及的MFC类的继承或者派生关系，如图1-2所示意。

图1-2所示的类都是从CObject类派生出来的；所有处理消息的类都是从CCmdTarget类派生的。如果是多文档应用程序，文档模板使用CMultiDocTemplae，主框架窗口从CMdiFarmeWnd派生，它包含工具条、状态栏和文档框架窗口。文档框架窗口从CMdiChildWnd派生，文档框架窗口包含视，视从CView或其派生类派生。

3. 构成应用程序的文件

通过上述分析，可知AppWizard产生的MDI框架程序的内容，所定义和实现的类。下面，从文件的角度来考察AppWizard生成了哪些源码文件，这些文件的作用是什么。表1-1列出了AppWizard所生成的头文件，表1-2列出了了AppWizard所生成的实现文件及其对头文件的包含关系。

表1-1 AppWizard所生成的头文件

头文件用途

stdafx.h 标准AFX头文件

resource.h 定义了各种资源ID

t.h #include "resource.h"

定义了从CWinApp派生的应用程序对象CTApp

childfrm.h 定义了从CMDIChildWnd派生的文档框架窗口对象CTChildFrame

mainfrm.h 定义了从CMDIFrameWnd派生的框架窗口对象CMainFrame

tdoc.h

tview.h

表1-2 AppWizard所生成的实现文件

实现文件

所包含的头文件

#include "stdafx.h"

# include "stdafx.h"

# include "t.h"

# include "MainFrm.h"

# include "childfrm.h"

#include "tdoc.h"

#include "tview.h"

#inlcude "stdafx.h"

#include "t.h"

#include “childfrm.h”

实现了类CChildFrame

实现的内容和功能

用来产生预编译的类型信息。

定义CTApp的实现，并定义CTApp类型的全局变量theApp。

定义了从CDocument派生的文档对象CTDoc

定义了从CView派生的视图对象CTView

#inlcude "stdafx.h"

#include "t.h"

#include "childfrm.h"

实现了类CMainFrame

# include "stdafx.h"

# include "t.h"

# include "tdoc.h"

实现了类CTDoc

# include "stdafx.h"

# include "t.h"

# include "tdoc.h"

# include "tview.h"

实现了类CTview

从表1-2中的包含关系一栏可以看出：

CTApp 的实现用到所有的用户定义对象，包含了他们的定义；CView 的实现用到CTdoc；其他对象的实现只涉及自己的定义；

当然，如果增加其他操作，引用其他对象，则要包含相应的类的定义文件。

对预编译头文件说明如下：

所谓头文件预编译，就是把一个工程(Project)中使用的一些MFC标准头文件(如Windows.H、Afxwin.H)预先编译，以后该工程编译时，不再编译这部分头文件，仅仅使用预编译的结果。这样可以加快编译速度，节省时间。

预编译头文件通过编译生成，以工程名命名，由于预编译的头文件的后缀是“pch”，所以编译结果文件是。

编译器通过一个头文件stdafx.h来使用预编译头文件。stdafx.h这个头文件名是可以在project的编译设置里指定的。编译器认为，所有在指令#include

"stdafx.h"前的代码都是预编译的，它跳过#include "stdafx. h"指令，使用编译这条指令之后的所有代码。

因此，所有的CPP实现文件第一条语句都是：#include "stdafx.h"。

另外，每一个实现文件CPP都包含了如下语句：

#ifdef _DEBUG

#undef THIS_FILE

static char BASED_CODE THIS_FILE[] = __FILE__;

#endif

这是表示，如果生成调试版本，要指示当前文件的名称。__FILE__是一个宏，在编译器编译过程中给它赋值为当前正在编译的文件名称。

2. MFC和Win32

1. MFC Object和Windows Object的关系

MFC中最重要的封装是对Win32 API的封装，因此，理解Windows Object和MFC

Object (C++对象，一个C++类的实例)之间的关系是理解MFC的关键之一。所谓Windows Object（Windows对象）是Win32下用句柄表示的Windows操作系统对象；所谓MFC Object (MFC对象)是C++对象，是一个C++类的实例，这里（本书范围内）MFC Object是有特定含义的，指封装Windows Object的C++ Object，并非指任意的C++ Object。

MFC Object 和Windows Object是不一样的，但两者紧密联系。以窗口对象为例：

一个MFC窗口对象是一个C++ CWnd类（或派生类）的实例，是程序直接创建的。在程序执行中它随着窗口类构造函数的调用而生成，随着析构函数的调用而消失。而Windows窗口则是Windows系统的一个内部数据结构的实例，由一个“窗口句柄”标识，Windows系统创建它并给它分配系统资源。Windows窗口在MFC窗口对象创建之后，由CWnd类的Create成员函数创建，“窗口句柄”保存在窗口对象的m_hWnd成员变量中。Windows窗口可以被一个程序销毁，也可以被用户的动作销毁。MFC窗口对象和Windows窗口对象的关系如图2-1所示。其他的Windows Object和对应的MFC Object也有类似的关系。

下面，对MFC Object和Windows Object作一个比较。有些论断对设备描述表(MFC类是CDC，句柄是HDC)可能不适用，但具体涉及到时会指出。

1. 从数据结构上比较

MFC Object是相应C++类的实例，这些类是MFC或者程序员定义的；

Windows Object是Windows系统的内部结构，通过一个句柄来引用；

MFC给这些类定义了一个成员变量来保存MFC Object对应的Windows

Object的句柄。对于设备描述表CDC类，将保存两个HDC句柄。

2. 从层次上讲比较

MFC Object是高层的，Windows Object是低层的；

MFC Object封装了Windows Object的大部分或全部功能，MFC Object的使用者不需要直接应用Windows Object的HANDLE（句柄）使用Win32

API，代替它的是引用相应的MFC Object的成员函数。

3. 从创建上比较

MFC Object通过构造函数由程序直接创建；Windows Object由相应的SDK函数创建。

MFC中，使用这些MFC Object，一般分两步：

首先，创建一个MFC Object，或者在STACK中创建，或者在HEAP中创建，这时，MFC Object的句柄实例变量为空，或者说不是一个有效的句柄。

然后，调用MFC Object的成员函数创建相应的Windows Object，MFC的句柄变量存储一个有效句柄。

CDC(设备描述表类)的创建有所不同，在后面的2.3节会具体说明CDC及其派生类的创建和使用。

当然，可以在MFC Object的构造函数中创建相应的Windows对象，MFC的GDI类就是如此实现的，但从实质上讲，MFC Object的创建和Windows

Object的创建是两回事。

4. 从转换上比较

可以从一个MFC Object得到对应的Windows Object的句柄；一般使用MFC Object的成员函数GetSafeHandle得到对应的句柄。

可以从一个已存在的Windows Object创建一个对应的MFC Object；一般使用MFC Object的成员函数Attach或者FromHandle来创建，前者得到一个永久性对象，后者得到的可能是一个临时对象。

5. 从使用范围上比较

MFC Object对系统的其他进程来说是不可见、不可用的；而Windows

Object一旦创建，其句柄是整个Windows系统全局的。一些句柄可以被其他进程使用。典型地，一个进程可以获得另一进程的窗口句柄，并给该窗口发送消息。

对同一个进程的线程来说，只可以使用本线程创建的MFC Object，不能使用其他线程的MFC Object。

6. 从销毁上比较

MFC Object随着析构函数的调用而消失；但Windows Object必须由相应的Windows系统函数销毁。

设备描述表CDC类的对象有所不同，它对应的HDC句柄对象可能不是被销毁，而是被释放。

当然，可以在MFC Object的析构函数中完成Windows Object的销毁，MFC Object的GDI类等就是如此实现的，但是，应该看到：两者的销毁是不同的。

每类Windows Object都有对应的MFC Object，下面用表格的形式列出它们之间的对应关系，如表2-1所示：

表2-1 MFC Object和Windows Object的对应关系

描述 Windows句柄

HWND

HDC

MFC Object

窗口

设备上下文

菜单

笔

CWnd and CWnd-derived classes

CDC and CDC-derived classes

HMENU

HPEN

CMenu

CGdiObject类，CPen和CPen-derived

classes

CGdiObject类，CBrush和CBrush-derived classes

CGdiObject类，CFont和CFont-derived classes

CGdiObject类，CBitmap和CBitmap-derived classes

CGdiObject类，CPalette和CPalette-derived classes

CGdiObject类，CRgn和CRgn-derived

classes

刷子 HBRUSH

字体 HFONT

位图 HBITMAP

调色板 HPALETTE

区域 HRGN

图像列表 HimageLIST CimageList和CimageList-derived

classes

套接字

表2-1中的OBJECT分以下几类：

Windows对象，

设备上下文对象，

GDI对象（BITMAP，BRUSH，FONT，PALETTE，PEN，RGN），

菜单，

图像列表，

网络套接字接口。

从广义上来看，文档对象和文件可以看作一对MFC Object和Windows Object，分别用CDocument类和文件句柄描述。

后续几节分别对前四类作一个简明扼要的论述。

1. Windows Object

用SDK的Win32 API编写各种Windows应用程序，有其共同的规律：首先是编写WinMain函数，编写处理消息和事件的窗口过程WndProc，在WinMain里头注册窗口（Register Window），创建窗口，然后开始应用程序的消息循环。

MFC应用程序也不例外，因为MFC是一个建立在SDK API基础上的编程框架。对程序员来说所不同的是：一般情况下，MFC框架自动完成了Windows登记、创建等工作。

下面，简要介绍MFC Window对Windows Window的封装。

1. Windows的注册

一个应用程序在创建某个类型的窗口前，必须首先注册该“窗口类”(Windows

Class)。注意，这里不是C++类的类。Register Window把窗口过程、窗口类型以及其他类型信息和要登记的窗口类关联起来。

SOCKET CSocket,CAsynSocket及其派生类

1. “窗口类”的数据结构

“窗口类”是Windows系统的数据结构，可以把它理解为Windows系统的类型定义，而Windows窗口则是相应“窗口类”的实例。Windows使用一个结构来描述“窗口类”，其定义如下：

typedef struct _WNDCLASSEX {

UINT cbSize; //该结构的字节数

UINT style; //窗口类的风格

WNDPROC lpfnWndProc; //窗口过程

int cbClsExtra;

int cbWndExtra;

HANDLE hInstance; //该窗口类的窗口过程所属的应用实例

HICON hIcon; //该窗口类所用的像标

HCURSOR hCursor; //该窗口类所用的光标

HBRUSH hbrBackground; //该窗口类所用的背景刷

LPCTSTR lpszMenuName; //该窗口类所用的菜单资源

LPCTSTR lpszClassName; //该窗口类的名称

HICON hIconSm; //该窗口类所用的小像标

} WNDCLASSEX;

从“窗口类”的定义可以看出，它包含了一个窗口的重要信息，如窗口风格、窗口过程、显示和绘制窗口所需要的信息，等等。关于窗口过程，将在后面消息映射等有关章节作详细论述。

Windows系统在初始化时，会注册(Register)一些全局的“窗口类”，例如通用控制窗口类。应用程序在创建自己的窗口时，首先必须注册自己的窗口类。在MFC环境下，有几种方法可以用来注册“窗口类”，下面分别予以讨论。

2. 调用AfxRegisterClass注册

AfxRegisterClass函数是MFC全局函数。AfxRegisterClass的函数原型：

BOOL AFXAPI AfxRegisterClass(WNDCLASS *lpWndClass);

参数lpWndClass是指向WNDCLASS结构的指针，表示一个“窗口类”。

首先，AfxRegisterClass检查希望注册的“窗口类”是否已经注册，如果是则表示已注册，返回TRUE，否则，继续处理。

接着，调用::RegisterClass(lpWndClass)注册窗口类；

然后，如果当前模块是DLL模块，则把注册“窗口类”的名字加入到模块状态的域m_szUnregisterList中。该域是一个固定长度的缓冲区，依次存放模块注册的“窗口类”的名字（每个名字是以“n0”结尾的字符串）。之所以这样做，是为了DLL退出时能自动取消(Unregister)它注册的窗口类。至于模块状态将在后面第9章详细的讨论。

最后，返回TRUE表示成功注册。

3. 调用AfxRegisterWndClass注册

AfxRegisterWndClass函数也是MFC全局函数。AfxRegisterWndClass的函数原型：

LPCTSTR AFXAPI AfxRegisterWndClass(UINT nClassStyle,

HCURSOR hCursor, HBRUSH hbrBackground, HICON hIcon)

参数1指定窗口类风格；

参数2、3、4分别指定该窗口类使用的光标、背景刷、像标的句柄，缺省值是0。

此函数根据窗口类属性动态地产生窗口类的名字，然后，判断是否该类已经注册，是则返回窗口类名；否则用指定窗口类的属性（窗口过程指定为缺省窗口过程），调用AfxRegisterCalss注册窗口类，返回类名。

动态产生的窗口类名字由以下几部分组成（包括冒号分隔符）：

如果参数2、3、4全部为NULL，则由三部分组成。

“Afx”+“:”+模块实例句柄”+“:”+“窗口类风格”

否则，由六部分组成：

“Afx”+“:”+模块实例句柄+“:”+“窗口类风格”+“:”+光标句柄+“:”+背景刷句柄+“:”+像标句柄。比如：“Afx:400000:b:13de:6:32cf”。

该函数在MFC注册主边框或者文档边框“窗口类”时被调用。具体怎样用在5.3.3.3节会指出。

4. 隐含的使用MFC预定义的的窗口类

MFC4.0以前的版本提供了一些预定义的窗口类，4.0以后不再预定义这些窗口类。但是，MFC仍然沿用了这些窗口类，例如：

用于子窗口的“AfxWnd”；

用于边框窗口(SDI主窗口或MDI子窗口)或视的“AfxFrameOrView”；

用于MDI主窗口的“AfxMDIFrame”；

用于标准控制条的“AfxControlBar”。

这些类的名字就是“AfxWnd”、“AfxFrameOrView”、“AfxMdiFrame”、

“AfxControlBar”加上前缀和后缀（用来标识版本号或是否调试版等）。它们使用标准应用程序像标、标准文档像标、标准光标等标准资源。为了使用这些“窗口类”，MFC会在适当的时候注册这些类：或者要创建该类的窗口时，或者创建应用程序的主窗口时，等等。

MFC内部使用了函数

BOOL AFXAPI AfxEndDeferRegisterClass(short fClass)

来帮助注册上述原MFC版本的预定义“窗口类”。参数fClass区分了那些预定义窗口的类型。根据不同的类型，使用不同的窗口类风格、窗口类名字等填充WndClass的域，然后调用AfxRegisterClass注册窗口类。并且注册成功之后，通过模块状态的m_fRegisteredClasses记录该窗口类已经注册，这样该模块在再次需要注册这些窗口类之前可以查一下m_fRegisteredClasses，如果已经注册就不必浪费时间了。为此，MFC内部使用宏

AfxDeferRegisterClass(short fClass)

来注册“窗口类”，如果m_fRegisteredClasses记录了注册的窗口类，返回TRUE，否则，调用AfxEndDeferRegisterClass注册。

注册这些窗口类的例子：

MFC在加载边框窗口时，会自动地注册“AfxFrameOrView”窗口类。在创建视时，就会使用该“窗口类”创建视窗口。当然，如果创建视窗口时，该“窗口类”还没有注册，MFC将先注册它然后使用它创建视窗口。

不过，MFC并不使用”AfxMDIFrame”来创建MDI主窗口，因为在加载主窗口时一般都指定了主窗口的资源，MFC使用指定的像标注册新的MDI主窗口类（通过函数AfxRegisterWndClass完成，因此“窗口类”的名字是动态产生的）。

MDI子窗口类似于上述MDI主窗口的处理。

在MFC创建控制窗口时，如工具栏窗口，如果“AfxControlBar”类还没有注册，则注册它。注册过程很简单，就是调用::InitCommonControl加载通用控制动态连接库。

5. 调用::RegisterWndClass。

直接调用Win32的窗口注册函数::RegisterWndClass注册“窗口类”，这样做有一个缺点：如果是DLL模块，这样注册的“窗口类”在程序退出时不会自动的被取消注册(Unregister)。所以必须记得在DLL模块退出时取消它所注册的窗口类。

6. 子类化

子类化（Subclass）一个“窗口类”，可自动地得到它的“窗口类”属性。

1. MFC窗口类CWnd

在Windows系统里，一个窗口的属性分两个地方存放：一部分放在“窗口类”里头，如上所述的在注册窗口时指定；另一部分放在Windows Object本身，如：窗口的尺寸，窗口的位置（X，Y轴），窗口的Z轴顺序，窗口的状态（ACTIVE，MINIMIZED，MAXMIZED，RESTORED…），和其他窗口的关系（父窗口，子窗口…），窗口是否可以接收键盘或鼠标消息，等等。

为了表达所有这些窗口的共性，MFC设计了一个窗口基类CWnd。有一点非常重要，那就是CWnd提供了一个标准而通用的MFC窗口过程，MFC下所有的窗口都使用这个窗口过程。至于通用的窗口过程却能为各个窗口实现不同的操作，那就是MFC消息映射机制的奥秘和作用了。这些，将在后面有关章节详细论述。

CWnd提供了一系列成员函数，或者是对Win32相关函数的封装，或者是CWnd新设计的一些函数。这些函数大致如下。

（1）窗口创建函数

这里主要讨论函数Create和CreateEx。它们封装了Win32窗口创建函数::CreateWindowEx。Create的原型如下：

BOOL CWnd::Create(LPCTSTR lpszClassName,

LPCTSTR lpszWindowName, DWORD dwStyle,

const RECT& rect,

CWnd* pParentWnd, UINT nID,

CCreateContext* pContext)

Create是一个虚拟函数，用来创建子窗口（不能创建桌面窗口和POP UP窗口）。CWnd的基类可以覆盖该函数，例如边框窗口类等覆盖了该函数以实现边框窗口的创建，视类则使用它来创建视窗口。

Create调用了成员函数CreateEx。CWnd::CreateEx的原型如下：

BOOL CWnd::CreateEx(DWORD dwExStyle, LPCTSTR lpszClassName,

LPCTSTR lpszWindowName, DWORD dwStyle,

int x, int y, int nWidth, int nHeight,

HWND hWndParent, HMENU nIDorHMenu, LPVOID lpParam)

CreateEx有11个参数，它将调用::CreateWindowEx完成窗口的创建，这11个参数对应地传递给::CreateWindowEx。参数指定了窗口扩展风格、“窗口类”、窗口名、窗口大小和位置、父窗口句柄、窗口菜单和窗口创建参数。

CreateEx的处理流程将在后面4.4.1节讨论窗口过程时分析。

窗口创建时发送WM_CREATE消息，消息参数lParam指向一个CreateStruct结构的变量，该结构有11个域，其描述见后面4.4.1节对窗口过程的分析，Windows使用和CreateEx参数一样的内容填充该变量。

（2）窗口销毁函数

例如：

DestroyWindow函数销毁窗口

PostNcDestroy( )，销毁窗口后调用，虚拟函数

（3）用于设定、获取、改变窗口属性的函数，例如：

SetWindowText(CString tiltle) 设置窗口标题

GetWindowText() 得到窗口标题

SetIcon(HICON hIcon, BOOL bBigIcon)；设置窗口像标

GetIcon( BOOL bBigIcon ) ;得到窗口像标

GetDlgItem( int nID)；得到窗口类指定ID的控制子窗口

GetDC(); 得到窗口的设备上下文

SetMenu(CMenu *pMenu); 设置窗口菜单

GetMenu()；得到窗口菜单

…

（4）用于完成窗口动作的函数

用于更新窗口，滚动窗口，等等。一部分成员函数设计成或可重载(Overloaded）函数，或虚拟(Overridden)函数，或MFC消息处理函数。这些函数或者实现了一部分功能，或者仅仅是一个空函数。如：

•

有关消息发送的函数：

SendMessage( UINT message,WPARAM wParam = 0, LPARAM lParam = 0 );

给窗口发送发送消息，立即调用方式

PostMessage(( UINT message,WPARAM wParam = 0, LPARAM lParam = 0 );

给窗口发送消息，放进消息队列

…

•

有关改变窗口状态的函数

MoveWindow( LPCRECT lpRect, BOOL bRepaint = TRUE );

移动窗口到指定位置

ShowWindow(BOOL )；显示窗口，使之可见或不可见

….

•

实现MFC消息处理机制的函数：

virtual LRESULT WindowProc( UINT message, WPARAM wParam, LPARAM lParam );

窗口过程，虚拟函数

virtual BOOL OnCommand( WPARAM wParam, LPARAM lParam )；处理命令消息

…

•

消息处理函数：

OnCreate( LPCREATESTRUCT lpCreateStruct );MFC窗口消息处理函数，窗口创建时由MFC框架调用

OnClose();MFC窗口消息处理函数，窗口创建时由MFC框架调用

…

•

其他功能的函数

CWnd的导出类是类型更具体、功能更完善的窗口类，它们继承了CWnd的属性和方法，并提供了新的成员函数（消息处理函数、虚拟函数、等等）。

常用的窗口类及其层次关系见图1-1。

1. 在MFC下创建一个窗口对象

MFC下创建一个窗口对象分两步，首先创建MFC窗口对象，然后创建对应的Windows窗口。在内存使用上，MFC窗口对象可以在栈或者堆(使用new创建)中创建。具体表述如下：

创建MFC窗口对象。通过定义一个CWnd或其派生类的实例变量或者动态创建一个MFC窗口的实例，前者在栈空间创建一个MFC窗口对象，后者在堆空间创建一个MFC窗口对象。

•

调用相应的窗口创建函数，创建Windows窗口对象。

•

例如：在前面提到的AppWizard产生的源码中，有CMainFrame（派生于CMDIFrame(SDI)或者CMDIFrameWnd(MDI)）类。它有两个成员变量定义如下：

CToolBar m_wndToolBar;

CStatusBar m_wndStatusBar;

当创建CMainFrame类对象时，上面两个MFC Object也被构造。

CMainFrame还有一个成员函数

OnCreate（LPCREATESTRUCT lpCreateStruct)，

它的实现包含如下一段代码，调用CToolBar和CStatusBar的成员函数Create来创建上述两个MFC对象对应的工具栏HWND窗口和状态栏HWND窗口：

int CMainFrame::OnCreate(LPCREATESTRUCT lpCreateStruct)

{

…

if (!m_(this) ||

!m_olBar(IDR_MAINFRAME))

{

TRACE0("Failed to create toolbarn");

return -1; // fail to create

}

if (!m_(this) ||

!m_icators(indicators,

sizeof(indicators)/sizeof(UINT)))

{

TRACE0("Failed to create status barn");

return -1; // fail to create

}

…

}

关于工具栏、状态栏将在后续有关章节作详细讨论。

在MFC中，还提供了一种动态创建技术。动态创建的过程实际上也如上所述分两步，只不过MFC使用这个技术是由框架自动地完成整个过程的。通常框架窗口、文档框架窗口、视使用了动态创建。介于MFC的结构，CFrameWnd和CView及其派生类的实例即使不使用动态创建，也要用new在堆中分配。理由见窗口的销毁（2.2.5节）。

至于动态创建技术，将在下一章具体讨论。

在Windows窗口的创建过程中，将发送一些消息，如：

在创建了窗口的非客户区(Nonclient area)之后，发送消息WM_NCCREATE；

在创建了窗口的客户区（client area）之后，发送消息WM_CREATE；

窗口的窗口过程在窗口显示之前收到这两个消息。

如果是子窗口，在发送了上述两个消息之后，还给父窗口发送WM_PARENATNOTIFY消息。其他类或风格的窗口可能发送更多的消息，具体参见SDK开发文档。

1. MFC窗口的使用

MFC提供了大量的窗口类，其功能和用途各异。程序员应该选择哪些类来使用，以及怎么使用他们呢？

直接使用MFC提供的窗口类或者先从MFC窗口类派生一个新的C++类然后使用它，这些在通常情况下都不需要程序员提供窗口注册的代码。是否需要派生新的C++类，视MFC已有的窗口类是否能满足使用要求而定。派生的C++类继承了基类的特性并改变或扩展了它的功能，例如增加或者改变对消息、事件的特殊处理等。

主要使用或继承以下一些MFC窗口类（其层次关系图见图1-1）：

框架类CFrameWnd，CMdiFrameWnd；

文档框架CMdiChildWnd；

视图CView和CView派生的有特殊功能的视图如：列表CListView，编辑CEditView，树形列表CTreeView，支持RTF的CRichEditView，基于对话框的视CFormView等等。

对话框CDialog。

通常，都要从这些类派生应用程序的框架窗口和视窗口或者对话框。

工具条CToolBar

状态条CStatusBar

其他各类控制窗口，如列表框CList，编辑框CEdit，组合框CComboBox，按钮Cbutton等。

通常，直接使用这些类。

2. 在MFC下窗口的销毁

窗口对象使用完毕，应该销毁。在MFC下，一个窗口对象的销毁包括HWND窗口对象的销毁和MFC窗口对象的销毁。一般情况下，MFC编程框架自动地处理了这些。

（1）对CFrameWnd和CView的派生类

这些窗口的关闭导致销毁窗口的函数DestroyWindow被调用。销毁Windows窗口时，MFC框架调用的最后一个成员函数是OnNcDestroy函数，该函数负责Windows清理工作，并在最后调用虚拟成员函数PostNcDestroy。CFrameWnd和CView的PostNcDestroy调用delete this删除自身这个MFC窗口对象。

所以，对这些窗口，如前所述，应在堆（Heap）中分配，而且，不要对这些对象使用delete操作。

（2）对Windows Control窗口

在它们的析构函数中，将调用DestroyWidnow来销毁窗口。如果在栈中分配这样的窗口对象，则在超出作用范围的时候，随着析构函数的调用，MFC窗口对象和它的Windows window对象都被销毁。如果在堆（Heap）中分配，则显式调用delete操作符，导致析构函数的调用和窗口的销毁。

所以，这种类型的窗口应尽可能在栈中分配，避免用额外的代码来销毁窗口。如前所述的CMainFrame的成员变量m_wndStatusBar和m_wndToolBar就是这样的例子。

（3）对于程序员直接从CWnd派生的窗口

程序员可以在派生类中实现上述两种机制之一，然后，在相应的规范下使用。

后面章节将详细的讨论应用程序退出时关闭、清理窗口的过程。

1. 设备描述表

1. 设备描述表概述

当一个应用程序使用GDI函数时，必须先装入特定的设备驱动程序，然后为绘制窗口准备设备描述表，比如指定线的宽度和颜色、刷子的样式和颜色、字体、剪裁区域等等。不像其他Win32结构，设备描述表不能被直接访问，只能通过系列Win32函数来间接地操作。

如同Windows“窗口类”一样，设备描述表也是一种Windows数据结构，用来描述绘制窗口所需要的信息。它定义了一个坐标映射模式、一组GDI图形对象及其属性。这些GDI对象包括用于画线的笔，绘图、填图的刷子，位图，调色板，剪裁区域，及路径(Path)。

表2-2列出了设备描述表的结构和各项缺省值，表2-3列出了设备描述表的类型，表2-4显示设备描述表的类型。

表2-2 设备描述表的结构

属性缺省值

Background Background color setting from Windows Control

color Panel (typically, white)

Background mode OPAQUE

Bitmap None

Brush WHITE_BRUSH

Brush origin (0,0)

Clipping region Entire window or client area with the update

region clipped, as appropriate. Child and

pop-up windows in the client area may also be

clipped

Palette DEFAULT_PALETTE

Current pen (0,0)

position

Device origin Upper left corner of the window or the client

area

Drawing mode R2_COPYPEN

Font SYSTEM_FONT (SYSTEM_FIXED_FONT for

applications written to run with Windows

versions 3.0 and earlier)

Intercharacter 0

spacing

Mapping mode MM_TEXT

Pen BLACK_PEN

Polygon-fill ALTERNATE

mode

Stretch mode BLACKONWHITE

Text color Text color setting from Control Panel

(typically, black)

Viewport extent (1,1)

Viewport origin (0,0)

Window extent (1,1)

Window origin (0,0)

表2-3 设备描述表的分类

Display 显示设备描述表，提供对视频显示设备上的绘制操作的支持

Printer 打印设备描述表，提供对打印机、绘图仪设备上的绘制操作的支持

Memory 内存设备描述表，提供对位图操作的支持

Information 信息设备描述表，提供对操作设备信息获取的支持

表2-3中的显示设备描述表又分三种类型，如表2-4所示。

表2-4 显示设备描述表的分类

名称特点功能

Class 提供对Win16的

Device 向后兼容

Contexts

Common 在Windows系统Applicaion获取设备描述表时，的高速缓冲区，Windows用缺省值初始化该设备描述Device

数量有限表，Application使用它完成绘制操作，然后释放

Contexts

Private

Device

Contexts

没有数量限制，用完不需释放一次获取，多次使用

多次使用过程中，每次设备描述表属性的任何修改或变化都会被保存，以支持快速绘制

（1）使用设备描述表的步骤

要使用设备描述表，一般有如下步骤：

获取或者创建设备描述表；

•

必要的话，改变设备描述表的属性；

•

使用设备描述表完成绘制操作；

•

释放或删除设备描述表。

•

Common设备描述表通过::GetDC，::GetDCEx，::BeginPaint来获得一个设备描述表，用毕，用::ReleaseDC或::EndPaint释放设备描述表；

Printer设备描述表通过::CreateDC创建设备描述表，用::DeleteDC删除设备描述表。

Memory设备描述表通过::CreateCompatibleDC创建设备描述表，用::DeleteDC删除。

Information设备描述表通过::CreateIC创建设备描述表，用::DeleteDC删除。

（2）改变设备描述表属性的途径

要改变设备描述表的属性，可通过以下途径：

用::SelectObject选入新的除调色板以外的GDI Object到设备描述表中；

对于调色板，使用::SelectPalette函数选入逻辑调色板，并使用::RealizePalette把逻辑调色板的入口映射到物理调色板中。

用其他API函数改变其他属性，如::SetMapMode改变映射模式。

1. 设备描述表在MFC中的实现

MFC提供了CDC类作为设备描述表类的基类，它封装了Windows的HDC设备描述表对象和相关函数。

1. CDC类

CDC类包含了各种类型的Windows设备描述表的全部功能，封装了所有的Win32 GDI 函数和设备描述表相关的SDK函数。在MFC下，使用CDC的成员函数来完成所有的窗口绘制工作。

CDC 类的结构示意图2-2所示。

CDC类有两个成员变量：m_hDC，m_hAttribDC，它们都是Windows设备描述表句柄。CDC的成员函数作输出操作时，使用m_Hdc；要获取设备描述表的属性时，使用m_hAttribDC。

在创建一个CDC类实例时，缺省的m_hDC等于m_hAttribDC。如果需要的话，程序员可以分别指定它们。例如，MFC框架实现CMetaFileDC类时，就是如此：CMetaFileDC从物理设备上读取设备信息，输出则送到元文件（metafile）上，所以m_hDC和m_hAttribDC是不同的，各司其责。还有一个类似的例子：打印预览的实现，一个代表打印机模拟输出，一个代表屏幕显示。

CDC封装::SelectObject(HDC hdc，HGDIOBJECT hgdiobject)函数时，采用了重载技术，即它针对不同的GDI对象，提供了名同而参数不同的成员函数：

SelectObject(CPen *pen)用于选入笔；

SelectObject(CBitmap* pBitmap)用于选入位图；

SelectObject(CRgn *pRgn)用于选入剪裁区域；

SelectObject(CBrush *pBrush)用于选入刷子；

SelectObject(CFont *pFont)用于选入字体；

至于调色板，使用SelectPalette(CPalette *pPalette，BOOL

bForceBackground )选入调色板到设备描述表，使用RealizePalletter()实现逻辑调色板到物理调色板的映射。

2. 从CDC派生出功能更具体的设备描述表

从CDC 派生出四个功能更具体的设备描述表类。层次如图2-3所示。

下面，分别讨论派生出的四种设备描述表。

•

CCientDC

代表窗口客户区的设备描述表。其构造函数CClientDC(CWnd *pWin)通过::GetDC获取指定窗口的客户区的设备描述表HDC，并且使用成员函数Attach把它和CClientDC对象捆绑在一起；其析构函数使用成员函数Detach把设备描述表句柄HDC分离出来，并调用::ReleaseDC释放设备描述表HDC。

•

CPaintDC

仅仅用于响应WM_PAINT消息时绘制窗口，因为它的构造函数调用了::BeginPaint获取设备描述表HDC，并且使用成员函数Attach把它和CPaintDC对象捆绑在一起；析构函数使用成员函数Detach把设备描述表句柄HDC分离出来，并调用::EndPaint释放设备描述表HDC，而::BeginPaint和::EndPaint仅仅在响应WM_PAINT时使用。

•

CMetaFileDC

用于生成元文件。

•

CWindowDC

代表整个窗口区(包括非客户区)的设备描述表。其构造函数CWindowDC(CWnd

*pWin)通过::GetWindowDC获取指定窗口的客户区的设备描述表HDC，并使用Attach把它和CWindowDC对象捆绑在一起；其析构函数使用Detach把设备描述表HDC分离出来，调用::ReleaseDC释放设备描述表HDC。

1. MFC设备描述表类的使用

1. 使用CPaintDC、CClientDC、CWindowDC的方法

首先，定义一个这些类的实例变量，通常在栈中定义。然后，使用它。

例如，MFC中CView对WM_PAINT消息的实现方法如下：

void CView::OnPaint()

{

// standard paint routine

CPaintDC dc(this);

OnPrepareDC(&dc);

OnDraw(&dc);

}

在栈中定义了CPaintDC类型的变量dc，随着构造函数的调用获取了设备描述表；设备描述表使用完毕，超出其有效范围就被自动地清除，随着析构函数的调用，其获取的设备描述表被释放。

如果希望在堆中创建，例如

CPaintDC *pDC；

pDC = new CPaintDC(this)

则在使用完毕时，用delete删除pDC:

delete pDC;

2. 直接使用CDC

需要注意的是：在生成CDC对象的时候，并不像它的派生类那样，在构造函数里获取相应的Windows设备描述表。最好不要使用::GetDC等函数来获取一个设备描述表，而是创建一个设备描述表。其构造函数如下：

CDC::CDC()

{

m_hDC = NULL;

m_hAttribDC = NULL;

m_bPrinting = FALSE;

}

其析构函数如下：

CDC::~CDC()

{

if (m_hDC != NULL)

::DeleteDC(Detach());

}

在CDC析构函数中，如果设备描述表句柄不空，则调用DeleteDC删除它。这是直接使用CDC时最好创建Windows设备描述表的理由。如果设备描述表不是创建的，则应该在析构函数被调用前分离出设备描述表句柄并用::RealeaseDC释放它，释放后m_hDC为空，则在析构函数调用时不会执行::DeleteDC。当然，不用担心CDC的派生类的析构函数调用CDC的析构函数，因为CDC::~CDC()不是虚拟析构函数。

直接使用CDC的例子是内存设备上下文，例如：

CDC dcMem; //声明一个CDC对象

CompatibleDC(&dc); //创建设备描述表

pbmOld = Object(&m_bmBall);//更改设备描述表属性

…//作一些绘制操作

Object(pbmOld);//恢复设备描述表的属性

DC(); //可以不调用，而让析构函数去删除设备描述表

1. GDI对象

在讨论设备描述表时，已经多次涉及到GDI对象。这里，需强调一下：GDI对象要选入Windows 设备描述表后才能使用；用毕，要恢复设备描述表的原GDI对象，并删除该GDI对象。

一般按如下步骤使用GDI对象：

Create or get a GDI OBJECT hNewGdi;

hOldGdi = ::SelectObject(hdc, hNewGdi)

……

::SelectObject(hdc, hOldGdi)

::DeleteObject(hNewGdi)

先创建或得到一个GDI对象，然后把它选入设备描述表并保存它原来的GDI对象；用毕恢复设备描述表原来的GDI对象并删除新创建的GDI对象。

需要指出的是，如果hNewGdi是一个Stock

GDI对象，可以不删除（删除也可以）。通过

HGDIOBJ GetStockObject(

int fnObject // type of stock object

);

来获取Stock GDI对象。

1. MFC GDI对象

MFC用一些类封装了Windows GDI对象和相关函数，层次结构如图2-4所示：

CGdiObject封装了Windows GDI Object共有的特性。其派生类在继承的基础上，主要封装了各类GDI的创建函数以及和具体GDI对象相关的操作。

CGdiObject的构造函数仅仅让m_hObject为空。如果m_hObject不空，其析构函数将删除对应的Windows GDI对象。MFC GDI对象和Windows GDI对象的关系如图2-5所示。

2. 使用MFC GDI类的使用

首先创建GDI对象，可分一步或两步创建。一步创建就是构造MFC对象和Windows

GDI对象一步完成；两步创建则先构造MFC对象，接着创建Windows GDI对象。然后，把新创建的GDI对象选进设备描述表，取代原GDI对象并保存。最后，恢复原GDI对象。例如：

void CMyView::OnDraw(CDC *pDC)

{

CPen penBlack; //构造MFC CPen对象

if (Pen(PS_SOLID, RGB(0, 0, 0)))

{

CPen *pOldPen = pDC->SelectObject(&penBlack)); //选进设备表，保存原笔

…

pDC->SelectObject(pOldPen); //恢复原笔

}else

{

…

}

和在SDK下有一点不同的是：这里没有DeleteObject。因为执行完OnDraw后，栈中的penBlack被销毁，它的析构函数被调用，导致DeleteObject的调用。

还有一点要说明：

pDC->SelectObject(&penBlack)返回了一个CPen *指针，也就是说，它根据原来PEN的句柄创建了一个MFC CPen对象。这个对象是否需要删除呢？不必要，因为它是一个临时对象，MFC框架会自动地删除它。当然，在本函数执行完毕把控制权返回给主消息循环之前，该对象是有效的。

关于临时对象及MFC处理它们的内部机制，将在后续章节详细讨论。

至此，Windows编程的核心概念：窗口、GDI界面（设备描述表、GDI对象等）已经陈述清楚，特别揭示了MFC对这些概念的封装机制，并简明讲述了与这些Windows Object对应的MFC类的使用方法。还有其他Windows概念，可以参见SDK开发文档。在MFC的实现上，基本上仅仅是对和这些概念相关的Win32函数的封装。如果明白了MFC的窗口、GDI界面的封装机制，其他就不难了。

3. CObject类

CObject是大多数MFC类的根类或基类。CObject类有很多有用的特性：对运行时类信息的支持，对动态创建的支持，对串行化的支持，对象诊断输出，等等。MFC从CObject派生出许多类，具备其中的一个或者多个特性。程序员也可以从CObject类派生出自己的类，利用CObject类的这些特性。

本章将讨论MFC如何设计CObject类的这些特性。首先，考察CObject类的定义，分析其结构和方法（成员变量和成员函数）对CObject特性的支持。然后，讨论CObject特性及其实现机制。

1. CObject的结构

以下是CObject类的定义：

class CObject

{

public:

//与动态创建相关的函数

virtual CRuntimeClass* GetRuntimeClass() const;

析构函数

virtual ~CObject(); // virtual destructors are necessary

//与构造函数相关的内存分配函数，可以用于DEBUG下输出诊断信息

void* PASCAL operator new(size_t nSize);

void* PASCAL operator new(size_t, void* p);

void PASCAL operator delete(void* p);

#if defined(_DEBUG) && !defined(_AFX_NO_DEBUG_CRT)

void* PASCAL operator new(size_t nSize, LPCSTR lpszFileName,

int nLine);

#endif

//缺省情况下，复制构造函数和赋值构造函数是不可用的

//如果程序员通过传值或者赋值来传递对象，将得到一个编译错误

protected:

//缺省构造函数

CObject();

private:

//复制构造函数，私有

CObject(const CObject& objectSrc); // no implementation

//赋值构造函数，私有

void operator=(const CObject& objectSrc); // no

implementation

// Attributes

public:

//与运行时类信息、串行化相关的函数

BOOL IsSerializable() const;

BOOL IsKindOf(const CRuntimeClass* pClass) const;

// Overridables

virtual void Serialize(CArchive& ar);

// 诊断函数

virtual void AssertValid() const;

virtual void Dump(CDumpContext& dc) const;

// Implementation

public:

//与动态创建对象相关的函数

static const AFX_DATA CRuntimeClass classCObject;

#ifdef _AFXDLL

static CRuntimeClass* PASCAL _GetBaseClass();

#endif

};

由上可以看出，CObject定义了一个CRuntimeClass类型的静态成员变量：

CRuntimeClass classCObject

还定义了几组函数：

构造函数析构函数类，

诊断函数，

与运行时类信息相关的函数，

与串行化相关的函数。

其中，一个静态函数：_GetBaseClass；五个虚拟函数：析构函数、GetRuntimeClass、Serialize、AssertValid、Dump。这些虚拟函数，在CObject的派生类中应该有更具体的实现。必要的话，派生类实现它们时可能要求先调用基类的实现，例如Serialize和Dump就要求这样。

静态成员变量classCObject和相关函数实现了对CObjet特性的支持。

2. CObject类的特性

下面，对三种特性分别描述，并说明程序员在派生类中支持这些特性的方法。

1. 对运行时类信息的支持

该特性用于在运行时确定一个对象是否属于一特定类（是该类的实例），或者从一个特定类派生来的。CObject提供IsKindOf函数来实现这个功能。

从CObject派生的类要具有这样的特性，需要：

定义该类时，在类说明中使用DECLARE_DYNAMIC（CLASSNMAE）宏；

•

在类的实现文件中使用IMPLEMENT_DYNAMIC(CLASSNAME，BASECLASS)宏。

•

1. 对动态创建的支持

前面提到了动态创建的概念，就是运行时创建指定类的实例。在MFC中大量使用，如前所述框架窗口对象、视对象，还有文档对象都需要由文档模板类(CDocTemplate)对象来动态的创建。

从CObject派生的类要具有动态创建的功能，需要：

定义该类时，在类说明中使用DECLARE_DYNCREATE（CLASSNMAE）宏；

•

定义一个不带参数的构造函数（默认构造函数）；

•

在类的实现文件中使用IMPLEMENT_DYNCREATE（CLASSNAME，BASECLASS）宏；

•

使用时先通过宏RUNTIME_CLASS得到类的RunTime信息，然后使用CRuntimeClass的成员函数CreateObject创建一个该类的实例。

•

例如：

CRuntimeClass* pRuntimeClass = RUNTIME_CLASS(CNname)

//CName必须有一个缺省构造函数

CObject* pObject = pRuntimeClass->CreateObject();

//用IsKindOf检测是否是CName类的实例

Assert( pObject->IsKindOf(RUNTIME_CLASS(CName));

1. 对序列化的支持

“序列化”就是把对象内容存入一个文件或从一个文件中读取对象内容的过程。从CObject派生的类要具有序列化的功能，需要：

定义该类时，在类说明中使用DECLARE_SERIAL（CLASSNMAE）宏；

•

定义一个不带参数的构造函数（默认构造函数）；

•

在类的实现文件中使用IMPLEMENT_SERIAL（CLASSNAME，BASECLASS）宏；

•

覆盖Serialize成员函数。（如果直接调用Serialize函数进行序列化读写，可以省略前面三步。）

•

对运行时类信息的支持、动态创建的支持、串行化的支持层（不包括直接调用Serailize实现序列化），这三种功能的层次依次升高。如果对后面的功能支持，必定对前面的功能支持。支持动态创建的话，必定支持运行时类信息；支持序列化，必定支持前面的两个功能，因为它们的声明和实现都是后者包含前者。

1. 综合示例：

定义一个支持串行化的类CPerson：

class CPerson : public CObject

{

public:

DECLARE_SERIAL( CPerson )

// 缺省构造函数

CPerson(){}{};

CString m_name;

WORD m_number;

void Serialize( CArchive& archive );

// rest of class declaration

};

实现该类的成员函数Serialize，覆盖CObject的该函数：void CPerson::Serialize( CArchive& archive )

{

// 先调用基类函数的实现

CObject::Serialize( archive );

// now do the stuff for our specific class

if( ing() )

archive << m_name << m_number;

else

archive >> m_name >> m_number;

}

使用运行时类信息：

CPerson a;

ASSERT( Of( RUNTIME_CLASS( CPerson ) ) );

ASSERT( Of( RUNTIME_CLASS( CObject ) ) );

动态创建：

CRuntimeClass* pRuntimeClass = RUNTIME_CLASS(CPerson)

//Cperson有一个缺省构造函数

CObject* pObject = pRuntimeClass->CreateObject();

Assert( pObject->IsKindOf(RUNTIME_CLASS(CPerson));

1. 实现CObject特性的机制

由上，清楚了CObject的结构，也清楚了从CObject派生新类时程序员使用CObject特性的方法。现在来考察这些方法如何利用CObjet的结构，CObject结构如何支持这些方法。

首先，要揭示DECLARE_DYNAMIC等宏的内容，然后，分析这些宏的作用。

1. DECLARE_DYNAMIC等宏的定义

MFC提供了DECLARE_DYNAMIC、DECLARE_DYNCREATE、DECLARE_SERIAL声明宏的两种定义，分别用于静态链接到MFC DLL和动态链接到MFC DLL。对应的实现宏IMPLEMNET_XXXX也有两种定义，但是，这里实现宏就不列举了。

MFC对这些宏的定义如下：

#ifdef _AFXDLL //动态链接到MFC DLL

#define DECLARE_DYNAMIC(class_name)

protected:

static CRuntimeClass* PASCAL _GetBaseClass();

public:

static const AFX_DATA CRuntimeClass class##class_name;

virtual CRuntimeClass* GetRuntimeClass() const;

#define _DECLARE_DYNAMIC(class_name)

protected:

static CRuntimeClass* PASCAL _GetBaseClass();

public:

static AFX_DATA CRuntimeClass class##class_name;

virtual CRuntimeClass* GetRuntimeClass() const;

#else

#define DECLARE_DYNAMIC(class_name)

public:

static const AFX_DATA CRuntimeClass class##class_name;

virtual CRuntimeClass* GetRuntimeClass() const;

#define _DECLARE_DYNAMIC(class_name)

public:

static AFX_DATA CRuntimeClass class##class_name;

virtual CRuntimeClass* GetRuntimeClass() const;

#endif

// not serializable, but dynamically constructable

#define DECLARE_DYNCREATE(class_name)

DECLARE_DYNAMIC(class_name)

static CObject* PASCAL CreateObject();

#define DECLARE_SERIAL(class_name)

_DECLARE_DYNCREATE(class_name)

friend CArchive& AFXAPI operator>>(CArchive& ar, class_name* &pOb);

由于这些声明宏都是在CObect派生类的定义中被使用的，所以从这些宏的上述定义中可以看出，DECLARE_DYNAMIC宏给所在类添加了一个CRuntimeClass类型的静态数据成员class##class_name(类名加前缀class，例如，若类名是CPerson，则该变量名称是classCPerson)，且指定为const；两个（使用MFC DLL时，否则，一个）成员函数：虚拟函数GetRuntimeClass和静态函数_GetBaseClass（使用MFC DLL时）。

DECLARE_DYNCREATE宏包含了DECLARE_DYNAMIC，在此基础上，还定义了一个静态成员函数CreateObject。

DECLARE_SERIAL宏则包含了_DECLARE_DYNCREATE，并重载了操作符“>>”（友员函数）。它和前两个宏有所不同的是CRuntimeClass数据成员class##class_name没有被指定为const。

对应地，MFC使用三个宏初始化DECLARE宏所定义的静态变量并实现DECLARE宏所声明的函数：IMPLEMNET_DYNAMIC，IMPLEMNET_DYNCREATE，IMPLEMENT_SERIAL。

首先，这三个宏初始化CRuntimeClass类型的静态成员变量class#class_name。IMPLEMENT_SERIAL不同于其他两个宏，没有指定该变量为const。初始化内容在下节讨论CRuntimeClass时给出。

其次，它实现了DECLARE宏声明的成员函数：

•

_GetBaseClass()

返回基类的运行时类信息，即基类的CRuntimeClass类型的静态成员变量。这是静态成员函数。

•

GetRuntimeClass()

返回类自己的运行类信息，即其CRuntimeClass类型的静态成员变量。这是虚拟成员函数。

对于动态创建宏，还有一个静态成员函数CreateObject，它使用C++操作符和类的缺省构造函数创建本类的一个动态对象。

•

操作符的重载

对于序列化的实现宏IMPLEMENT_SERIAL，还重载了操作符<<和定义了一个静态成员变量

static const AFX_CLASSINIT

_init_##class_name(RUNTIME_CLASS(class_name));

比如，对CPerson来说，该变量是_init_Cperson，其目的在于静态成员在应用程序启动之前被初始化，使得AFX_CLASSINIT类的构造函数被调用，从而通过AFX_CLASSINIT类的构造函数在模块状态的CRuntimeClass链表中插入构造函数参数表示的CRuntimeClass类信息。至于模块状态，在后文有详细的讨论。

重载的操作符函数用来在序列化时从文档中读入该类对象的内容，是一个友员函数。定义如下：

CArchive& AFXAPI operator>>(CArchive& ar, class_name* &pOb)

{

pOb = (class_name*) ject(

RUNTIME_CLASS(class_name));

return ar;

}

回顾CObject的定义，它也有一个CRuntimeClass类型的静态成员变量classCObject，因为它本身也支持三个特性。

以CObject及其派生类的静态成员变量classCObject为基础，IsKindOf和动态创建等函数才可以起到作用。

这个变量为什么能有这样的用处，这就要分析CRuntimeClass类型变量的结构和内容了。下面，在讨论了CRuntimeClass的结构之后，考察该类型的静态变量被不同的宏初始化之后的内容。

1. CruntimeClass类的结构与功能

从上面的讨论可以看出，在对CObject特性的支持上，CRuntimeClass类起到了关键作用。下面，考查它的结构和功能。

1. CRuntimeClass的结构

CruntimeClass的结构如下：

Struct CRuntimeClass

{

LPCSTR m_lpszClassName;//类的名字

int m_nObjectSize;//类的大小

UINT m_wSchema;

CObject* (PASCAL* m_pfnCreateObject)();

//pointer to function, equal to Object()

//after IMPLEMENT

CRuntimeClass* (PASCAL* m_pfnGetBaseClass)();

CRumtieClass* m_pBaseClass;

//operator:

CObject *CreateObject();

BOOL IsDerivedFrom(const CRuntimeClass* pBaseClass) const;

...

}

CRuntimeClass成员变量中有两个是函数指针，还有几个用来保存所在CruntimeClass对象所在类的名字、类的大小（字节数）等。

这些成员变量被三个实现宏初始化，例如：

m_pfnCreateObject，将被初始化指向所在类的静态成员函数CreateObject。CreateObject函数在初始化时由实现宏定义，见上文的说明。

m_pfnGetBaseClass，如果定义了_AFXDLL，则该变量将被初始化指向所在类的成员函数_GetBaseClass。_GetBaseClass在声明宏中声明，在初始化时由实现宏定义，见上文的说明。

下面，分析三个宏对CObject及其派生类的CRuntimeClass类型的成员变量class##class_name初始化的情况，然后讨论CRuntimeClass成员函数的实现。

2. 成员变量class##class_name的内容

IMPLEMENT_DYNCREATE等宏将初始化类的CRuntimeClass类型静态成员变量的各个域，表3-1列出了在动态类信息、动态创建、序列化这三个不同层次下对该静态成员变量的初始化情况：

表3-1 静态成员变量class##class_name的初始化

CRuntimeClass成员变量

m_lpszClassName

m_nObjectSize

动态类信息动态创建序列化

类名字符串

类的大小（字节数）

类名字符串

类的大小（字节数）

类名字符串

类的大小（字节数）

m_wShema 0xFFFF 0xFFFF

类的成员函数

1、2等，非0

类的成员函数 m_pfnCreateObject NULL

CreateObject CreateObject

m_pBaseClass 基类的CRuntimeClass变量

基类的CRuntimeClass变量

类的成员函数

基类的CRuntimeClass变量

类的成员函数 m_pfnGetBaseClass 类的成员函数

_GetBaseClass _GetBaseClass _GetBaseClass

m_pNextClass NULL NULL NULL

m_wSchema类型是UINT，定义了序列化中保存对象到文档的程序的版本。如果不要求支持序列化特性，该域为0XFFFF，否则，不能为0。

Cobject类本身的静态成员变量classCObject被初始化为：

{ "CObject", sizeof(CObject), 0xffff, NULL,

&CObject::_GetBaseClass, NULL };

对初始化内容解释如下：

类名字符串是“CObject”，类的大小是sizeof(CObject)，不要求支持序列化，不支持动态创建。

3. 成员函数CreateObject

回顾3.2节，动态创建对象是通过语句pRuntimeClass->CreateObject完成的，即调用了CRuntimeClass自己的成员函数，CreateObject函数又调用m_pfnCreateObject指向的函数来完成动态创建任务，如下所示：

CObject* CRuntimeClass::CreateObject()

{

if (m_pfnCreateObject == NULL) //判断函数指针是否空

{

TRACE(_T("Error: Trying to create object which is not ")

_T("DECLARE_DYNCREATE nor DECLARE_SERIAL: %hs.n"),

m_lpszClassName);

return NULL;

}

//函数指针非空，继续处理

CObject* pObject = NULL;

TRY

{

pObject = (*m_pfnCreateObject)(); //动态创建对象

}

END_TRY

return pObject;

}

4. 成员函数IsDerivedFrom

该函数用来帮助运行时判定一个类是否派生于另一个类，被CObject的成员函数IsKindOf函数所调用。其实现描述如下：

如果定义了_AFXDLL则，成员函数IsDerivedFrom调用成员函数m_pfnGetBaseClass指向的函数来向上逐层得到基类的CRuntimeClass类型的静态成员变量，直到某个基类的CRuntimeClass类型的静态成员变量和参数指定的CRuntimeClass变量一致或者追寻到最上层为止。

如果没有定义_AFXDLL，则使用成员变量m_pBaseClass基类的CRuntimeClass类型的静态成员变量。

程序如下所示：

BOOL CRuntimeClass::IsDerivedFrom(

const CRuntimeClass* pBaseClass) const

{

ASSERT(this != NULL);

ASSERT(AfxIsValidAddress(this, sizeof(CRuntimeClass), FALSE));

ASSERT(pBaseClass != NULL);

ASSERT(AfxIsValidAddress(pBaseClass, sizeof(CRuntimeClass),

FALSE));

// simple SI case

const CRuntimeClass* pClassThis = this;

while (pClassThis != NULL)//从本类开始向上逐个基类搜索

{

if (pClassThis == pBaseClass)//若是参数指定的类信息

return TRUE;

//类信息不符合，继续向基类搜索

#ifdef _AFXDLL

pClassThis = (*pClassThis->m_pfnGetBaseClass)();

#else

pClassThis = pClassThis->m_pBaseClass;

#endif

}

return FALSE; // 搜索完毕，没有匹配，返回FALSE。

}

由于CRuntimeClass类型的成员变量是静态成员变量，所以如果两个类的CruntimeClass成员变量相同，必定是同一个类。这就是IsDerivedFrom和IsKindOf的实现基础。

5. RUNTIME_CLASS宏

RUNTIME_CLASS宏定义如下：

#define

RUNTIME_CLASS(class_name)

(&class_name::class##class_name)

为了方便地得到每个类（Cobject或其派生类）的CRuntimeClass类型的静态成员变量，MFC定义了这个宏。它返回对类class_name的CRuntimeClass类型成员变量的引用，该成员变量的名称是“class”加上class_name（类的名字）。例如：

RUNTIME_CLASS(CObject)得到对classCObject的引用；

RUNTIME_CLASS(CPerson)得到对class CPerson的引用。

1. 动态类信息、动态创建的原理

MFC对Cobject动态类信息、动态创建的实现原理：

动态类信息、动态创建都建立在给类添加的CRuntimeClass类型的静态成员变量基础上，总结如下。

C++不支持动态创建，但是支持动态对象的创建。动态创建归根到底是创建动态对象，因为从一个类名创建一个该类的实例最终是创建一个以该类为类型的动态对象。其中的关键是从一个类名可以得到创建其动态对象的代码。

在一个类没有任何实例之前，怎么可以得到该类的创建动态对象的代码？借助于C++的静态成员数据技术可达到这个目的：

静态成员数据在程序的入口(main或WinMain)之前初始化。因此，在一个静态成员数据里存放有关类型信息、动态创建函数等，需要的时候，得到这个成员数据就可以了。

•

不论一个类创建多少实例，静态成员数据只有一份。所有的类的实例共享一个静态成员数据，要判断一个类是否是一个类的实例，只须确认它是否使用了该类的这个静态数据。

•

从前两节的讨论知道，DECLARE_CREATE等宏定义了一个这样的静态成员变量：类型是CRuntimeClass，命名约定是“calss”加上类名；IMPLEMENT_CREATE等宏初始化该变量；RUNTIME_CLASS宏用来得到该成员变量。

动态类信息的原理在分析CRuntimeClass的成员函数IsDerivedFrom时已经作了解释。

动态创建的过程和原理了，用图表示其过程如下：

注：下面一个方框内的逐级缩进表示逐层调用关系。

1. 序列化的机制

由上所述可知，一个类要支持实现序列化，使得它的对象可以保存到文档中或者可以从文档中读入到内存中并生成对象，需要使用动态类信息，而且，需要覆盖基类的Serialize虚拟函数来完成其对象的序列化。

仅仅有类的支持是不够的，MFC还提供了一个归档类CArchive来支持简单类型的数据和复杂对象的读写。

CArchive 在文件和内存对象之间充当一个代理者的角色。它负责按一定的顺序和格式把内存对象写到文件中，或者读出来，可以被看作是一个二进制的流。它和文件类CFile的关系如图3-2所示：

一个CArchive对象在要序列化的对象和存储媒体(storage medium，可以是一个文件或者一个Socket)之间起了中介作用。它提供了系列方法来完成序列化，不仅能够把int、float等简单类型数据进行序列化，而且能够把复杂的数据如string等进行序列化，更重要的是它能把复杂的对象(包括复合对象)进行序列化。这些方法就是重载的操作符>>和<<。对于简单类型，它针对不同类型直接实现不同的读写操作；对于复杂的对象，其每一个支持序列化的类都重载了操作符>>，从前几节可以清楚地看到这点：IMPLEMENT_SERIAL给所在类重载了操作符>>。至于<<操作，就不必每个序列化类都重载了。

复杂对象的“<<”操作，先搜索本模块状态的CRuntimeClass链表看是否有“<<”第二个参数指定的对象类的运行类信息(搜索过程涉及到模块状态，将在9.5.2节描述)，如果有（无，则返回），则先使用这些信息动态的创建对象（这就是是序列化类必须提供动态类信息、支持动态创建的原因），然后对该对象调用Serilize函数从存储媒体读入对象内容。

复杂对象的“>>”操作先把对象类的运行类信息写入存储媒体，然后对该对象调用Serilize函数把对象内容写入存储媒体。

在创建CArchive对象时，必须有一个CFile对象，它代表了存储媒介。通常，程序员不必做这个工作，打开或保存文档时MFC将自动的创建CFile对象和CArchive对象并在适当的时候调用序列化类的Serialize函数。在后面讨论打开(5.3.3.2节)或者关闭(6.1节)文档时将会看到这样的流程。

CArchive对象被创建时，需要指定它是用来读还是用来写，即指定序列化操作的方向。Serialize函数适用CArchive的函数IsStoring判定CArchive是用于读出数据还是写入数据。

在解释实现序列化的方法时，曾经提到如果程序员直接调用Serilize函数完成序列化，而不借助CArchive的>>和<<操作，则可以不需要动态类信息和动态创

建。从上文的论述可以看出，没有CArchive的>>和<<操作，的确不需要动态类信息和动态创建特性。

4. 消息映射的实现

1. Windows消息概述

Windows应用程序的输入由Windows系统以消息的形式发送给应用程序的窗口。这些窗口通过窗口过程来接收和处理消息，然后把控制返还给Windows。

1. 消息的分类

1. 队列消息和非队列消息

从消息的发送途径上看，消息分两种：队列消息和非队列消息。队列消息送到系统消息队列，然后到线程消息队列；非队列消息直接送给目的窗口过程。

这里，对消息队列阐述如下：

Windows维护一个系统消息队列（System message queue），每个GUI线程有一个线程消息队列（Thread message queue）。

鼠标、键盘事件由鼠标或键盘驱动程序转换成输入消息并把消息放进系统消息队列，例如WM_MOUSEMOVE、WM_LBUTTONUP、WM_KEYDOWN、WM_CHAR等等。Windows每次从系统消息队列移走一个消息，确定它是送给哪个窗口的和这个窗口是由哪个线程创建的，然后，把它放进窗口创建线程的线程消息队列。线程消息队列接收送给该线程所创建窗口的消息。线程从消息队列取出消息，通过Windows把它送给适当的窗口过程来处理。

除了键盘、鼠标消息以外，队列消息还有WM_PAINT、WM_TIMER和WM_QUIT。

这些队列消息以外的绝大多数消息是非队列消息。

2. 系统消息和应用程序消息

从消息的来源来看，可以分为：系统定义的消息和应用程序定义的消息。

系统消息ID的范围是从0到WM_USER-1，或0X80000到0XBFFFF；应用程序消息从WM_USER（0X0400）到0X7FFF，或0XC000到0XFFFF；WM_USER到0X7FFF范围的消息由应用程序自己使用；0XC000到0XFFFF范围的消息用来和其他应用程序通信，为了ID的唯一性，使用::RegisterWindowMessage来得到该范围的消息ID。

1. 消息结构和消息处理

1. 消息的结构

为了从消息队列获取消息信息，需要使用MSG结构。例如，::GetMessage函数（从消息队列得到消息并从队列中移走）和::PeekMessage函数(从消息队列得到消息但是可以不移走)都使用了该结构来保存获得的消息信息。

MSG结构的定义如下：

typedef struct tagMSG { // msg

HWND hwnd;

UINT message;

WPARAM wParam;

LPARAM lParam;

DWORD time;

POINT pt;

} MSG;

该结构包括了六个成员，用来描述消息的有关属性：

接收消息的窗口句柄、消息标识（ID）、第一个消息参数、第二个消息参数、消息产生的时间、消息产生时鼠标的位置。

2. 应用程序通过窗口过程来处理消息

如前所述，每个“窗口类”都要登记一个如下形式的窗口过程：

LRESULT CALLBACK MainWndProc (

HWND hwnd,// 窗口句柄

UINT msg,// 消息标识

WPARAM wParam,//消息参数1

LPARAM lParam//消息参数2

)

应用程序通过窗口过程来处理消息：非队列消息由Windows直接送给目的窗口的窗口过程，队列消息由::DispatchMessage等派发给目的窗口的窗口过程。窗口过程被调用时，接受四个参数：

a window handle（窗口句柄）；

a message identifier（消息标识）；

two 32-bit values called message parameters（两个32位的消息参数）；

需要的话，窗口过程用::GetMessageTime获取消息产生的时间，用::GetMessagePos获取消息产生时鼠标光标所在的位置。

在窗口过程里，用switch/case分支处理语句来识别和处理消息。

3. 应用程序通过消息循环来获得对消息的处理

每个GDI应用程序在主窗口创建之后，都会进入消息循环，接受用户输入、解释和处理消息。

消息循环的结构如下：

while (GetMessage(&msg, (HWND) NULL, 0, 0)) {//从消息队列得到消息

if (hwndDlgModeless == (HWND) NULL ||

!IsDialogMessage(hwndDlgModeless, &msg) &&

!TranslateAccelerator(hwndMain, haccel, &msg)) {

TranslateMessage(&msg);

DispatchMessage(&msg); //发送消息

}

消息循环从消息队列中得到消息，如果不是快捷键消息或者对话框消息，就进行消息转换和派发，让目的窗口的窗口过程来处理。

当得到消息WM_QUIT，或者::GetMessage出错时，退出消息循环。

4. MFC消息处理

使用MFC框架编程时，消息发送和处理的本质也如上所述。但是，有一点需要强调的是，所有的MFC窗口都使用同一窗口过程，程序员不必去设计和实现自己的窗口过程，而是通过MFC提供的一套消息映射机制来处理消息。因此，MFC简化了程序员编程时处理消息的复杂性。

所谓消息映射，简单地讲，就是让程序员指定要某个MFC类（有消息处理能力的类）处理某个消息。MFC提供了工具ClassWizard来帮助实现消息映射，在处理消息的类中添加一些有关消息映射的内容和处理消息的成员函数。程序员将完成消息处理函数，实现所希望的消息处理能力。

如果派生类要覆盖基类的消息处理函数，就用ClassWizard在派生类中添加一个消息映射条目，用同样的原型定义一个函数，然后实现该函数。这个函数覆盖派生类的任何基类的同名处理函数。

下面几节将分析MFC的消息机制的实现原理和消息处理的过程。为此，首先要分析ClassWizard实现消息映射的内幕，然后讨论MFC的窗口过程，分析MFC窗口过程是如何实现消息处理的。

1. 消息映射的定义和实现

1. MFC处理的三类消息

根据处理函数和处理过程的不同，MFC主要处理三类消息：

Windows消息，前缀以“WM_”打头，WM_COMMAND例外。Windows消息直接送给MFC窗口过程处理，窗口过程调用对应的消息处理函数。一般，由窗口对象来处理这类消息，也就是说，这类消息处理函数一般是MFC窗口类的成员函数。

•

控制通知消息，是控制子窗口送给父窗口的WM_COMMAND通知消息。窗口过程调用对应的消息处理函数。一般，由窗口对象来处理这类消息，也就是说，这类消息处理函数一般是MFC窗口类的成员函数。

•

需要指出的是，Win32使用新的WM_NOFITY来处理复杂的通知消息。WM_COMMAND类型的通知消息仅仅能传递一个控制窗口句柄(lparam)、控制窗ID和通知代码(wparam)。WM_NOTIFY能传递任意复杂的信息。

•

命令消息，这是来自菜单、工具条按钮、加速键等用户接口对象的WM_COMMAND通知消息，属于应用程序自己定义的消息。通过消息映射机制，MFC框架把命令按一定的路径分发给多种类型的对象（具备消息处理能力）处理，如文档、窗口、应用程序、文档模板等对象。能处理消息映射的类必须从CCmdTarget类派生。

在讨论了消息的分类之后，应该是讨论各类消息如何处理的时候了。但是，要知道怎么处理消息，首先要知道如何映射消息。

1. MFC消息映射的实现方法

mfc类库大全

发布评论取消回复

最近发表

相关推荐

标签列表

mfc类库大全

发布评论 取消回复

最近发表

相关推荐

标签列表

发布评论取消回复