MFC 教程

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
t.h	#include “resource.h” 定义了从CWinApp派生的应用程序对象CTApp
childfrm.h	定义了从CMDIChildWnd派生的文档框架窗口对象CTChildFrame
mainfrm.h	定义了从CMDIFrameWnd派生的框架窗口对象CMainFrame
tdoc.h	定义了从CDocument派生的文档对象CTDoc
tview.h	定义了从CView派生的视图对象CTView

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

实现文件	所包含的头文件	实现的内容和功能
stdafx.cpp	#include “stdafx.h”	用来产生预编译的类型信息。
t.cpp	# include “stdafx.h” # include “t.h” # include “MainFrm.h” # include “childfrm.h” #include “tdoc.h” #include “tview.h”	定义CTApp的实现，并定义CTApp类型的全局变量theApp。
childfrm.cpp	#inlcude “stdafx.h” #include “t.h” #include “childfrm.h”	实现了类CChildFrame
childfrm.cpp	#inlcude “stdafx.h” #include “t.h” #include “childfrm.h”	实现了类CMainFrame
tdoc.cpp	# include “stdafx.h” # include “t.h” # include “tdoc.h”	实现了类CTDoc
tview.cpp	# include “stdafx.h” # include “t.h” # include “tdoc.h” # include “tview.h”	实现了类CTview

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

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

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

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

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

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

编译器通过一个头文件stdafx.h来使用预编译头文件。stdafx.h这个头文件名是可以在project的编译设置里指定的。编译器认为，所有在指令#include “stdafx.h”前的代码都是预编译的，它跳过#include “stdafx. h”指令，使用projectname.pch编译这条指令之后的所有代码。

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

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

#ifdef _DEBUG

#undef THIS_FILE

static char BASED_CODE THIS_FILE[] = __FILE__;

#endif

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

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)可能不适用，但具体涉及到时会指出。

从数据结构上比较

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

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

MFC给这些类定义了一个成员变量来保存MFC Object对应的Windows Object的句柄。对于设备描述表CDC类，将保存两个HDC句柄。
从层次上讲比较

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

MFC Object封装了Windows Object的大部分或全部功能，MFC Object的使用者不需要直接应用Windows Object的HANDLE（句柄）使用Win32 API，代替它的是引用相应的MFC Object的成员函数。
从创建上比较

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的创建是两回事。
从转换上比较

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

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

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

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

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句柄	MFC Object
窗口	HWND	CWnd and CWnd-derived classes
设备上下文	HDC	CDC and CDC-derived classes
菜单	HMENU	CMenu
笔	HPEN	CGdiObject类，CPen和CPen-derived classes
刷子	HBRUSH	CGdiObject类，CBrush和CBrush-derived classes
字体	HFONT	CGdiObject类，CFont和CFont-derived classes
位图	HBITMAP	CGdiObject类，CBitmap和CBitmap-derived classes
调色板	HPALETTE	CGdiObject类，CPalette和CPalette-derived classes
区域	HRGN	CGdiObject类，CRgn和CRgn-derived classes
图像列表	HimageLIST	CimageList和CimageList-derived classes
套接字	SOCKET	CSocket,CAsynSocket及其派生类

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

Windows对象，

设备上下文对象，

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

菜单，

图像列表，

网络套接字接口。

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

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

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把窗口过程、窗口类型以及其他类型信息和要登记的窗口类关联起来。

“窗口类”的数据结构

“窗口类”是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环境下，有几种方法可以用来注册“窗口类”，下面分别予以讨论。
调用AfxRegisterClass注册

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

BOOL AFXAPI AfxRegisterClass(WNDCLASS *lpWndClass);

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

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

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

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

最后，返回TRUE表示成功注册。
调用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节会指出。
隐含的使用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加载通用控制动态连接库。
调用::RegisterWndClass。

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

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

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。

在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_wndToolBar.Create(this) ||

!m_wndToolBar.LoadToolBar(IDR_MAINFRAME))

{

TRACE0(“Failed to create toolbar\n”);

return -1; // fail to create

}

if (!m_wndStatusBar.Create(this) ||

!m_wndStatusBar.SetIndicators(indicators,

sizeof(indicators)/sizeof(UINT)))

{

TRACE0(“Failed to create status bar\n”);

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开发文档。

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等。

通常，直接使用这些类。
在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. 设备描述表概述

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

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

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

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

属性	缺省值
Background color	Background color setting from Windows Control 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 position	(0,0)
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)
Font
Intercharacter spacing	0
Mapping mode	MM_TEXT
Pen	BLACK_PEN
Polygon-fill mode	ALTERNATE
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 Device Contexts	提供对Win16的向后兼容
Common Device Contexts	在Windows系统的高速缓冲区，数量有限	Applicaion获取设备描述表时，Windows用缺省值初始化该设备描述表，Application使用它完成绘制操作，然后释放
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改变映射模式。

设备描述表在MFC中的实现

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

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()实现逻辑调色板到物理调色板的映射。
从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。

MFC设备描述表类的使用

使用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;
直接使用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对象

dcMem.CreateCompatibleDC(&dc); //创建设备描述表

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

…//作一些绘制操作

dcMem.SelectObject(pbmOld);//恢复设备描述表的属性

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

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对象。

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所示。
使用MFC GDI类的使用

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

void CMyView::OnDraw(CDC *pDC)

{

CPen penBlack; //构造MFC CPen对象

if (penBlack.CreatePen(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界面的封装机制，其他就不难了。

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类的特性

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

对运行时类信息的支持

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

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

定义该类时，在类说明中使用DECLARE_DYNAMIC（CLASSNMAE）宏；
在类的实现文件中使用IMPLEMENT_DYNAMIC(CLASSNAME，BASECLASS)宏。

对动态创建的支持

前面提到了动态创建的概念，就是运行时创建指定类的实例。在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));

对序列化的支持

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

定义该类时，在类说明中使用DECLARE_SERIAL（CLASSNMAE）宏；
定义一个不带参数的构造函数（默认构造函数）；
在类的实现文件中使用IMPLEMENT_SERIAL（CLASSNAME，BASECLASS）宏；
覆盖Serialize成员函数。（如果直接调用Serialize函数进行序列化读写，可以省略前面三步。）

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

综合示例：

定义一个支持串行化的类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( archive.IsStoring() )

archive << m_name << m_number;

else

archive >> m_name >> m_number;

}

使用运行时类信息：

CPerson a;

ASSERT( a.IsKindOf( RUNTIME_CLASS( CPerson ) ) );

ASSERT( a.IsKindOf( RUNTIME_CLASS( CObject ) ) );

动态创建：

CRuntimeClass* pRuntimeClass = RUNTIME_CLASS(CPerson)

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

CObject* pObject = pRuntimeClass->CreateObject();

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

实现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*) ar.ReadObject(

RUNTIME_CLASS(class_name));

return ar;

}

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

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

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

CruntimeClass类的结构与功能

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

CRuntimeClass的结构

CruntimeClass的结构如下：

Struct CRuntimeClass

{

LPCSTR m_lpszClassName;//类的名字

int m_nObjectSize;//类的大小

UINT m_wSchema;

CObject* (PASCAL* m_pfnCreateObject)();

//pointer to function, equal to newclass.CreateObject()

//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成员函数的实现。

成员变量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)，不要求支持序列化，不支持动态创建。

成员函数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;

}
成员函数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的实现基础。
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的引用。

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

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

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

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

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

静态成员数据在程序的入口(main或WinMain)之前初始化。因此，在一个静态成员数据里存放有关类型信息、动态创建函数等，需要的时候，得到这个成员数据就可以了。
不论一个类创建多少实例，静态成员数据只有一份。所有的类的实例共享一个静态成员数据，要判断一个类是否是一个类的实例，只须确认它是否使用了该类的这个静态数据。

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

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

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

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

序列化的机制

由上所述可知，一个类要支持实现序列化，使得它的对象可以保存到文档中或者可以从文档中读入到内存中并生成对象，需要使用动态类信息，而且，需要覆盖基类的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的>>和<<操作，的确不需要动态类信息和动态创建特性。

消息映射的实现
1. Windows消息概述
  
  Windows应用程序的输入由Windows系统以消息的形式发送给应用程序的窗口。这些窗口通过窗口过程来接收和处理消息，然后把控制返还给Windows。
  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。

这些队列消息以外的绝大多数消息是非队列消息。
系统消息和应用程序消息

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

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

消息结构和消息处理

消息的结构

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

MSG结构的定义如下：

typedef struct tagMSG { // msg

HWND hwnd;

UINT message;

WPARAM wParam;

LPARAM lParam;

DWORD time;

POINT pt;

} MSG;

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

接收消息的窗口句柄、消息标识（ID）、第一个消息参数、第二个消息参数、消息产生的时间、消息产生时鼠标的位置。
应用程序通过窗口过程来处理消息

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

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分支处理语句来识别和处理消息。
应用程序通过消息循环来获得对消息的处理

每个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出错时，退出消息循环。
MFC消息处理

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

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

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

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

消息映射的定义和实现
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类派生。

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

MFC消息映射的实现方法

MFC使用ClassWizard帮助实现消息映射，它在源码中添加一些消息映射的内容，并声明和实现消息处理函数。现在来分析这些被添加的内容。

在类的定义（头文件）里，它增加了消息处理函数声明，并添加一行声明消息映射的宏DECLARE_MESSAGE_MAP。

在类的实现（实现文件）里，实现消息处理函数，并使用IMPLEMENT_MESSAGE_MAP宏实现消息映射。一般情况下，这些声明和实现是由MFC的ClassWizard自动来维护的。看一个例子：

在AppWizard产生的应用程序类的源码中，应用程序类的定义（头文件）包含了类似如下的代码：

//{{AFX_MSG(CTttApp)

afx_msg void OnAppAbout();

//}}AFX_MSG

DECLARE_MESSAGE_MAP()

应用程序类的实现文件中包含了类似如下的代码：

BEGIN_MESSAGE_MAP(CTApp, CWinApp)

//{{AFX_MSG_MAP(CTttApp)

ON_COMMAND(ID_APP_ABOUT, OnAppAbout)

//}}AFX_MSG_MAP

END_MESSAGE_MAP()

头文件里是消息映射和消息处理函数的声明，实现文件里是消息映射的实现和消息处理函数的实现。它表示让应用程序对象处理命令消息ID_APP_ABOUT，消息处理函数是OnAppAbout。

为什么这样做之后就完成了一个消息映射？这些声明和实现到底作了些什么呢？接着，将讨论这些问题。
在声明与实现的内部

DECLARE_MESSAGE_MAP宏：

首先，看DECLARE_MESSAGE_MAP宏的内容：

#ifdef _AFXDLL

#define DECLARE_MESSAGE_MAP() \

private: \

static const AFX_MSGMAP_ENTRY _messageEntries[]; \

protected: \

static AFX_DATA const AFX_MSGMAP messageMap; \

static const AFX_MSGMAP* PASCAL _GetBaseMessageMap(); \

virtual const AFX_MSGMAP* GetMessageMap() const; \

#else

#define DECLARE_MESSAGE_MAP() \

private: \

static const AFX_MSGMAP_ENTRY _messageEntries[]; \

protected: \

static AFX_DATA const AFX_MSGMAP messageMap; \

virtual const AFX_MSGMAP* GetMessageMap() const; \

#endif

DECLARE_MESSAGE_MAP定义了两个版本，分别用于静态或者动态链接到MFC DLL的情形。
BEGIN_MESSAE_MAP宏

然后，看BEGIN_MESSAE_MAP宏的内容：

#ifdef _AFXDLL

#define BEGIN_MESSAGE_MAP(theClass, baseClass) \

const AFX_MSGMAP* PASCAL theClass::_GetBaseMessageMap() \

{ return &baseClass::messageMap; } \

const AFX_MSGMAP* theClass::GetMessageMap() const \

{ return &theClass::messageMap; } \

AFX_DATADEF const AFX_MSGMAP theClass::messageMap = \

{ &theClass::_GetBaseMessageMap, &theClass::_messageEntries[0] }; \

const AFX_MSGMAP_ENTRY theClass::_messageEntries[] = \

{ \

#else

#define BEGIN_MESSAGE_MAP(theClass, baseClass) \

const AFX_MSGMAP* theClass::GetMessageMap() const \

{ return &theClass::messageMap; } \

AFX_DATADEF const AFX_MSGMAP theClass::messageMap = \

{ &baseClass::messageMap, &theClass::_messageEntries[0] }; \

const AFX_MSGMAP_ENTRY theClass::_messageEntries[] = \

{ \

#endif

#define END_MESSAGE_MAP() \

{0, 0, 0, 0, AfxSig_end, (AFX_PMSG)0 } \

}; \

对应地，BEGIN_MESSAGE_MAP定义了两个版本，分别用于静态或者动态链接到MFC DLL的情形。END_MESSAGE_MAP相对简单，就只有一种定义。
ON_COMMAND宏

最后，看ON_COMMAND宏的内容：

#define ON_COMMAND(id, memberFxn) \

WM_COMMAND,\

CN_COMMAND,\

(WORD)id,\

AfxSig_vv,\

(AFX_PMSG)memberFxn\

}；

消息映射声明的解释

在清楚了有关宏的定义之后，现在来分析它们的作用和功能。

消息映射声明的实质是给所在类添加几个静态成员变量和静态或虚拟函数，当然它们是与消息映射相关的变量和函数。

成员变量

有两个成员变量被添加，第一个是_messageEntries，第二个是messageMap。

第一个成员变量的声明：

AFX_MSGMAP_ENTRY _messageEntries[]

这是一个AFX_MSGMAP_ENTRY 类型的数组变量，是一个静态成员变量，用来容纳类的消息映射条目。一个消息映射条目可以用AFX_MSGMAP_ENTRY结构来描述。

AFX_MSGMAP_ENTRY结构的定义如下：

struct AFX_MSGMAP_ENTRY

{

//Windows消息ID

UINT nMessage;

//控制消息的通知码

UINT nCode;

//Windows Control的ID

UINT nID;

//如果是一定范围的消息被映射，则nLastID指定其范围

UINT nLastID;

UINT nSig;//消息的动作标识

//响应消息时应执行的函数(routine to call (or special value))

AFX_PMSG pfn;

};

从上述结构可以看出，每条映射有两部分的内容：第一部分是关于消息ID的，包括前四个域；第二部分是关于消息对应的执行函数，包括后两个域。

在上述结构的六个域中，pfn是一个指向CCmdTarger成员函数的指针。函数指针的类型定义如下：

typedef void (AFX_MSG_CALL CCmdTarget::*AFX_PMSG)(void);

当使用一条或者多条消息映射条目初始化消息映射数组时，各种不同类型的消息函数都被转换成这样的类型：不接收参数，也不返回参数的类型。因为所有可以有消息映射的类都是从CCmdTarge派生的，所以可以实现这样的转换。

nSig是一个标识变量，用来标识不同原型的消息处理函数，每一个不同原型的消息处理函数对应一个不同的nSig。在消息分发时，MFC内部根据nSig把消息派发给对应的成员函数处理，实际上，就是根据nSig的值把pfn还原成相应类型的消息处理函数并执行它。

第二个成员变量的声明

AFX_MSGMAP messageMap;

这是一个AFX_MSGMAP类型的静态成员变量，从其类型名称和变量名称可以猜出，它是一个包含了消息映射信息的变量。的确，它把消息映射的信息（消息映射数组）和相关函数打包在一起，也就是说，得到了一个消息处理类的该变量，就得到了它全部的消息映射数据和功能。AFX_MSGMAP结构的定义如下：

struct AFX_MSGMAP

{

//得到基类的消息映射入口地址的数据或者函数

#ifdef _AFXDLL

//pfnGetBaseMap指向_GetBaseMessageMap函数

const AFX_MSGMAP* (PASCAL* pfnGetBaseMap)();

#else

//pBaseMap保存基类消息映射入口_messageEntries的地址

const AFX_MSGMAP* pBaseMap;

#endif

//lpEntries保存消息映射入口_messageEntries的地址

const AFX_MSGMAP_ENTRY* lpEntries;

};

从上面的定义可以看出，通过messageMap可以得到类的消息映射数组_messageEntries和函数_GetBaseMessageMap的地址（不使用MFC DLL时，是基类消息映射数组的地址）。

成员函数

_GetBaseMessageMap()

用来得到基类消息映射的函数。

GetMessageMap()

用来得到自身消息映射的函数。

消息映射实现的解释

消息映射实现的实质是初始化声明中定义的静态成员函数_messageEntries和messageMap，实现所声明的静态或虚拟函数GetMessageMap、_GetBaseMessageMap。

这样，在进入WinMain函数之前，每个可以响应消息的MFC类都生成了一个消息映射表，程序运行时通过查询该表判断是否需要响应某条消息。

对消息映射入口表(消息映射数组)的初始化

如前所述，消息映射数组的元素是消息映射条目，条目的格式符合结构AFX_MESSAGE_ENTRY的描述。所以，要初始化消息映射数组，就必须使用符合该格式的数据来填充：如果指定当前类处理某个消息，则把和该消息有关的信息（四个）和消息处理函数的地址及原型组合成为一个消息映射条目，加入到消息映射数组中。

显然，这是一个繁琐的工作。为了简化操作，MFC根据消息的不同和消息处理方式的不同，把消息映射划分成若干类别，每一类的消息映射至少有一个共性：消息处理函数的原型相同。对每一类消息映射，MFC定义了一个宏来简化初始化消息数组的工作。例如，前文提到的ON_COMMAND宏用来映射命令消息，只要指定命令ID和消息处理函数即可，因为对这类命令消息映射条目，其他四个属性都是固定的。ON_COMMAND宏的初始化内容如下：

{WM_COMMAND,

CN_COMMAND,

(WORD)ID_APP_ABOUT,

(WORD)ID_APP_ABOUT,

AfxSig_vv,

(AFX_PMSG)OnAppAbout

}

这个消息映射条目的含义是：消息ID是ID_APP_ABOUT，OnAppAbout被转换成AFX_PMSG指针类型，AfxSig_vv是MFC预定义的枚举变量，用来标识OnAppAbout的函数类型为参数空(Void)、返回空(Void)。

在消息映射数组的最后，是宏END_MESSAGE_MAP的内容，它标识消息处理类的消息映射条目的终止。
对messageMap的初始化

如前所述，messageMap的类型是AFX_MESSMAP。

经过初始化，域lpEntries保存了消息映射数组_messageEntries的地址；如果动态链接到MFC DLL，则pfnGetBaseMap保存了_GetBaseMessageMap成员函数的地址；否则pBaseMap保存了基类的消息映射数组的地址。
对函数的实现

_GetBaseMessageMap()

它返回基类的成员变量messagMap（当使用MFC DLL时），使用该函数得到基类消息映射入口表。

GetMessageMap()：

它返回成员变量messageMap，使用该函数得到自身消息映射入口表。

顺便说一下，消息映射类的基类CCmdTarget也实现了上述和消息映射相关的函数，不过，它的消息映射数组是空的。

既然消息映射宏方便了消息映射的实现，那么有必要详细的讨论消息映射宏。下一节，介绍消息映射宏的分类、用法和用途。

消息映射宏的种类

为了简化程序员的工作，MFC定义了一系列的消息映射宏和像AfxSig_vv这样的枚举变量，以及标准消息处理函数，并且具体地实现这些函数。这里主要讨论消息映射宏，常用的分为以下几类。

用于Windows消息的宏，前缀为“ON_WM_”。

这样的宏不带参数，因为它对应的消息和消息处理函数的函数名称、函数原型是确定的。MFC提供了这类消息处理函数的定义和缺省实现。每个这样的宏处理不同的Windows消息。

例如：宏ON_WM_CREATE()把消息WM_CREATE映射到OnCreate函数，消息映射条目的第一个成员nMessage指定为要处理的Windows消息的ID，第二个成员nCode指定为0。
用于命令消息的宏ON_COMMAND

这类宏带有参数，需要通过参数指定命令ID和消息处理函数。这些消息都映射到WM_COMMAND上，也就是将消息映射条目的第一个成员nMessage指定为WM_COMMAND，第二个成员nCode指定为CN_COMMAND(即0)。消息处理函数的原型是void (void)，不带参数，不返回值。

除了单条命令消息的映射，还有把一定范围的命令消息映射到一个消息处理函数的映射宏ON_COMMAND_RANGE。这类宏带有参数，需要指定命令ID的范围和消息处理函数。这些消息都映射到WM_COMMAND上，也就是将消息映射条目的第一个成员nMessage指定为WM_COMMAND，第二个成员nCode指定为CN_COMMAND(即0)，第三个成员nID和第四个成员nLastID指定了映射消息的起止范围。消息处理函数的原型是void (UINT)，有一个UINT类型的参数，表示要处理的命令消息ID，不返回值。

（3）用于控制通知消息的宏

这类宏可能带有三个参数，如ON_CONTROL，就需要指定控制窗口ID，通知码和消息处理函数；也可能带有两个参数，如具体处理特定通知消息的宏ON_BN_CLICKED、ON_LBN_DBLCLK、ON_CBN_EDITCHANGE等，需要指定控制窗口ID和消息处理函数。

控制通知消息也被映射到WM_COMMAND上，也就是将消息映射条目的第一个成员的nMessage指定为WM_COMMAND，但是第二个成员nCode是特定的通知码，第三个成员nID是控制子窗口的ID，第四个成员nLastID等于第三个成员的值。消息处理函数的原型是void (void)，没有参数，不返回值。

还有一类宏处理通知消息ON_NOTIFY，它类似于ON_CONTROL，但是控制通知消息被映射到WM_NOTIFY。消息映射条目的第一个成员的nMessage被指定为WM_NOTIFY，第二个成员nCode是特定的通知码，第三个成员nID是控制子窗口的ID，第四个成员nLastID等于第三个成员的值。消息处理函数的原型是void (NMHDR*, LRESULT*)，参数1是NMHDR指针，参数2是LRESULT指针，用于返回结果，但函数不返回值。

对应地，还有把一定范围的控制子窗口的某个通知消息映射到一个消息处理函数的映射宏，这类宏包括ON__CONTROL_RANGE和ON_NOTIFY_RANGE。这类宏带有参数，需要指定控制子窗口ID的范围和通知消息，以及消息处理函数。

对于ON__CONTROL_RANGE，是将消息映射条目的第一个成员的nMessage指定为WM_COMMAND，但是第二个成员nCode是特定的通知码，第三个成员nID和第四个成员nLastID等于指定了控制窗口ID的范围。消息处理函数的原型是void (UINT)，参数表示要处理的通知消息是哪个ID的控制子窗口发送的，函数不返回值。

对于ON__NOTIFY_RANGE，消息映射条目的第一个成员的nMessage被指定为WM_NOTIFY，第二个成员nCode是特定的通知码，第三个成员nID和第四个成员nLastID指定了控制窗口ID的范围。消息处理函数的原型是void (UINT, NMHDR*, LRESULT*)，参数1表示要处理的通知消息是哪个ID的控制子窗口发送的，参数2是NMHDR指针，参数3是LRESULT指针，用于返回结果，但函数不返回值。

（4）用于用户界面接口状态更新的ON_UPDATE_COMMAND_UI宏

这类宏被映射到消息WM_COMMND上，带有两个参数，需要指定用户接口对象ID和消息处理函数。消息映射条目的第一个成员nMessage被指定为WM_COMMAND，第二个成员nCode被指定为-1，第三个成员nID和第四个成员nLastID都指定为用户接口对象ID。消息处理函数的原型是 void (CCmdUI*)，参数指向一个CCmdUI对象，不返回值。

对应地，有更新一定ID范围的用户接口对象的宏ON_UPDATE_COMMAND_UI_RANGE，此宏带有三个参数，用于指定用户接口对象ID的范围和消息处理函数。消息映射条目的第一个成员nMessage被指定为WM_COMMAND，第二个成员nCode被指定为-1，第三个成员nID和第四个成员nLastID用于指定用户接口对象ID的范围。消息处理函数的原型是 void (CCmdUI*)，参数指向一个CCmdUI对象，函数不返回值。之所以不用当前用户接口对象ID作为参数，是因为CCmdUI对象包含了有关信息。

（5）用于其他消息的宏

例如用于用户定义消息的ON_MESSAGE。这类宏带有参数，需要指定消息ID和消息处理函数。消息映射条目的第一个成员nMessage被指定为消息ID，第二个成员nCode被指定为0，第三个成员nID和第四个成员也是0。消息处理的原型是LRESULT (WPARAM, LPARAM)，参数1和参数2是消息参数wParam和lParam，返回LRESULT类型的值。

（6）扩展消息映射宏

很多普通消息映射宏都有对应的扩展消息映射宏，例如：ON_COMMAND对应的ON_COMMAND_EX，ON_ONTIFY对应的ON_ONTIFY_EX，等等。扩展宏除了具有普通宏的功能，还有特别的用途。关于扩展宏的具体讨论和分析，见4.4.3.2节。

作为一个总结，下表列出了这些常用的消息映射宏。

表4-1 常用的消息映射宏

消息映射宏	用途
ON_COMMAND	把command message映射到相应的函数
ON_CONTROL	把control notification message映射到相应的函数。MFC根据不同的控制消息，在此基础上定义了更具体的宏，这样用户在使用时就不需要指定通知代码ID，如ON_BN_CLICKED。
ON_MESSAGE	把user-defined message.映射到相应的函数
ON_REGISTERED_MESSAGE	把registered user-defined message映射到相应的函数，实际上nMessage等于0x0C000，nSig等于宏的消息参数。nSig的真实值为Afxsig_lwl。
ON_UPDATE_COMMAND_UI	把user interface user update command message映射到相应的函数上。
ON_COMMAND_RANGE	把一定范围内的command IDs 映射到相应的函数上
ON_UPDATE_COMMAND_UI_RANGE	把一定范围内的user interface user update command message映射到相应的函数上
ON_CONTROL_RANGE	把一定范围内的control notification message映射到相应的函数上

在表4-1中，宏ON_REGISTERED_MESSAGE的定义如下：

#define ON_REGISTERED_MESSAGE(nMessageVariable, memberFxn) \

{ 0xC000, 0, 0, 0,\

(UINT)(UINT*)(&nMessageVariable), \

/*implied ‘AfxSig_lwl’*/ \

(AFX_PMSG)(AFX_PMSGW)(LRESULT\

(AFX_MSG_CALL CWnd::*)\

(WPARAM, LPARAM))&memberFxn }

从上面的定义可以看出，实际上，该消息被映射到WM_COMMAND(0XC000)，指定的registered消息ID存放在nSig域内，nSig的值在这样的映射条目下隐含地定为AfxSig_lwl。由于ID和正常的nSig域存放的值范围不同，所以MFC可以判断出是否是registered消息映射条目。如果是，则使用AfxSig_lwl把消息处理函数转换成参数1为Word、参数2为long、返回值为long的类型。

在介绍完了消息映射的内幕之后，应该讨论消息处理过程了。由于CCmdTarge的特殊性和重要性，在4.3节先对其作一个大略的介绍。

CcmdTarget类

除了CObject类外，还有一个非常重要的类CCmdTarget。所有响应消息或事件的类都从它派生。例如，CWinapp，CWnd，CDocument，CView，CDocTemplate，CFrameWnd，等等。

CCmdTarget类是MFC处理命令消息的基础、核心。MFC为该类设计了许多成员函数和一些成员数据，基本上是为了解决消息映射问题的，而且，很大一部分是针对OLE设计的。在OLE应用中，CCmdTarget是MFC处理模块状态的重要环节，它起到了传递模块状态的作用：其构造函数获取当前模块状态，并保存在成员变量m_pModuleState里头。关于模块状态，在后面章节讲述。

CCmdTarget有两个与消息映射有密切关系的成员函数：DispatchCmdMsg和OnCmdMsg。

静态成员函数DispatchCmdMsg

CCmdTarget的静态成员函数DispatchCmdMsg，用来分发Windows消息。此函数是MFC内部使用的，其原型如下：

static BOOL DispatchCmdMsg(

CCmdTarget* pTarget,

UINT nID,

int nCode,

AFX_PMSG pfn,

void* pExtra,

UINT nSig,

AFX_CMDHANDLERINFO* pHandlerInfo)

关于此函数将在4.4.3.2章节命令消息的处理中作更详细的描述。
虚拟函数OnCmdMsg

CCmdTarget的虚拟函数OnCmdMsg，用来传递和发送消息、更新用户界面对象的状态，其原型如下：

OnCmdMsg(

UINT nID,

int nCode,

void* pExtra,

AFX_CMDHANDLERINFO* pHandlerInfo)

框架的命令消息传递机制主要是通过该函数来实现的。其参数描述参见4.3.3.2章节DispacthCMdMessage的参数描述。

在本书中，命令目标指希望或者可能处理消息的对象；命令目标类指命令目标的类。

CCmdTarget对OnCmdMsg的默认实现：在当前命令目标(this所指)的类和基类的消息映射数组里搜索指定命令消息的消息处理函数（标准Windows消息不会送到这里处理）。

这里使用虚拟函数GetMessageMap得到命令目标类的消息映射入口数组_messageEntries，然后在数组里匹配指定的消息映射条目。匹配标准：命令消息ID相同，控制通知代码相同。因为GetMessageMap是虚拟函数，所以可以确认当前命令目标的确切类。

如果找到了一个匹配的消息映射条目，则使用DispachCmdMsg调用这个处理函数；

如果没有找到，则使用_GetBaseMessageMap得到基类的消息映射数组，查找，直到找到或搜寻了所有的基类（到CCmdTarget）为止；

如果最后没有找到，则返回FASLE。

每个从CCmdTarget派生的命令目标类都可以覆盖OnCmdMsg，利用它来确定是否可以处理某条命令，如果不能，就通过调用下一命令目标的OnCmdMsg，把该命令送给下一个命令目标处理。通常，派生类覆盖OnCmdMsg时，要调用基类的被覆盖的OnCmdMsg。

在MFC框架中，一些MFC命令目标类覆盖了OnCmdMsg，如框架窗口类覆盖了该函数，实现了MFC的标准命令消息发送路径。具体实现见后续章节。

必要的话，应用程序也可以覆盖OnCmdMsg，改变一个或多个类中的发送规定，实现与标准框架发送规定不同的发送路径。例如，在以下情况可以作这样的处理：在要打断发送顺序的类中把命令传给一个非MFC默认对象；在新的非默认对象中或在可能要传出命令的命令目标中。

本节对CCmdTarget的两个成员函数作一些讨论，是为了对MFC的消息处理有一个大致印象。后面4.4.3.2节和4.4.3.3节将作进一步的讨论。

MFC窗口过程

前文曾经提到，所有的消息都送给窗口过程处理，MFC的所有窗口都使用同一窗口过程，消息或者直接由窗口过程调用相应的消息处理函数处理，或者按MFC命令消息派发路径送给指定的命令目标处理。

那么，MFC的窗口过程是什么？怎么处理标准Windows消息？怎么实现命令消息的派发？这些都将是下文要回答的问题。
1. MFC窗口过程的指定
  
  从前面的讨论可知，每一个“窗口类”都有自己的窗口过程。正常情况下使用该“窗口类”创建的窗口都使用它的窗口过程。
  
  MFC的窗口对象在创建HWND窗口时，也使用了已经注册的“窗口类”，这些“窗口类”或者使用应用程序提供的窗口过程，或者使用Windows提供的窗口过程（例如Windows控制窗口、对话框等）。那么，为什么说MFC创建的所有HWND窗口使用同一个窗口过程呢？
  
  在MFC中，的确所有的窗口都使用同一个窗口过程：AfxWndProc或AfxWndProcBase（如果定义了_AFXDLL）。它们的原型如下：
  
  LRESULT CALLBACK
  
  AfxWndProc(HWND hWnd, UINT nMsg, WPARAM wParam, LPARAM lParam)
  
  LRESULT CALLBACK
  
  AfxWndProcBase(HWND hWnd, UINT nMsg, WPARAM wParam, LPARAM lParam)
  
  这两个函数的原型都如4.1.1节描述的窗口过程一样。
  
  如果动态链接到MFC DLL(定义了_AFXDLL)，则AfxWndProcBase被用作窗口过程，否则AfxWndProc被用作窗口过程。AfxWndProcBase首先使用宏AFX_MANAGE_STATE设置正确的模块状态，然后调用AfxWndProc。
  
  下面，假设不使用MFC DLL，讨论MFC如何使用AfxWndProc取代各个窗口的原窗口过程。
  
  窗口过程的取代发生在窗口创建的过程时，使用了子类化(Subclass)的方法。所以，从窗口的创建过程来考察取代过程。从前面可以知道，窗口创建最终是通过调用CWnd::CreateEx函数完成的，分析该函数的流程，如图4-1所示。
  
  图4-1中的CREATESTRUCT结构类型的变量cs包含了传递给窗口过程的初始化参数。CREATESTRUCT结构描述了创建窗口所需要的信息，定义如下：
  
  typedef struct tagCREATESTRUCT {
  
  LPVOID lpCreateParams; //用来创建窗口的数据
  
  HANDLE hInstance; //创建窗口的实例
  
  HMENU hMenu; //窗口菜单
  
  HWND hwndParent; //父窗口
  
  int cy; //高度
  
  int cx; //宽度
  
  int y; //原点Y坐标
  
  int x;//原点X坐标
  
  LONG style; //窗口风格
  
  LPCSTR lpszName; //窗口名
  
  LPCSTR lpszClass; //窗口类
  
  DWORD dwExStyle; //窗口扩展风格
  
  } CREATESTRUCT;
  
  cs表示的创建参数可以在创建窗口之前被程序员修改，程序员可以覆盖当前窗口类的虚拟成员函数PreCreateWindow，通过该函数来修改cs的style域，改变窗口风格。这里cs的主要作用是保存创建窗口的各种信息，::CreateWindowEx函数使用cs的各个域作为参数来创建窗口，关于该函数见2.2.2节。
  
  在创建窗口之前，创建了一个WH_CBT类型的钩子（Hook）。这样，创建窗口时所有的消息都会被钩子过程函数_AfxCbtFilterHook截获。
  
  AfxCbtFilterHook函数首先检查是不是希望处理的Hook──HCBT_CREATEWND。如果是，则先把MFC窗口对象（该对象必须已经创建了）和刚刚创建的Windows窗口对象捆绑在一起，建立它们之间的映射（见后面模块-线程状态）；然后，调用::SetWindowLong设置窗口过程为AfxWndProc，并保存原窗口过程在窗口类成员变量m_pfnSuper中，这样形成一个窗口过程链。需要的时候，原窗口过程地址可以通过窗口类成员函数GetSuperWndProcAddr得到。
  
  这样，AfxWndProc就成为CWnd或其派生类的窗口过程。不论队列消息，还是非队列消息，都送到AfxWndProc窗口过程来处理（如果使用MFC DLL，则AfxWndProcBase被调用，然后是AfxWndProc）。经过消息分发之后没有被处理的消息，将送给原窗口过程处理。
  
  最后，有一点可能需要解释：为什么不直接指定窗口过程为AfxWndProc，而要这么大费周折呢？这是因为原窗口过程（“窗口类”指定的窗口过程）常常是必要的，是不可缺少的。
  
  接下来，讨论AfxWndProc窗口过程如何使用消息映射数据实现消息映射。Windows消息和命令消息的处理不一样，前者没有消息分发的过程。
2. 对Windows消息的接收和处理
  
  Windows消息送给AfxWndProc窗口过程之后，AfxWndProc得到HWND窗口对应的MFC窗口对象，然后，搜索该MFC窗口对象和其基类的消息映射数组，判定它们是否处理当前消息，如果是则调用对应的消息处理函数，否则，进行缺省处理。
  
  下面，以一个应用程序的视窗口创建时，对WM_CREATE消息的处理为例，详细地讨论Windows消息的分发过程。
  
  用第一章的例子，类CTview要处理WM_CREATE消息，使用ClassWizard加入消息处理函数CTview::OnCreate。下面，看这个函数怎么被调用：
  
  视窗口最终调用::CreateEx函数来创建。由Windows系统发送WM_CREATE消息给视的窗口过程AfxWndProc，参数1是创建的视窗口的句柄，参数2是消息ID（WM_CREATE)，参数3、4是消息参数。图4-2描述了其余的处理过程。图中函数的类属限制并非源码中所具有的，而是根据处理过程得出的判断。例如，“CWnd::WindowProc”表示CWnd类的虚拟函数WindowProc被调用，并不一定当前对象是CWnd类的实例，事实上，它是CWnd派生类CTview类的实例；而“CTview::OnCreate”表示CTview的消息处理函数OnCreate被调用。下面描述每一步的详细处理。
  1. 从窗口过程到消息映射

首先，分析AfxWndProc窗口过程函数。

AfxWndProc的原型如下：

LRESULT AfxWndProc(HWND hWnd,

UINT nMsg, WPARAM wParam, LPARAM lParam)

如果收到的消息nMsg不是WM_QUERYAFXWNDPROC（该消息被MFC内部用来确认窗口过程是否使用AfxWndProc），则从hWnd得到对应的MFC Windows对象（该对象必须已存在，是永久性<Permanent>对象）指针pWnd。pWnd所指的MFC窗口对象将负责完成消息的处理。这里，pWnd所指示的对象是MFC视窗口对象，即CTview对象。

然后，把pWnd和AfxWndProc接受的四个参数传递给函数AfxCallWndProc执行。

AfxCallWndProc原型如下：

LRESULT AFXAPI AfxCallWndProc(CWnd* pWnd, HWND hWnd,

UINT nMsg, WPARAM wParam = 0, LPARAM lParam = 0)

MFC使用AfxCallWndProc函数把消息送给CWnd类或其派生类的对象。该函数主要是把消息和消息参数(nMsg、wParam、lParam)传递给MFC窗口对象的成员函数WindowProc（pWnd->WindowProc）作进一步处理。如果是WM_INITDIALOG消息，则在调用WindowProc前后要作一些处理。

WindowProc的函数原型如下：

LRESULT CWnd::WindowProc(UINT message,

WPARAM wParam, LPARAM lParam)

这是一个虚拟函数，程序员可以在CWnd的派生类中覆盖它，改变MFC分发消息的方式。例如，MFC的CControlBar就覆盖了WindowProc，对某些消息作了自己的特别处理，其他消息处理由基类的WindowProc函数完成。

但是在当前例子中，当前对象的类CTview没有覆盖该函数，所以CWnd的WindowProc被调用。

这个函数把下一步的工作交给OnWndMsg函数来处理。如果OnWndMsg没有处理，则交给DefWindowProc来处理。

OnWndMsg和DefWindowProc都是CWnd类的虚拟函数。

OnWndMsg的原型如下：

BOOL CWnd::OnWndMsg( UINT message,

WPARAM wParam, LPARAM lParam,RESULT*pResult );

该函数是虚拟函数。

和WindowProc一样，由于当前对象的类CTview没有覆盖该函数，所以CWnd的OnWndMsg被调用。

在CWnd中，MFC使用OnWndMsg来分别处理各类消息：

如果是WM_COMMAND消息，交给OnCommand处理；然后返回。

如果是WM_NOTIFY消息，交给OnNotify处理；然后返回。

如果是WM_ACTIVATE消息，先交给_AfxHandleActivate处理（后面5.3.3.7节会解释它的处理），再继续下面的处理。

如果是WM_SETCURSOR消息，先交给_AfxHandleSetCursor处理；然后返回。

如果是其他的Windows消息（包括WM_ACTIVATE），则

首先在消息缓冲池进行消息匹配，

若匹配成功，则调用相应的消息处理函数；

若不成功，则在消息目标的消息映射数组中进行查找匹配，看它是否处理当前消息。这里，消息目标即CTview对象。

如果消息目标处理了该消息，则会匹配到消息处理函数，调用它进行处理；

否则，该消息没有被应用程序处理，OnWndMsg返回FALSE。

关于Windows消息和消息处理函数的匹配，见下一节。

缺省处理函数DefWindowProc将在讨论对话框等的实现时具体分析。

Windows消息的查找和匹配

CWnd或者派生类的对象调用OnWndMsg搜索本对象或者基类的消息映射数组，寻找当前消息的消息处理函数。如果当前对象或者基类处理了当前消息，则必定在其中一个类的消息映射数组中匹配到当前消息的处理函数。

消息匹配是一个比较耗时的任务，为了提高效率，MFC设计了一个消息缓冲池，把要处理的消息和匹配到的消息映射条目（条目包含了消息处理函数的地址）以及进行消息处理的当前类等信息构成一条缓冲信息，放到缓冲池中。如果以后又有同样的消息需要同一个类处理，则直接从缓冲池查找到对应的消息映射条目就可以了。

MFC用哈希查找来查询消息映射缓冲池。消息缓冲池相当于一个哈希表，它是应用程序的一个全局变量，可以放512条最新用到的消息映射条目的缓冲信息，每一条缓冲信息是哈希表的一个入口。

采用AFX_MSG_CACHE结构描述每条缓冲信息，其定义如下：

struct AFX_MSG_CACHE

{

UINT nMsg;

const AFX_MSGMAP_ENTRY* lpEntry;

const AFX_MSGMAP* pMessageMap;

};

nMsg存放消息ID，每个哈希表入口有不同的nMsg。

lpEnty存放和消息ID匹配的消息映射条目的地址，它可能是this所指对象的类的映射条目，也可能是这个类的某个基类的映射条目，也可能是空。

pMessageMap存放消息处理函数匹配成功时进行消息处理的当前类（this所指对象的类）的静态成员变量messageMap的地址，它唯一的标识了一个类（每个类的messageMap变量都不一样）。

this所指对象是一个CWnd或其派生类的实例，是正在处理消息的MFC窗口对象。

哈希查找：使用消息ID的值作为关键值进行哈希查找，如果成功，即可从lpEntry获得消息映射条目的地址，从而得到消息处理函数及其原型。

如何判断是否成功匹配呢？有两条标准：

第一，当前要处理的消息message在哈希表（缓冲池）中有入口；第二，当前窗口对象（this所指对象）的类的静态变量messageMap的地址应该等于本条缓冲信息的pMessagMap。MFC通过虚拟函数GetMessagMap得到messageMap的地址。

如果在消息缓冲池中没有找到匹配，则搜索当前对象的消息映射数组，看是否有合适的消息处理函数。

如果匹配到一个消息处理函数,则把匹配结果加入到消息缓冲池中，即填写该条消息对应的哈希表入口：

nMsg=message;

pMessageMap=this->GetMessageMap;

lpEntry=查找结果

然后，调用匹配到的消息处理函数。否则（没有找到），使用_GetBaseMessageMap得到基类的消息映射数组，查找和匹配；直到匹配成功或搜寻了所有的基类（到CCmdTarget）为止。

如果最后没有找到，则也把该条消息的匹配结果加入到缓冲池中。和匹配成功不同的是：指定lpEntry为空。这样OnWndMsg返回，把控制权返还给AfxCallWndProc函数，AfxCallWndProc将继续调用DefWndProc进行缺省处理。

消息映射数组的搜索在CCmdTarget::OnCmdMsg函数中也用到了，而且算法相同。为了提高速度，MFC把和消息映射数组条目逐一比较、匹配的函数AfxFindMessageEntry用汇编书写。

const AFX_MSGMAP_ENTRY* AFXAPI

AfxFindMessageEntry(const AFX_MSGMAP_ENTRY* lpEntry,

UINT nMsg, UINT nCode, UINT nID)

第一个参数是要搜索的映射数组的入口；第二个参数是Windows消息标识；第三个参数是控制通知消息标识；第四个参数是命令消息标识。

对Windows消息来说，nMsg是每条消息不同的，nID和nCode为0。

对命令消息来说，nMsg固定为WM_COMMAND，nID是每条消息不同，nCode都是CN_COMMAND（定义为0）。

对控制通知消息来说，nMsg固定为WM_COMMAND或者WM_NOTIFY，nID和nCode是每条消息不同。

对于Register消息，nMsg指定为0XC000，nID和nCode为0。在使用函数AfxFindMessageEntry得到匹配结果之后，还必须判断nSig是否等于message，只有相等才调用对应的消息处理函数。
Windows消息处理函数的调用

对一个Windows消息，匹配到了一个消息映射条目之后，将调用映射条目所指示的消息处理函数。

调用处理函数的过程就是转换映射条目的pfn指针为适当的函数类型并执行它：MFC定义了一个成员函数指针mmf，首先把消息处理函数的地址赋值给该函数指针，然后根据消息映射条目的nSig值转换指针的类型。但是，要给函数指针mmf赋值，必须使该指针可以指向所有的消息处理函数，为此则该指针的类型是所有类型的消息处理函数指针的联合体。

对上述过程，MFC的实现大略如下：

union MessageMapFunctions mmf；

mmf.pfn = lpEntry->pfn;

swithc (value_of_nsig){

…

case AfxSig_is: //OnCreate就是该类型

lResult = (this->*mmf.pfn_is)((LPTSTR)lParam);

break;

…

default:

ASSERT(FALSE); break;

}

…

LDispatchRegistered: // 处理registered windows messages

ASSERT(message >= 0xC000);

mmf.pfn = lpEntry->pfn;

lResult = (this->*mmf.pfn_lwl)(wParam, lParam);

…

如果消息处理函数有返回值，则返回该结果，否则，返回TRUE。

对于图4-1所示的例子，nSig等于AfxSig_is，所以将执行语句

(this->*mmf.pfn_is)((LPTSTR)lParam)

也就是对CTview::OnCreate的调用。

顺便指出，对于Registered窗口消息，消息处理函数都是同一原型，所以都被转换成lwl型（关于Registered窗口消息的映射，见4.4.2节）。

综上所述，标准Windwos消息和应用程序消息中的Registered消息，由窗口过程直接调用相应的处理函数处理：

如果某个类型的窗口（C++类）处理了某条消息（覆盖了CWnd或直接基类的处理函数），则对应的HWND窗口（Winodws window）收到该消息时就调用该覆盖函数来处理；如果该类窗口没有处理该消息，则调用实现该处理函数最直接的基类（在C++的类层次上接近该类）来处理，上述例子中如果CTview不处理WM_CREATE消息，则调用上一层的CWnd::OnCreate处理；

如果基类都不处理该消息，则调用DefWndProc来处理。
消息映射机制完成虚拟函数功能的原理

综合对Windows消息的处理来看，MFC使用消息映射机制完成了C++虚拟函数的功能。这主要基于以下几点：

所有处理消息的类从CCmdTarget派生。
使用静态成员变量_messageEntries数组存放消息映射条目，使用静态成员变量messageMap来唯一地区别和得到类的消息映射。
通过GetMessage虚拟函数来获取当前对象的类的messageMap变量，进而得到消息映射入口。
按照先底层，后基层的顺序在类的消息映射数组中搜索消息处理函数。基于这样的机制，一般在覆盖基类的消息处理函数时，应该调用基类的同名函数。

以上论断适合于MFC其他消息处理机制，如对命令消息的处理等。不同的是其他消息处理有一个命令派发/分发的过程。

下一节，讨论命令消息的接受和处理。

对命令消息的接收和处理
1. MFC标准命令消息的发送

在SDI或者MDI应用程序中，命令消息由用户界面对象（如菜单、工具条等）产生，然后送给主边框窗口。主边框窗口使用标准MFC窗口过程处理命令消息。窗口过程把命令传递给MFC主边框窗口对象，开始命令消息的分发。MFC边框窗口类CFrameWnd提供了消息分发的能力。

下面，还是通过一个例子来说明命令消息的处理过程。

使用AppWizard产生一个单文档应用程序t。从help菜单选择“About”，就会弹出一个ABOUT对话框。下面，讨论从命令消息的发出到对话框弹出的过程。

首先，选择“ About”菜单项的动作导致一个Windows命令消息ID_APP_ABOUT的产生。Windows系统发送该命令消息到边框窗口，导致它的窗口过程AfxWndProc被调用，参数1是边框窗口的句柄，参数2是消息ID（即WM_COMMAND），参数3、4是消息参数，参数3的值是ID_APP_ABOUT。接着的系列调用如图4-3所示。

下面分别讲述每一层所调用的函数。

前4步同对Windows消息的处理。这里接受消息的HWND窗口是主边框窗口，因此，AfxWndProc根据HWND句柄得到的MFC窗口对象是MFC边框窗口对象。

在4.2.2节谈到，如果CWnd::OnWndMsg判断要处理的消息是命令消息(WM_COMMAND)，就调用OnCommand进一步处理。由于OnCommand是虚拟函数，当前MFC窗口对象是边框窗口对象，它的类从CFrameWnd类导出，没有覆盖CWnd的虚拟函数OnCommand，而CFrameWnd覆盖了CWnd的OnCommand，所以，CFrameWnd的OnCommand被调用。换句话说，CFrameWnd的OnCommand被调用是动态约束的结果。接着介绍的本例子的有关调用，也是通过动态约束而实际发生的函数调用。

接着的有关调用，将不进行为什么调用某个类的虚拟或者消息处理函数的分析。

（1）CFrameWnd的OnCommand函数

BOOL CFrameWnd::OnCommand(WPARAM wParam, LPARAM lParam)

参数wParam的低阶word存放了菜单命令nID或控制子窗口ID；如果消息来自控制窗口，高阶word存放了控制通知消息；如果消息来自加速键，高阶word值为1；如果消息来自菜单，高阶word值为0。

如果是通知消息，参数lParam存放了控制窗口的句柄hWndCtrl，其他情况下lParam是0。

在这个例子里，低阶word是ID_APP_ABOUT，高阶word是1；lParam是0。

MFC对CFrameWnd的缺省实现主要是获得一个机会来检查程序是否运行在HELP状态，需要执行上下文帮助，如果不需要，则调用基类的CWnd::OnCommand实现正常的命令消息发送。

（2）CWnd的OnCommand函数

BOOL CWnd::OnCommand(WPARAM wParam, LPARAM lParam)

它按一定的顺序处理命令或者通知消息，如果发送成功，返回TRUE，否则，FALSE。处理顺序如下：

如果是命令消息，则调用OnCmdMsg(nID, CN_UPDATE_COMMAND_UI, &state, NULL)测试nID命令是否已经被禁止，如果这样，返回FALSE；否则，调用OnCmdMsg进行命令发送。关于CN_UPDATE_COMMAND_UI通知消息，见后面用户界面状态的更新处理。

如果是控制通知消息，则先用ReflectLastMsg反射通知消息到子窗口。如果子窗口处理了该消息，则返回TRUE；否则，调用OnCmdMsg进行命令发送。关于通知消息的反射见后面4.4.4.3节。OnCommand给OnCmdMsg传递四个参数：nID，即命令消息ID；nCode，如果是通知消息则为通知代码，如果是命令消息则为NC_COMMAND(即0)；其余两个参数为空。

（3）CFrameWnd的OnCmdMsg函数

BOOL CFrameWnd::OnCmdMsg(UINT nID, int nCode, void* pExtra,

AFX_CMDHANDLERINFO* pHandlerInfo)

参数1是命令ID；如果是通知消息（WM_COMMAND或者WM_NOTIFY），则参数2表示通知代码，如果是命令消息，参数2是0；如果是WM_NOTIFY，参数3包含了一些额外的信息；参数4在正常消息处理中应该是空。

在这个例子里，参数1是命令ID，参数2为0，参数3空。

OnCmdMsg是虚拟函数，CFrameWnd覆盖了该函数，当前对象（this所指）是MFC单文档的边框窗口对象。故CFrameWnd的OnCmdMsg被调用。CFrameWnd::OnCmdMsg在MFC消息发送中占有非常重要的地位，MFC对该函数的缺省实现确定了MFC的标准命令发送路径：

送给活动（Active）视处理，调用活动视的OnCmdMsg。由于当前对象是MFC视对象，所以，OnCmdMsg将搜索CTview及其基类的消息映射数组，试图得到相应的处理函数。
如果视对象自己不处理，则视得到和它关联的文档，调用关联文档的OnCmdMsg。由于当前对象是MFC视对象，所以，OnCmdMsg将搜索CTdoc及其基类的消息映射数组，试图得到相应的处理函数。
如果文档对象不处理，则它得到管理文档的文档模板对象，调用文档模板的OnCmdMsg。由于当前对象是MFC文档模板对象，所以，OnCmdMsg将搜索文档模板类及其基类的消息映射数组，试图得到相应的处理函数。
如果文档模板不处理，则把没有处理的信息逐级返回：文档模板告诉文档对象，文档对象告诉视对象，视对象告诉边框窗口对象。最后，边框窗口得知，视、文档、文档模板都没有处理消息。
CFrameWnd的OnCmdMsg继续调用CWnd::OnCmdMsg（斜体表示有类属限制）来处理消息。由于CWnd没有覆盖OnCmdMsg，故实际上调用了函数CCmdTarget::OnCmdMsg。由于当前对象是MFC边框窗口对象，所以OnCmdMsg函数将搜索CMainFrame类及其所有基类的消息映射数组，试图得到相应的处理函数。CWnd没有实现OnCmdMsg却指定要执行其OnCmdMsg函数，可能是为了以后MFC给CWnd实现了OnCmdMsg之后其他代码不用改变。

这一步是边框窗口自己尝试处理消息。
如果边框窗口对象不处理，则送给应用程序对象处理。调用CTApp的OnCmdMsg，由于实际上CTApp及其基类CWinApp没有覆盖OnCmdMsg，故实际上调用了函数CCmdTarget::OnCmdMsg。由于当前对象是MFC应用程序对象，所以OnCmdMsg函数将搜索CTApp类及其所有基类的的消息映射入口数组，试图得到相应的处理函数
如果应用程序对象不处理，则返回FALSE，表明没有命令目标处理当前的命令消息。这样，函数逐级别返回，OnCmdMsg告诉OnCommand消息没有被处理，OnCommand告诉OnWndMsg消息没有被处理，OnWndMsg告诉WindowProc消息没有被处理，于是WindowProc调用DefWindowProc进行缺省处理。

本例子在第六步中，应用程序对ID_APP_ABOUT消息作了处理。它找到处理函数CTApp::OnAbout，使用DispatchCmdMsg派发消息给该函数处理。

如果是MDI边框窗口，标准发送路径还有一个环节，该环节和第二、三、四步所涉及的OnCmdMsg函数，将在下两节再次具体分析。

命令消息的派发和消息的多次处理

命令消息的派发

如前3.1所述，CCmdTarget的静态成员函数DispatchCmdMsg用来派发命令消息给指定的命令目标的消息处理函数。

static BOOL DispatchCmdMsg(CCmdTarget* pTarget,

UINT nID, int nCode,

AFX_PMSG pfn, void* pExtra, UINT nSig,

AFX_CMDHANDLERINFO* pHandlerInfo)

前面在讲CCmdTarget时，提到了该函数。这里讲述它的实现：

第一个参数指向处理消息的对象；第二个参数是命令ID；第三个是通知消息等；第四个是消息处理函数地址；第五个参数用于存放一些有用的信息，根据nCode的值表示不同的意义，例如当消息是WM_NOFITY，指向一个NMHDR结构（关于WM_NOTIFY，参见4.4.4.2节通知消息的处理）；第六个参数标识消息处理函数原型；第七个参数是一个指针，指向AFX_CMDHANDLERINFO结构。前六个参数（除了第五个外）都是向函数传递信息，第五个和第七个参数是双向的，既向函数传递信息，也可以向调用者返回信息。

关于AFX_CMDHANDLERINFO结构：

struct AFX_CMDHANDLERINFO

{

CCmdTarget* pTarget;

void (AFX_MSG_CALL CCmdTarget::*pmf)(void);

};

第一个成员是一个指向命令目标对象的指针，第二个成员是一个指向CCmdTarget成员函数的指针。

该函数的实现流程可以如下描述：

首先，它检查参数pHandlerInfo是否空，如果不空，则用pTarget和pfn填写其指向的结构，返回TRUE；通常消息处理时传递来的pHandlerInfo空，而在使用OnCmdMsg来测试某个对象是否处理某条命令时，传递一个非空的pHandlerInfo指针。若返回TRUE，则表示可以处理那条消息。

如果pHandlerInfo空，则进行消息处理函数的调用。它根据参数nSig的值，把参数pfn的类型转换为要调用的消息处理函数的类型。这种指针转换技术和前面讲述的Windows消息的处理是一样的。
消息的多次处理

如果消息处理函数不返回值，则DispatchCmdMsg返回TRUE；否则，DispatchCmdMsg返回消息处理函数的返回值。这个返回值沿着消息发送相反的路径逐级向上传递，使得各个环节的OnCmdMsg和OnCommand得到返回的处理结果：TRUE或者FALSE，即成功或者失败。

这样就产生了一个问题，如果消息处理函数有意返回一个FALSE，那么不就传递了一个错误的信息？例如，OnCmdMsg函数得到FALSE返回值，就认为消息没有被处理，它将继续发送消息到下一环节。的确是这样的，但是这不是MFC的漏洞，而是有意这么设计的，用来处理一些特别的消息映射宏，实现同一个消息的多次处理。

通常的命令或者通知消息是没有返回值的（见4.4.2节的消息映射宏），仅仅一些特殊的消息处理函数具有返回值，这类消息的消息处理函数是使用扩展消息映射宏映射的，例如：

ON_COMMAND对应的ON_COMMAND_EX

扩展映射宏和对应的普通映射宏的参数个数相同，含义一样。但是扩展映射宏的消息处理函数的原型和对应的普通映射宏相比，有两个不同之处：一是多了一个UINT类型的参数，另外就是有返回值（返回BOOL类型）。回顾4.4.2章节，范围映射宏ON_COMMAND_RANGE的消息处理函数也有一个这样的参数，该参数在两处的含义是一样的，例如：命令消息扩展映射宏ON_COMMAND_EX定义的消息处理函数解释该参数是当前要处理的命令消息ID。有返回值的意义在于：如果扩展映射宏的消息处理函数返回FALSE，则导致当前消息被发送给消息路径上的下一个消息目标处理。

综合来看，ON_COMMAND_EX宏有两个功能：

一是可以把多个命令消息指定给一个消息处理函数处理。这类似于ON_COMMAND_RANGE宏的作用。不过，这里的多条消息的命令ID或者控制子窗口ID可以不连续，每条消息都需要一个ON_COMMAND_EX宏。

二是可以让几个消息目标处理同一个命令或者通知或者反射消息。如果消息发送路径上较前的命令目标不处理消息或者处理消息后返回FALSE，则下一个命令目标将继续处理该消息。

对于通知消息、反射消息，它们也有扩展映射宏，而且上述论断也适合于它们。例如：

ON_NOTIFY对应的ON_NOTIFY_EX

ON_CONTROL对应的ON_CONTROL_EX

ON_CONTROL_REFLECT对应的ON_CONTROL_REFLECT_EX

等等。

范围消息映射宏也有对应的扩展映射宏，例如：

ON_NOTIFY_RANGE对应的ON_NOTIFY_EX_RANGE

ON_COMMAND_RANGE对应的ON_COMMAND_EX_RANGE

使用这些宏的目的在于利用扩展宏的第二个功能：实现消息的多次处理。

关于扩展消息映射宏的例子，参见13.2..4.4节和13.2.4.6节。

一些消息处理类的OnCmdMsg的实现

从以上论述知道，OnCmdMsg虚拟函数在MFC命令消息的发送中扮演了重要的角色，CFrameWnd的OnCmdMsg实现了MFC的标准命令消息发送路径。

那么，就产生一个问题：如果命令消息不送给边框窗口对象，那么就不会有按标准命令发送路径发送消息的过程？答案是肯定的。例如一个菜单被一个对话框窗口所拥有，那么，菜单命令将送给MFC对话框窗口对象处理，而不是MFC边框窗口处理，当然不会和CFrameWnd的处理流程相同。

但是，有一点需要指出，一般标准的SDI和MDI应用程序，只有主边框窗口拥有菜单和工具条等用户接口对象，只有在用户与用户接口对象进行交互时，才产生命令，产生的命令必然是送给SDI或者MDI程序的主边框窗口对象处理。

下面，讨论几个MFC类覆盖OnCmdMsg虚拟函数时的实现。这些类的OnCmdMsg或者可能是标准MFC命令消息路径的一个环节，或者可能是一个独立的处理过程（对于其中的MFC窗口类）。

从分析CView的OnCmdMsg实现开始。

CView的OnCmdMsg

CView::OnCmdMsg(UINT nID, int nCode, void* pExtra,

AFX_CMDHANDLERINFO* pHandlerInfo)

首先，调用CWnd::OnCmdMsg，结果是搜索当前视的类和基类的消息映射数组，搜索顺序是从下层到上层。若某一层实现了对命令消息nID的处理，则调用它的实现函数；否则，调用m_pDocument->OnCmdMsg，把命令消息送给文档类处理。m_pDocument是和当前视关联的文档对象指针。如果文档对象类实现了OnCmdMsg，则调用它的覆盖函数；否则，调用基类(例如CDocument)的OnCmdMsg。

接着，讨论CDocument的实现。

CDocument的 OnCmdMsg

BOOL CDocument::OnCmdMsg(UINT nID, int nCode, void* pExtra,

AFX_CMDHANDLERINFO* pHandlerInfo)

首先，调用CCmdTarget::OnCmdMsg，导致当前对象(this)的类和基类的消息映射数组被搜索，看是否有对应的消息处理函数可用。如果有，就调用它；如果没有，则调用文档模板的OnCmdMsg函数（m_pTemplate->OnCmdMsg）把消息送给文档模板处理。

MFC文档模板没有覆盖OnCmdMsg，导致基类CCmdTarget的OnCmdMsg被调用，看是否有文档模板类或基类实现了对消息的处理。是的话，调用对应的消息处理函数，否则，返回FALSE。从前面的分析知道，CCmdTarget类的消息映射数组是空的，所以这里返回FALSE。

CDialog的OnCmdMsg

BOOL CDialog::OnCmdMsg(UINT nID, int nCode, void* pExtra,

AFX_CMDHANDLERINFO* pHandlerInfo)

调用CWnd::OnCmdMsg，让对话框或其基类处理消息。
如果还没有处理，而且是控制消息或系统命令或非命令按钮，则返回FALSE，不作进一步处理。否则，调用父窗口的OnCmdmsg(GetParent()->OnCmdmsg)把消息送给父窗口处理。
如果仍然没有处理，则调用当前线程的OnCmdMsg(GetThread()->OnCmdMsg)把消息送给线程对象处理。
如果最后没有处理，返回FALSE。

CMDIFrameWnd的OnCmdMsg

对于MDI应用程序，MDI主边框窗口首先是把命令消息发送给活动的MDI文档边框窗口进行处理。MDI主边框窗口对OnCmdMsg的实现函数的原型如下：

BOOL CMDIFrameWnd::OnCmdMsg(UINT nID, int nCode, void* pExtra,

AFX_CMDHANDLERINFO* pHandlerInfo)

如果有激活的文档边框窗口，则调用它的OnCmdMsg(MDIGetActive（）->OnCmdMsg)把消息交给它进行处理。MFC的文档边框窗口类并没有覆盖OnCmdMsg函数，所以基类CFrameWnd的函数被调用，导致文档边框窗口的活动视、文档边框窗口本身、应用程序对象依次来进行消息处理。
如果文档边框窗口没有处理，调用CFrameWnd::OnCmdMsg把消息按标准路径发送，重复第一次的步骤，不过对于MDI边框窗口来说不存在活动视，所以省却了让视处理消息的必要；接着让MDI边框窗口本身来处理消息，如果它还没有处理，则让应用程序对象进行消息处理──虽然这是一个无用的重复。

除了CView、CDocument和CMDIFrameWnd类，还有几个OLE相关的类覆盖了OnCmdMsg函数。OLE的处理本书暂不涉及，CDialog::OnCmdMsg将在对话框章节专项讨论其具体实现。

一些消息处理类的OnCommand的实现

除了虚拟函数OnCmdMsg，还有一个虚拟函数OnCommand在命令消息的发送中占有重要地位。在处理命令或者通知消息时，OnCommand被MFC窗口过程调用，然后它调用OnCmdMsg按一定路径传送消息。除了CWnd类和一些OLE相关类外，MFC里主要还有MDI边框窗口实现了OnCommand。

BOOL CMDIFrameWnd::OnCommand(WPARAM wParam, LPARAM lParam)

第一，如果存在活动的文档边框窗口，则使用AfxCallWndProc调用它的窗口过程，把消息送给文档边框窗口来处理。这将导致文档边框窗口的OnCmdMsg作如下的处理：

活动视处理消息→与视关联的文档处理消息→本文档边框窗口处理消息→应用程序对象处理消息→文档边框窗口缺省处理

任何一个环节如果处理消息，则不再向下发送消息，处理终止。如果消息仍然没有被处理，就只有交给主边框窗口了。

第二，第一步没有处理命令，继续调用CFrameWnd::OnCommand，将导致CMDIFrameWnd的OnCmdMsg被调用。从前面的分析知道，将再次把消息送给MDI边框窗口的活动文档边框窗口，第一步的过程除了文档边框窗口缺省处理外都将被重复。具体的处理过程见前文的CMDIFrameWnd::OnCmdMsg函数。

对于MDI消息，如果主边框窗口还不处理的话，交给CMDIFrameWnd的DefWindowProc作缺省处理。
消息没有处理，返回FALSE。

上述分析综合了OnCommand和OnCmdMsg的处理，它们是在MFC内部MDI边框窗口处理命令消息的完整的流程和标准的步骤。整个处理过程再次表明了边框窗口在处理命令消息时的中心作用。从程序员的角度来看，可以认为整个标准处理路径如下：

活动视处理消息→与视关联的文档处理消息→本文档边框窗口处理消息→应用程序对象处理消息→文档边框窗口缺省处理→MDI边框窗口处理消息→MDI边框窗口缺省处理

任何一个环节如果处理消息，不再向下发送消息，急处理终止。

对控制通知消息的接收和处理
1. WM_COMMAND控制通知消息的处理

WM_COMMAND控制通知消息的处理和WM_COMMAND命令消息的处理类似，但是也有不同之处。

首先，分析处理WM_COMMAND控制通知消息和命令消息的相似处。如前所述，命令消息和控制通知消息都是由窗口过程给OnCommand处理（参见CWnd::OnWndMsg的实现），OnCommand通过wParam和lParam参数区分是命令消息或通知消息，然后送给OnCmdMsg处理（参见CWnd::OnCommnd的实现）。

其次，两者的不同之处是：

命令消息一般是送给主边框窗口的，这时，边框窗口的OnCmdMsg被调用；而控制通知消息送给控制子窗口的父窗口，这时，父窗口的OnCmdMsg被调用。
OnCmdMsg处理命令消息时，通过命令分发可以由多种命令目标处理，包括非窗口对象如文档对象等；而处理控制通知消息时，不会有消息分发的过程，控制通知消息最终肯定是由窗口对象处理的。

不过，在某种程度上可以说，控制通知消息由窗口对象处理是一种习惯和约定。当使用ClassWizard进行消息映射时，它不提供把控制通知消息映射到非窗口对象的机会。但是，手工地添加消息映射，让非窗口对象处理控制通知消息的可能是存在的。例如，对于CFormView，一方面它具备接受WM_COMMAND通知消息的条件，另一方面，具备把WM_COMMAND消息派发给关联文档对象处理的能力，所以给CFormView的通知消息是可以让文档对象处理的。

事实上，BN_CLICKED控制通知消息的处理和命令消息的处理完全一样，因为该消息的通知代码是0，ON_BN_CLICKED(id，memberfunction)和ON_COMMAND(id，memberfunction)是等同的。

此外，MFC的状态更新处理机制就是建立在通知消息可以发送给各种命令目标的基础之上的。关于MFC的状态更新处理机制，见后面4.4.4.4节的讨论。

控制通知消息可以反射给子窗口处理。OnCommand判定当前消息是WM_COMAND通知消息之后，首先它把消息反射给控制子窗口处理，如果子窗口处理了反射消息，OnCommand不会继续调用OnCmdMsg让父窗口对象来处理通知消息。

WM_NOTIFY消息及其处理:

（1）WM_NOTIFY消息

还有一种通知消息WM_NOTIFY，在Win32中用来传递信息复杂的通知消息。WM_NOTIFY消息怎么来传递复杂的信息呢？WM_NOTIFY的消息参数wParam包含了发送通知消息的控制窗口ID，另一个参数lParam包含了一个指针。该指针指向一个NMHDR结构，或者更大的结构，只要它的第一个结构成员是NMHDR结构。

NMHDR结构：

typedef struct tagNMHDR {

HWND hwndFrom;

UINT idFrom;

UINT code;

} NMHDR;

上述结构有三个成员，分别是发送通知消息的控制窗口的句柄、ID和通知消息代码。

举一个更大、更复杂的结构例子：列表控制窗发送LVN_KEYDOWN控制通知消息，则lParam包含了一个指向LV_KEYDOWN结构的指针。其结构如下：

typedef struct tagLV_KEYDOWN {

NMHDR hdr;

WORD wVKey;

UINT flags;

}LV_KEYDOWN;

它的第一个结构成员hdr就是NMHDR类型。其他成员包含了更多的信息：哪个键被按下，哪些辅助键(SHIFT、CTRL、ALT等)被按下。

（2）WM_NOTIFY消息的处理

在分析CWnd::OnWndMsg函数时，曾指出当消息是WM_NOTIFY时，它把消息传递给OnNotify虚拟函数处理。这是一个虚拟函数，类似于OnCommand，CWnd和派生类都可以覆盖该函数。OnNotify的函数原型如下：

BOOL CWnd::OnNotify(WPARAM, LPARAM lParam, LRESULT* pResult)

参数1是发送通知消息的控制窗口ID，没有被使用；参数2是一个指针；参数3指向一个long类型的数据，用来返回处理结果。

WM_NOTIFY消息的处理过程如下：

反射消息给控制子窗口处理。
如果子窗口不处理反射消息，则交给OnCmdMsg处理。给OnCmdMsg的四个参数分别如下：第一个是命令消息ID，第四个为空；第二个高阶word是WM_NOTIFY，低阶word是通知消息；第三个参数是指向AFX_NOTIFY结构的指针。第二、三个参数有别于OnCommand送给OnCmdMsg的参数。

AFX_NOTIFY结构：

struct AFX_NOTIFY

{

LRESULT* pResult;

NMHDR* pNMHDR;

};

pNMHDR的值来源于参数2 lParam，该结构的域pResult用来保存处理结果，域pNMHDR用来传递信息。

OnCmdMsg后续的处理和WM_COMMAND通知消息基本相同，只是在派发消息给消息处理函数时，DispatchMsdMsg的第五个参数pExtra指向OnCmdMsg传递给它的AFX_NOTIFY类型的参数，而不是空指针。这样，处理函数就得到了复杂的通知消息信息。

消息反射

（1）消息反射的概念

前面讨论控制通知消息时，曾经多次提到了消息反射。MFC提供了两种消息反射机制，一种用于OLE控件，一种用于Windows控制窗口。这里只讨论后一种消息反射。

Windows控制常常发送通知消息给它们的父窗口，通常控制消息由父窗口处理。但是在MFC里头，父窗口在收到这些消息后，或者自己处理，或者反射这些消息给控制窗口自己处理，或者两者都进行处理。如果程序员在父窗口类覆盖了通知消息的处理（假定不调用基类的实现），消息将不会反射给控制子窗口。这种反射机制是MFC实现的，便于程序员创建可重用的控制窗口类。

MFC的CWnd类处理以下控制通知消息时，必要或者可能的话，把它们反射给子窗口处理：

WM_CTLCOLOR，

WM_VSCROLL，WM_HSCROLL，

WM_DRAWITEM，WM_MEASUREITEM，

WM_COMPAREITEM，WM_DELETEITEM，

WM_CHARTOITEM，WM_VKEYTOITEM，

WM_COMMAND、WM_NOTIFY。

例如，对WM_VSCROLL、WM_HSCROLL消息的处理，其消息处理函数如下：

void CWnd::OnHScroll(UINT, UINT, CScrollBar* pScrollBar)

{

//如果是一个滚动条控制，首先反射消息给它处理

if (pScrollBar != NULL && pScrollBar->SendChildNotifyLastMsg())

return; //控制窗口成功处理了该消息

Default();

}

又如：在讨论OnCommand和OnNofity函数处理通知消息时，都曾经指出，它们首先调用ReflectLastMsg把消息反射给控制窗口处理。

为了利用消息反射的功能，首先需要从适当的MFC窗口派生出一个控制窗口类，然后使用ClassWizard给它添加消息映射条目，指定它处理感兴趣的反射消息。下面，讨论反射消息映射宏。

上述消息的反射消息映射宏的命名遵循以下格式：“ON”前缀+消息名+“REFLECT”后缀，例如：消息WM_VSCROLL的反射消息映射宏是ON_WM_VSCROLL_REFECT。但是通知消息WM_COMMAND和WM_NOTIFY是例外，分别为ON_CONTROL_REFLECT和ON_NOFITY_REFLECT。状态更新通知消息的反射消息映射宏是ON_UPDATE_COMMAND_UI_REFLECT。

消息处理函数的名字和去掉“WM_”前缀的消息名相同，例如WM_HSCROLL反射消息处理函数是Hscroll。

消息处理函数的原型这里不一一列举了。

这些消息映射宏和消息处理函数的原型可以借助于ClassWizard自动地添加到程序中。ClassWizard添加消息处理函数时，可以处理的反射消息前面有一个等号，例如处理WM_HSCROLL的反射消息，选择映射消息“=EN_HSC ROLL”。ClassWizard自动的添加消息映射宏和处理函数到框架文件。

（2）消息反射的处理过程

如果不考虑有OLE控件的情况，消息反射的处理流程如下图所示：

首先，调用CWnd的成员函数SendChildNotifyLastMsg，它从线程状态得到本线程最近一次获取的消息（关于线程状态，后面第9章会详细介绍）和消息参数，并且把这些参数传递给函数OnChildNotify。注意，当前的CWnd对象就是MFC控制子窗口对象。

OnChlidNofify是CWnd定义的虚拟函数，不考虑OLE控制的话，它仅仅只调用ReflectChildNotify。OnChlidNofify可以被覆盖，所以如果程序员希望处理某个控制的通知消息，除了采用消息映射的方法处理通知反射消息以外，还可以覆盖OnChlidNotify虚拟函数，如果成功地处理了通知消息，则返回TRUE。

ReflectChildNotify是CWnd的成员函数，完成反射消息的派发。对于WM_COMMAND，它直接调用CWnd::OnCmdMsg派发反射消息WM_REFLECT_BASE+WM_COMMAND；对于WM_NOTIFY，它直接调用CWnd::OnCmdMsg派发反射消息WM_REFLECT_BASE+WM_NOFITY；对于其他消息，则直接调用CWnd::OnWndMsg（即CmdTarge::OnWndMsg）派发相应的反射消息，例如WM_REFLECT_BASE+WM_HSCROLL。

注意：ReflectChildNotify直接调用了CWnd的OnCmdMsg或OnWndMsg，这样反射消息被直接派发给控制子窗口，省却了消息发送的过程。

接着，控制子窗口如果处理了当前的反射消息，则返回反射消息被成员处理的信息。

（3）一个示例

如果要创建一个编辑框控制，要求它背景使用黄色，其他特性不变，则可以从CEdit派生一个类CYellowEdit，处理通知消息WM_CTLCOLOR的反射消息。CYellowEdit有三个属性，定义如下：

CYellowEdit::CYellowEdit()

{

m_clrText = RGB( 0, 0, 0 );

m_clrBkgnd = RGB( 255, 255, 0 );

m_brBkgnd.CreateSolidBrush( m_clrBkgnd );

}

使用ClassWizard添加反射消息处理函数：

函数原型：

afx_msg void HScroll();

消息映射宏：

ON_WM_CTLCOLOR_REFLECT()

函数的框架

HBRUSH CYellowEdit::CtlColor(CDC* pDC, UINT nCtlColor)

{

// TODO:添加代码改变设备描述表的属性

// TODO: 如果不再调用父窗口的处理，则返回一个非空的刷子句柄

return NULL;

}

添加一些处理到函数CtlColor中，如下：

pDC->SetTextColor( m_clrText );//设置文本颜色

pDC->SetBkColor( m_clrBkgnd );//设置背景颜色

return m_brBkgnd; //返回背景刷

这样，如果某个地方需要使用黄色背景的编辑框，则可以使用CYellowEdit控制。

对更新命令的接收和处理

用户接口对象如菜单、工具条有多种状态，例如：禁止，可用，选中，未选中，等等。这些状态随着运行条件的变化，由程序来进行更新。虽然程序员可以自己来完成更新，但是MFC框架为自动更新用户接口对象提供了一个方便的接口，使用它对程序员来说可能是一个好的选择。
1. 实现方法
  
  每一个用户接口对象，如菜单、工具条、控制窗口的子窗口，都由唯一的ID号标识，用户和它们交互时，产生相应ID号的命令消息。在MFC里，一个用户接口对象还可以响应CN_UPDATE_COMMAND_UI通知消息。因此，对每个标号ID的接口对象，可以有两个处理函数：一个消息处理函数用来处理该对象产生的命令消息ID，另一个状态更新函数用来处理给该对象的CN_UPDATE_COMMAND_UID的通知消息。
  
  使用ClassWizard可把状态更新函数加入到某个消息处理类，其结果是：
  
  在类的定义中声明一个状态函数；
  
  在消息映射中使用ON_UPDATE_COMMAND_UI宏添加一个映射条目；
  
  在类的实现文件中实现状态更新函数的定义。
  
  ON_UPDATE_COMMAND_UI给指定ID的用户对象指定状态更新函数，例如：
  
  ON_UPDATE_COMMAND_UI(ID_EDIT_COPY, OnUpdateEditCopy)
  
  映射标识号ID为ID_EDIT_COPY菜单的通知消息CN_UPDATE_COMMAND_UI到函数OnUpdateEditCopy。用于给EDIT（编辑菜单）的菜单项ID_EDIT_COPY（复制）添加一个状态处理函数OnUpdateEditCopy，通过处理通知消息CN_UPDATE_COMMAND_UI实现该菜单项的状态更新。
  
  状态处理函数的原型如下：
  
  afxmsg void ClassName::OnUpdateEditPaste(CCmdUI* pCmdUI)
  
  CCmdUI对象由MFC自动地构造。在完善函数的实现时，使用pCmdUI对象和CmdUI的成员函数实现菜单项ID_EDIT_COPY的状态更新，让它变灰或者变亮，也就是禁止或者允许用户使用该菜单项。
2. 状态更新命令消息
  
  要讨论MFC的状态更新处理，先得了解一条特殊的消息。MFC的消息映射机制除了处理各种Windows消息、控制通知消息、命令消息、反射消息外，还处理一种特别的“通知命令消息”，并通过它来更新菜单、工具栏（包括对话框工具栏）等命令目标的状态。
  
  这种“通知命令消息”是MFC内部定义的，消息ID是WM_COMMAND，通知代码是CN_UPDATE_COMMAND_UI（0XFFFFFFFF）。
  
  它不是一个真正意义上的通知消息，因为没有控制窗口产生这样的通知消息，而是MFC自己主动产生，用于送给工具条窗口或者主边框窗口，通知它们更新用户接口对象的状态。
  
  它和标准WM_COMMAND命令消息也不相同，因为它有特定的通知代码，而命令消息通知代码是0。
  
  但是，从消息的处理角度，可以把它看作是一条通知消息。如果是工具条窗口接收该消息，则在发送机制上它和WM_COMMAND控制通知消息是相同的，相当于让工具条窗口处理一条通知消息。如果是边框窗口接收该消息，则在消息的发送机制上它和WM_COMMAND命令消息是相同的，可以让任意命令目标处理该消息，也就是说边框窗口可以把该条通知消息发送给任意命令目标处理。
  
  从程序员的角度，可以把它看作一条“状态更新命令消息”，像处理命令消息那样处理该消息。每条命令消息都可以对应有一条“状态更新命令消息”。ClassWizard也支持让任意消息目标处理“状态更新命令消息”（包括非窗口命令目标），实现用户接口状态的更新。
  
  在这条消息发送时，通过OnCmdMsg的第三个参数pExtra传递一些信息，表示要更新的用户接口对象。pExtra指向一个CCmdUI对象。这些信息将传递给状态更新命令消息的处理函数。
  
  下面讨论用于更新用户接口对象状态的类CCmdUI。
3. 类CCmdUI

CCmdUI不是从CObject派生，没有基类。

成员变量

m_nID 用户接口对象的ID

m_nIndex 用户接口对象的index

m_pMenu 指向CCmdUI对象表示的菜单

m_pSubMenu 指向CCmdUI对象表示的子菜单

m_pOther 指向其他发送通知消息的窗口对象

m_pParentMenu 指向CCmdUI对象表示的子菜单
成员函数

Enable(BOOL bOn = TRUE ) 禁止用户接口对象或者使之可用

SetCheck( int nCheck = 1) 标记用户接口对象选中或未选中

SetRadio(BOOL bOn = TRUE)

SetText(LPCTSTR lpszText)

ContinueRouting()

还有一个MFC内部使用的成员函数：

DoUpdate(CCmdTarget* pTarget, BOOL bDisableIfNoHndler)

其中，参数1指向处理接收更新通知的命令目标，一般是边框窗口；参数2指示如果没有提供处理函数（例如某个菜单没有对应的命令处理函数），是否禁止用户对象。

DoUpdate作以下事情：

首先，发送状态更新命令消息给参数1表示的命令目标：调用pTarget->OnCmdMsg（m_nID, CN_UPDATE_COMMAND_UI, this, NULL)发送m_nID对象的通知消息CN_UPDATE_COMMAND_UI。OnCmdMsg的参数3取值this，包含了当前要更新的用户接口对象的信息。

然后，如果参数2为TRUE，调用pTarget->OnCmdMsg(m_nID, CN_COMMAND, this, &info)测试命令消息m_nID是否被处理。这时，OnCmdMsg的第四个参数非空，表示仅仅是测试，不是真的要派发消息。如果没有提供命令消息m_nID的处理函数，则禁止用户对象m_nID，否则使之可用。

从上面的讨论可以知道：通过其结构，一个CCmdUI对象标识它表示了哪一个用户接口对象，如果是菜单接口对象，pMenu表示了要更新的菜单对象；如果是工具条，pOther表示了要更新的工具条窗口对象，nID表示了工具条按钮ID。

所以，由参数上状态更新消息的消息处理函数就知道要更新什么接口对象的状态。例如，第1节的函数OnUpdateEditPaste，函数参数pCmdUI表示一个菜单对象，需要更新该菜单对象的状态。

通过其成员函数，一个CCmdUI可以更新、改变用户接口对象的状态。例如，CCmdUI可以管理菜单和对话框控制的状态，调用Enable禁止或者允许菜单或者控制子窗口，等等。

所以，函数OnUpdateEditPaste可以直接调用参数的成员函数（如pCmdUI->Enable）实现菜单对象的状态更新。

由于接口对象的多样性，其他接口对象将从CCmdUI派生出管理自己的类来，覆盖基类的有关成员函数如Enable等，提供对自身状态更新的功能。例如管理状态条和工具栏更新的CStatusCmdUI类和CToolCmdUI类。

自动更新用户接口对象状态的机制

MFC提供了分别用于更新菜单和工具条的两种途径。

更新菜单状态

当用户对菜单如File单击鼠标时，就产生一条WM_INITMENUPOPUP消息，边框窗口在菜单下拉之前响应该消息，从而更新该菜单所有项的状态。

在应用程序开始运行时，边框也会收到WM_INITMENUPOPUP消息。
更新工具条等状态

当应用程序进入空闲处理状态时，将发送WM_IDLEUPDATECMDUI消息，导致所有的工具条用户对象的状态处理函数被调用，从而改变其状态。WM_IDLEUPDATECMDUI是MFC自己定义和使用的消息。

在窗口初始化时，工具条也会收到WM_IDLEUPDATECMDUI消息。
菜单状态更新的实现

MFC让边框窗口来响应WM_INITMENUPOPUP消息，消息处理函数是OnInitMenuPopup，其原型如下：

afx_msg void CFrameWnd::OnInitMenuPopup( CMenu* pPopupMenu,

UINT nIndex, BOOL bSysMenu );

第一个参数指向一个CMenu对象，是当前按击的菜单；第二个参数是菜单索引；第三个参数表示子菜单是否是系统控制菜单。

函数的处理：

如果是系统控制菜单，不作处理；否则，创建CCmdUI对象state，给它的各个成员如m_pMenu，m_pParentMenu，m_pOther等赋值。

对该菜单的各个菜单项，调函数state.DoUpdate，用CCmdUI的DoUpdate来更新状态。DoUpdate的第一个参数是this，表示命令目标是边框窗口；在CFrameWnd的成员变量m_bAutoMenuEnable为TRUE时（表示如果菜单m_nID没有对应的消息处理函数或状态更新函数，则禁止它），把DoUpdate的第二个参数bDisableIfNoHndler置为TRUE。

顺便指出，m_bAutoMenuEnable缺省时为TRUE，所以，应用程序启动时菜单经过初始化处理，没有提供消息处理函数或状态更新函数的菜单项被禁止。
工具条等状态更新的实现

图4-5表示了消息空闲时MFC更新用户对象状态的流程：

MFC提供的缺省空闲处理向顶层窗口(框架窗口)的所有子窗口发送消息WM_IDLEUPDATECMDUI；MFC的控制窗口（工具条、状态栏等）实现了对该消息的处理，导致用户对象状态处理函数的调用。

虽然两种途径调用了同一状态处理函数，但是传递的 CCmdUI参数从内部构成上是不一样的：第一种传递的CCmdUI对象表示了一菜单对象，(pMenu域被赋值)；第二种传递了一个窗口对象(pOther域被赋值)。同样的状态改变动作，如禁止、允许状态的改变，前者调用了CMenu的成员函数EnableMenuItem，后者使用了CWnd的成员函数EnabelWindow。但是，这些不同由CCmdUI对象内部区分、处理，对用户是透明的：不论菜单还是对应的工具条，用户都用同一个状态处理函数使用同样的形式来处理。

这一节分析了用户界面更新的原理和机制。在后面第13章讨论工具条和状态栏时，将详细的分析这种机制的具体实现。

消息的预处理

到现在为止，详细的讨论了MFC的消息映射机制。但是，为了提高效率和简化处理，MFC提供了一种消息预处理机制，如果一条消息在预处理时被过滤掉了（被处理），则不会被派发给目的窗口的窗口过程，更不会进入消息循环了。

显然，能够进行预处理的消息只可能是队列消息，而且必须在消息派发之前进行预处理。因此，MFC在实现消息循环时，对于得到的每一条消息，首先送给目的窗口、其父窗口、其祖父窗口乃至最顶层父窗口，依次进行预处理，如果没有被处理，则进行消息转换和消息派发，如果某个窗口实现了预处理，则终止。有关实现见后面关于CWinThread线程类的章节，CWinThread的Run函数和PreTranslateMessage函数以及CWnd的函数WalkPreTranslateTree实现了上述要求和功能。这里要讨论的是MFC窗口类如何进行消息预处理。

CWnd提供了虚拟函数PreTranslateMessage来进行消息预处理。CWnd的派生类可以覆盖该函数，实现自己的预处理。下面，讨论几个典型的预处理。

首先，是CWnd的预处理：

预处理函数的原型为：

BOOL CWnd::PreTranslateMessage(MSG* pMsg)

CWnd类主要是处理和过滤Tooltips消息。关于该函数的实现和Tooltips消息，见后面第13章关于工具栏的讨论。

然后，是CFrameWnd的预处理：

CFrameWnd除了调用基类CWnd的实现过滤Tooltips消息之外，还要判断当前消息是否是键盘快捷键被按下，如果是，则调用函数::TranslateAccelerator(m_hWnd, hAccel, pMsg)处理快捷键。

接着，是CMDIChildWnd的预处理：

CMDIChildWnd的预处理过程和CFrameWnd的一样，但是不能依靠基类CFrameWnd的实现，必须覆盖它。因为MDI子窗口没有菜单，所以它必须在MDI边框窗口的上下文中来处理快捷键，它调用了函数::TranslateAccelerator(GetMDIFrame()->m_hWnd, hAccel, pMsg)。

讨论了MDI子窗口的预处理后，还要讨论MDI边框窗口：

CMDIFrameWnd的实现除了CFrameWnd的实现的功能外，它还要处理MDI快捷键（标准MDI界面统一使用的系统快捷键）。

在后面，还会讨论CDialog、CFormView、CToolBar等的消息预处理及其实现。

至于CWnd::WalkPreTranslateTree函数，它从接受消息的窗口开始，逐级向父窗回溯，逐一对各层窗口调用PreTranslateMessage函数，直到消息被处理或者到最顶层窗口为止。
MFC消息映射的回顾

从处理命令消息的过程可以看出，Windows消息和控制消息的处理要比命令消息的处理简单，因为查找消息处理函数时，后者只要搜索当前窗口对象(this所指)的类或其基类的消息映射入口表。但是，命令消息就要复杂多了，它沿一定的顺序链查找链上的各个命令目标，每一个被查找的命令目标都要搜索它的类或基类的消息映射入口表。

MFC通过消息映射的手段，以一种类似C++虚拟函数的概念向程序员提供了一种处理消息的方式。但是，若使用C++虚拟函数实现众多的消息，将导致虚拟函数表极其庞大；而使用消息映射，则仅仅感兴趣的消息才加入映射表，这样就要节省资源、提高效率。这套消息映射机制的基础包括以下几个方面：

消息映射入口表的实现：采用了C++静态成员和虚拟函数的方法来表示和得到一个消息映射类(CCmdTarget或派生类)的映射表。
消息查找的实现：从低层到高层搜索消息映射入口表，直至根类CCmdTarget。
消息发送的实现：主要以几个虚拟函数为基础来实现标准MFC消息发送路径：OnComamnd、OnNotify、OnWndMsg和OnCmdMsg。、

OnWndMsg是CWnd类或其派生类的成员函数，由窗口过程调用。它处理标准的Windows消息。

OnCommand是CWnd类或其派生类的成员函数，由OnWndMsg调用来处理WM_COMMAND消息，实现命令消息或者控制通知消息的发送。如果派生类覆盖该函数，则必须调用基类的实现，否则将不能自动的处理命令消息映射，而且必须使用该函数接受的参数（不是程序员给定值）调用基类的OnCommand。

OnNotify是CWnd类或其派生类的成员函数，由OnWndMsg调用来处理WM_NOTIFY消息，实现控制通知消息的发送。

OnCmdMsg是CCmdTarget类或其派生类的成员函数。被OnCommand调用，用来实现命令消息发送和派发命令消息到命令消息处理函数。

自动更新用户对象状态是通过MFC的命令消息发送机制实现的。

控制消息可以反射给控制窗口处理。

队列消息在发送给窗口过程之前可以进行消息预处理，如果消息被MFC窗口对象预处理了，则不会进入消息发送过程。

MFC对象的创建

前面几章介绍了MFC的核心概念和思想，即介绍了MFC对Windows对象的封装方法和特点；MFC对象的动态创建、序列化；MFC消息映射机制。

现在，考查MFC的应用程序结构体系，即以文档-视为核心的编程模式。学习本章，应该弄清楚以下问题：

MFC中诸多MFC对象的关系：应用程序对象，文档对象，边框窗口对象，文档边框窗口对象，视对象，文档模板对象等。

MFC对象的创建和销毁：由什么对象创建或销毁什么对象，何时创建，何时销毁？

MFC提供了那些接口来支持其编程模式？

MFC对象的关系

创建关系

这里讨论应用程序、文档模板、边框窗口、视、文档等的创建关系。图5-1大略地表示了创建顺序，但表5-1更直接地显示了创建与被创建的关系。

　

表5-1 MFC对象的创建关系

创建者

被创建的对象

应用程序对象

文档模板

文档模板

文档

文档模板

边框窗口

边框窗口

视

　
交互作用关系

应用程序对象有一个文档模板列表，存放一个或多个文档模板对象；文档模板对象有一个打开文档列表，存放一个或多个已经打开的文档对象；文档对象有一个视列表，存放显示该文档数据的一个或多个视对象；还有一个指针指向创建该文档的文档模板对象；视有一个指向其关联文档的指针，视是一个子窗口，其父窗口是边框窗口（或者文档边框窗口）；文档边框窗口有一个指向其当前活动视的指针；文档边框窗口是边框窗口的子窗口。

Windows 管理所有已经打开的窗口，把消息或事件发送给目标窗口。通常，命令消息发送给主边框窗口。

图5-2大略地表示了上述关系：

MFC提供了一些函数来维护这些关系。

表5-2列出了从一个对象得到相关对象的方法。

表5-2 从一个对象得到另一个对象的方法

本对象	要得到的对象	使用的成员函数
CDocument对象	视列表	GetFirstViewPosition GetNextView
CDocument对象	文档模板	GetDocTemplate
CView对象	文档对象	GetDocument
CView对象	边框窗口	GetParentFrame
CMDIChildWnd或 CFrameWnd对象	活动视	GetActiveView
CMDIChildWnd或 CFrameWnd对象	活动视的文档	GetActiveDocument
CMDIFrameWnd对象	活动文档边框窗口	MDIGetActive

表5-3 从一个对象通知另一个对象的方法：

本对象	要通知的对象/动作	使用的成员函数
CView对象	通知文档更新所有视	CDocument::UpdateAllViews
CDocument对象	更新一个视	CView::OnUpdate
CFrameWnd或 CMDIFrameWnd对象	通知一个视为活动视	CView::OnActivateView
CFrameWnd或 CMDIFrameWnd对象	设置一个视为活动视	SetActivateView

可以通过表5-2得到相关对象，再调用表5-3中相应的函数。例如：视在接受了新数据或者数据被修改之后，使用表5-2中的函数GetDocument得到关联文档对象，然后调用表5-3中的文档函数UpdateAllViews更新其他和文档对象关联的视。

在表5-2和表5-3中，CView对象指CView或派生类的实例；成员函数列中如果没有指定类属，就是第一列对象的类的成员函数。

MFC提供的接口

MFC编程就是把一些应用程序特有的东西填入MFC框架。MFC提供了两种填入的方法：一种就是使用前一章论述的消息映射，消息映射给应用程序的各种对象处理各种消息的机会；另一种就是使用虚拟函数，MFC在实现许多功能或者处理消息、事件的过程中，调用了虚拟函数来完成一些任务，这样就给了派生类覆盖这些虚拟函数实现特定处理的机会。

下面两节将列出两类接口，有两个目的：一是为了让读者获得整体印象，二是后文将涉及到或者讨论其中的许多函数时，不显得突兀。

虚拟函数接口

几乎每一个MFC类都定义和使用了虚拟成员函数，程序员可以在派生类中覆盖它们。一般，MFC提供了这些函数的缺省实现，所以覆盖函数应该调用基类的实现。这里给出一个MFC常用虚拟函数的总览表(见表5-4)，更详细的信息或它们的缺省实现动作参见MFC文档。由于基类的虚拟函数被派生类继承，所以在派生类中不作重复说明。

覆盖基类的虚拟函数可以通过ClassWizard进行，不过，并非所有的函数都可以这样，有的必须手工加入函数声明和实现。

表5-4 常见MFC类的虚拟函数接口

类	虚拟函数	覆盖的目的和功能
CCmdTarget	OnCmdMsg	发送、派发命令消息
CCmdTarget	OnFinalRelease	OLE用途，引用为0时作清理工作
CWinThread	ExitInstance	在线程退出时作清理工作
	InitInstance	在线程开始时作初始化
	OnIdle	执行thread-specific idle-time处理
	PreTranslateMessage	在消息送给Windows函数TranslateMessage and DispatchMessage.之前进行消息过滤
	IsIdleMessage	检查是否是某个特别的消息
	ProcessWndProcException	截获线程消息/命令处理中的例外
	ProcessMessageFilter	线程消息过滤
	Run	实现线程特定的消息循环
CWinApp	HideApplication	关闭所有的窗口之前隐藏应用程序
CWinApp	CloseAllDocument	退出程序之前关闭所有文档
转下页

续表
	SaveModifiedDocument	框架窗口关闭时用来保存文档
	DoMessageBox	实现客户化的messagebox
	DoWaitCursor	关闭或打开等待光标
	OnDDeCommand	响应DDE命令
	WinHelp	调用WinHelp函数
CWnd	WindowProc	提供一个窗口过程
	DefWindowProc	为应用程序不处理的消息提供缺省处理
	PostNcDestroy	在窗口销毁之后被消息处理函数OnNcDestroy调用
	OnNotify	处理通知消息WM_NOTIFY
	OnChildNotify	父窗口调用它给控制子窗口一个机会来处理通知反射消息
	DoDataExchange	Updata调用它来进行对话框数据交换和验证
CFrameWnd	GetMessageBar	返回一个指向框架窗口的状态条的指针
	OnCreateClient	创建框架的客户窗口
	OnSetPreviewMode	设置程序的主框架窗口进入或退出打印预览模式
	NegotiateBorderSpace	协调边框窗口的边框空间的大小(OLE用途)
CMDIFrameWnd	CreateClient	创建CMDIFrameWnd的MDICLIENT窗，被CWnd的消息处理函数OnCreate调用.
转下页

续表
	GetWindowMenuPopup	返回窗口的弹出式菜单
CDialog	OnInitDialog	对话框窗口的初始化
	OnSetFont	设置对话框控制的文本字体
	OnOK	模式对话框的OK按钮按下后进行的处理
	OnCancel	模式对话框的CANCEL按钮按下后进行的处理
CView	IsSelected	测试是否有一个文档被选择(OLE支持)
	OnActivateView	视窗口激活时调用
	OnActivateFrame	当包含视窗口的框架窗口变成活动或非活动窗口时调用
	OnBeginPrinting	打印工作开始时调用，用来分配GDI资源
	OnDraw	用来屏幕显示、打印、打印预览文档内容
	OnEndPrinting	打印工作结束时调用，释放GDI资源
	OnEndPrintPreview	退出打印预览模式时调用
	OnPrepareDC	OnDraw或OnPrint之前调用，用来准备设备描述表
	OnPreparePrinting	文档打印或者打印预览前调用，可用来初始化打印对话框
	OnPrint	用来打印或打印预览文档
	OnUpdate	用来通知一个视的关联文档内容已经变化
CDocTemplate	MatchDocType	确定文档类型和文档模板匹配时的可信程度
转下页

续表
	CreateNewDocument	创建一个新的文档
	CreateNewFrame	创建一个包含文档和视的框架窗口
	InitialUpdateFrame	初始化框架窗口，必要时使它可见
	SaveAllModified	保存所有和模板相关的而且修改了的文档
	CloseAllDocuments	关闭所有和模板相关的文档
	OpenDocumentFile	打开指定路径的文件
	SetDefaultTitle	设置文档窗口缺省显示的标题
CDocument	CanCloseFrame	在关闭显示该文档的边框窗口之前调用
	DeleteContents	用来清除文档的内容
	OnChangedViewList	在与文档关联的视图被移走或新加入时调用
	OnCloseDocument	用来关闭文档
	OnNewDocument	用来创建新文档
	OnOpenDocument	用来打开文档
	OnSaveDocument	以来保存文档
	ReportSaveLoadException	处理打开、保存文档操作失败时的例外
	GetFile	返回一个指向Cfile对象的指针
	ReleaseFile	释放一个文件以便其他应用程序可以使用
	SaveModified	用来询问用户文档是否需要保存
	PreCloseFrame	在框架窗口关闭之前调用

消息映射方法和标准命令消息

窗口对象可以响应以“WM_”为前缀的标准Windows消息，消息处理函数名称以“ON”为前缀。不同类型的Windows窗口处理的Windows消息是有所不同的，因此，不同类型的MFC窗口实现的消息处理函数也有所不同。例如，多文档边框窗口能处理WM_MDIACTIVATE消息，其他类型窗口就不能。程序员从一定的MFC窗口派生自己的窗口类，对感兴趣的消息，覆盖基类的消息处理函数，实现自己的消息处理函数。

所有的命令目标（CCmdTarger或导出类对象）可以响应命令消息，程序员可以指定应用程序对象、框架窗口对象、视对象或文档对象等来处理某条命令消息。一般地，尽量由与命令消息关系密切的对象来处理，例如隐藏/显示工具栏由框架窗口处理，打开文件由应用程序对象处理，数据变化的操作由文档对象处理。

对话框的控制子窗口可以响应各类通知消息。

对于命令消息，MFC实现了一系列标准命令消息处理函数。标准命令ID在afxres.h中定义。表5-5列出了MFC标准命令的实现，从ID或者函数名可以大致地看出该函数的目的、功用，具体的实现有的后续章节会讲解，详细参见MFC技术文档。

程序员可以自己来处理这些标准消息，也可以通过不同的类或从不同的类导出自己的类来处理这些消息，不过最好遵循MFC的缺省实现。比如处理ID_FILE_NEW命令，最好由CWinApp的派生类处理。

表5-5 标准命令消息处理函数

ID	函数	实现函数的类
ID_FILE_NEW	OnFileNew	CWinApp
ID_FILE_OPEN	OnFileOpen	CWinApp
ID_FILE_CLOSE	OnFileClose	CDocument
ID_FILE_SAVE	OnFileSave	CDocument
ID_FILE_SAVE_AS	OnFileSaveAs	CDocument
ID_FILE_SAVE_COPY_AS	OnFileSaveCopyAs	COleServerDoc
ID_FILE_UPDATE	OnUpdateDocument	COleServerDoc
ID_FILE_PAGE_SETUP	OnFilePrintSetup	CWinApp
转下页

续表
ID_FILE_PRINT	OnFilePrint	CView
ID_FILE_PRINT_PREVIEW	OnFilePrintPreview	CView
ID_FILE_MRU_FILE1…FILE16	OnUpdateRecentFileMenu	CWinApp
ID_EDIT_CLEAR		CView没有实现，
ID_EDIT_CLEAR_ALL		但是，如果有实现
ID_EDIT_COPY		函数，就是派生类
ID_EDIT_CUT		CEditView的
ID_EDIT_FIND		实现函数
ID_EDIT_PASTE_LINK
ID_EDIT_PASTE_SPECIAL
ID_EDIT_REPEAT
ID_EDIT_REPLACE
ID_EDIT_SELET_ALL
ID_EDIT_UNDO
ID_WINDOW_NEW	OnWindowNew	CMDIFrameWnd
ID_WINDOW_ARRANGE	OnMDIWindowCmd	CMDIFrameWnd
ID_WINDOW_CASCADE
ID_WINDOW_TILE_HORZ
ID_WINDOW_TILE_VERT
ID_WINDOW_SPLIT		CSplitterWnd
ID_APP_ABOUT
ID_APP_EXIT	OnAppExit	CWinApp
ID_HELP_INDEX	OnHelpIndex	CWinApp
ID_HELP_USING	OnHelpUsing	CWinApp
ID_CONTEXT_HELP	OnContextHelp	CWinApp
转下页

续表
ID_HELP	OnHelp	CWinApp
ID_DEFAULT_HELP	OnHelpIndex	CWinApp
ID_NEXT_PANE	OnNextPaneCmd	CSplitterWnd
ID_PREV_PANE	OnNextPaneCmd	CSplitterWnd
ID_OLE_INSERT_NEW
ID_OLE_EDIT_LINKS
ID_OLE_VERB_FIRST…LAST
ID_VIEW_TOOLBAR		CFrameWnd
ID_VIEW_STATUS_BAR		CFrameWnd
ID_INDICATOR_CAPS ID_INDICATOR_NUM ID_INDICATOR_SCRL ID_INDICATOR_KANA	OnUpdateKeyIndicator	CFrameWnd

MFC对象的创建过程

应用程序使用MFC的接口是把一些自己的特殊处理填入MFC框架，这些处理或者在应用程序启动和初始化的时候被调用，或者在程序启动之后和用户交互的过程中被调用，或者在程序退出和作清理工作的时候被调用。这三个阶段中，和用户交互阶段是各个程序自己的事情，自然都不一样，但是程序的启动和退出两个阶段是MFC框架所实现的，是MFC框架的一部分，各个程序都遵循同样的步骤和规则。显然，清楚MFC框架对这两个阶段的处理是很有必要的，它可以帮助深入理解MFC框架，更好地使用MFC框架，更有效地实现应用程序特定的处理。

MFC程序启动和初始化过程就是创建MFC对象和Windows对象、建立各种对象之间的关系、把窗口显示在屏幕上的过程，退出过程就是关闭窗口、销毁所创建的Windows对象和MFC对象的过程。所以，下面要讨论几种常用MFC对象的结构，它们是构成一个文档-视模式应用程序的重要部件。

应用程序中典型对象的结构

本节将主要分析应用程序对象、文档对象、文档模板等的数据结构。通过考察类的结构，特别是成员变量结构，弄清它的功能、目的以及和其他类的关系；另外，在后续有关分析中必定会提到这些成员变量，这里先作个说明，到时也不会显得突兀。

下面几节以表格的形式来描述各个类的成员变量。表格中，第一列打钩的表示是MFC类库文档有说明的；没打钩的在文档中没有说明，如果是public，则可以直接访问，但随着MFC版本的变化，以后MFC可能不支持这些成员；第二列是访问属性；第三列是成员变量名称；第四列是成员变量的数据类型；第五列是对成员变量的功能、用途的简要描述。

应用程序类的成员变量

应用程序对象的数据成员表由两部分组成，第一部分是CWinThread的成员变量，如表5-6所示，CWinApp继承了CWinThread的数据成员。第二部分是CWinApp自己定义的成员变量，如表5-7所示。

表5-6 CwinThread的成员变量

	访问限制	变量名称	类型	解释
√	public	m_bAutoDelete	BOOL	指定线程结束时是否销毁线程对象本身
√	public	m_hThread	HANDLE	当前线程的句柄
√	public	m_nThreadID	UINT	当前线程的ID
√	public	m_pMainWnd	CWnd*	指向应用程序主窗口的指针
√	public	m_pActiveWnd	CWnd*	当OLE SERVER就地激活时指向客户程序主窗口的指针
	public	m_msgCur	MSG	当前消息(MSG结构)
	public	m_pThreadParams	LPVOID	传递给线程开始函数的参数
	public	m_pfnThreadProc	函数指针1	线程开始函数，AFX_THREADPROC类型
	public	m_lpfnOleTermOrFreeLib	函数指针2	OLE用途，void (AFXAPI * fn)(BOOL,BOOL)
	public	m_pMessageFilter	指针	OLE消息过滤，指向COleMessageFilter对象
	protected	m_ptCursorLast	CPoint	最新鼠标位置
	protected	m_nMsgLast	UINT	消息队列中最新接收到的消息

表5-7 CWinApp的成员变量

	访问限制	变量名称	类型	解释
√	public	m_pszAppName	LPCTSTR	应用程序名称
√	public	m_hInstance	HINSTANCE	标志应用程序当前实例句柄
√	public	m_hPrevInstance	HINSTANCE	32位程序设为空
√	public	m_lpCmdLine	LPTSTR	指向应用程序的命令行字符串
√	public	m_nCmdShow	int	指定窗口开始的显示方式
√	public	m_bHelpMode	BOOL	标识用户是否在上下文帮助模式
√	public	m_pszExeName	LPCTSTR	应用程序的模块名
√	public	m_pszHelpFilePath	LPCTSTR	应用程序的帮助文件名，缺省时同模块名
√	public	m_pszProfileName	LPCTSTR	应用程序的INI文件名，缺省时同应用程序名
√	public	m_pszRegistryKey	LPCTSTR	Register入口，如果不指定，使用INI文件。
	public	m_pDocManager;	CDocManager *	指向一个文档模板管理器
	protected	m_hDevMode	HGLOBAL	打印设备模式
	protected	m_hDevNames	HGLOBAL	打印设备名称
	protected	m_dwPromptContext	DWORD	被MESSAGE BOX覆盖的帮助上下文
	protected	m_nWaitCursorCount	int	等待光标计数
	protected	m_hcurWaitCursorRestore	HCURSOR	保存的光标，在等待光标之后恢复
	protected	m_pRecentFileList	指针	指向CRecentFileList对象，最近打开的文件列表
	public	m_atomApp	ATOM	DDE用途
	public	m_atomSystemTopic	m_atomApp	DDE用途
	public	m_nNumPreviewPages	UINT	缺省被打印的页面
	public	m_nSafetyPoolSize	size_t	理想尺寸
	public	m_lpfnDaoTerm	函数指针	DAO初始化设置时使用

CDocument的成员变量

表5-8 文档对象的属性。

访问限制	变量名称	类型	解释
protected	m_strTitle	CString	文档标题
protected	m_strPathName	CString	文档路径
protected	m_pDocTemplate	CDocTemplate*	指向文档模板的指针
protected	m_viewList	CPtrList	关联的视窗口列表
protected	m_bModified	BOOL	文档是否有变化、需要存盘
public	m_bAutoDelete	BOOL	关联视都关闭时是否删除文档对象
public	m_bEmbedded	BOOL	文档是否由OLE创建

文档模板的属性

表5-9列出了文档模板的成员变量，5-10列出了单文档模板的成员变量，5-11列出了多文档模板的成员变量。单、多文档模板继承了文档模板的成员变量。

表5-9 文档模板的数据成员

访问限制	变量名称	类型	解释
public	m_bAutoDelete	BOOL
public	m_pAttachedFactory	CObject *
public	m_hMenuInPlace	HMENU	就地激活时，OLE客户程序的菜单
public	m_hAccelInPlace	HACCEL	就地激活时，OLE客户程序的快捷键
public	m_hMenuEmbedding	HMENU
public	m_hAccelEmbedding	HACCEL
public	m_hMenuInPlaceServer	HMENU
public	m_hAccelInPlaceServer	HACCEL
protected	m_nIDResource	UINT	框架、菜单、快捷键等的资源ID
protected	m_nIDServerResource	UINT
public	m_nIDEmbeddingResource	UINT
public	m_nIDContainerResource	UINT
public	m_pDocClass	CRuntimeClass*	指向文档类的动态创建信息
public	m_pFrameClass	CRuntimeClass*	指向框架类的动态创建信息
public	m_pViewClass	CRuntimeClass*	指向视类的动态创建信息，由字符串m_nIDResource描述
public	m_pOleFrameClass	CRuntimeClass*	指向OLD框架类的动态创建信息
public	m_pOleViewClass	CRuntimeClass*
public	m_strDocStrings	CString	描述该文档类型的字符串

表5-10 单文档模板的成员变量

	访问限制	变量名称	类型	解释
	protected	m_pOnlyDoc	CDocment*	指向唯一的文档对象

表5-11 单文档模板的成员变量

访问限制	变量名称	类型	解释
public	m_hMenuShared	HMENU	该模板的MDI子窗口的菜单
public	m_hAccelTable	HACCEL	该模板的MDI子窗口的快捷键
protected	m_docList	CPtrList	该模板的文档列表
protected	m_nUntitledCount	UINT	用来生成文件名的数字，如”untitled0”的0。

WinMain入口函数
1. WinMain流程
  
  现在讨论MFC应用程序如何启动。
  
  WinMain函数是MFC提供的应用程序入口。进入WinMain前，全局应用程序对象已经生成。WinMain流程如图5-3所示。图中，灰色框是对被调用的虚拟函数的注释，程序员可以或必须覆盖它以实现MFC要求的或用户希望的功能；大括号所包含的图示是相应函数流程的细化，有应用程序对象App的初始化、Run函数的实现、PumpMessage的流程，等等。
  
  从图中可以看出：
  
  （1）一些虚拟函数被调用的时机
  
  对应用程序类（线程类）的InitIntance、ExitInstance、Run、ProcessMessageFilter、OnIdle、PreTranslateMessage来说，InitInstance在应用程序初始化时调用，ExitInstance在程序退出时调用，Run在程序初始化之后调用导致程序进入消息循环，ProcessMessageFilter、OnIdle、PreTranslateMessage在消息循环时被调用，分别用来过滤消息、进行Idle处理、让窗口预处理消息。
  
  （2）应用程序对象的角色
  
  首先，应用程序对象的成员函数InitInstance被WinMain调用。对程序员来说，它就是程序的入口点（真正的入口点是WinMain，但MFC向程序员隐藏了WinMain的存在）。由于MFC没有提供InitInstance的缺省实现，用户必须自己实现它。稍后将讨论该函数的实现。
  
  其次，通过应用程序对象的Run函数，程序进入消息循环。实际上，消息循环的实现是通过CWinThread::Run来实现的，图中所示的是CWinThread::Run的实现，因为CWinApp没有覆盖Run的实现，程序员的应用程序类一般也不用覆盖该函数。
  
  （3）Run所实现的消息循环
  
  它调用PumpMessage来实现消息循环，如果没消息，则进行空闲(Idle)处理。如果是WM_QUIT消息，则调用ExitInstance后退出消息循环。
  
  （4）CWinThread::PumpMessage
  
  该函数在MFC函数文档里没有描述，但是MFC建议用户使用。它实现获取消息，转换(Translate)消息，发送消息的消息循环。在转换消息之前，调用虚拟函数PreTranslateMessage对消息进行预处理，该函数得到消息目的窗口对象之后，使用CWnd的WalkPreTranslateTree让目的窗口及其所有父窗口得到一个预处理当前消息的机会。关于消息预处理，见消息映射的有关章节。如果是WM_QUIT消息，PumpMessage返回FALSE；否则返回TRUE。
2. MFC空闲处理

MFC实现了一个Idle处理机制，就是在没有消息可以处理时，进行Idle处理。Idle处理的一个应用是更新用户接口对象的状态。更新用户接口状态的内容见消息映射的章节。

空闲处理由函数OnIdle完成，其原型为BOOL OnIdle（int）。参数的含义是当前空闲处理周期已经完成了多少次OnIdle调用，每个空闲处理周期的第一次调用，该参数设为0，每调用一次加1；返回值表示当前空闲处理周期是否继续调用OnIdle。
MFC的缺省实现里，CWinThread::OnIdle完成了工具栏等的状态更新。如果覆盖OnIdle，需要调用基类的实现。
在处理完一个消息或进入消息循环时，如果消息队列中没有消息要处理，则MFC开始一个新的空闲处理周期；
当OnIdle返回FASLE，或者消息队列中有消息要处理时，当前的空闲处理周期结束。

从图5-3中Run的流程上可以清楚的看到MFC空闲处理的情况。

本节描述了应用程序从InitInstance开始初始化、从Run进入消息循环的过程，下面将就SDI应用程序的例子描述该过程中创建各个所需MFC对象的流程。

SDI应用程序的对象创建

如前一节所述，程序从InitInstance开始。在SDI应用程序的InitInstance里，至少有以下语句：

//第一部分，创建文档模板对象并把它添加到应用程序的模板链表

CSingleDocTemplate* pDocTemplate;

pDocTemplate = new CSingleDocTemplate(

IDR_MAINFRAME,

RUNTIME_CLASS(CTDoc),

RUNTIME_CLASS(CMainFrame), // main SDI frame window

RUNTIME_CLASS(CTView));

AddDocTemplate(pDocTemplate);

//第二部分，动态创建文档、视、边框窗口等MFC对象和对应的Windows对象

//Parse command line for standard shell commands, DDE, file open

CCommandLineInfo cmdInfo;

ParseCommandLine(cmdInfo);

// Dispatch commands specified on the command line

if (!ProcessShellCommand(cmdInfo))

return FALSE;

//第三部分，返回TRUE，WinMain下一步调用Run开始消息循环，

//否则，终止程序

return TRUE;

对于第二部分，又可以分解成许多步骤。

下面将解释每一步。
1. 文档模板的创建
  
  第一步是创建文档模板。
  
  文档模板的作用是动态创建其他MFC对象，它保存了要动态创建类的动态创建信息和该文档类型的资源ID。这些信息保存在文档模板的成员变量里：m_nIDResource(资源ID)、m_pDocClass(文档类动态创建信息)、m_pFrameClass(边框窗口类动态创建信息)、m_pViewClass(视类动态创建信息)。
  
  资源ID包括菜单、像标、快捷键、字符串资源的ID，它们都使用同一个ID值，如IDR_MAINFRAME。其中，字符串资源描述了文档类型，由七个被“\n”分隔的子字符串组成，各个子串可以通过CDocTemplate的成员函数GetDocString(CString& rString, enum DocStringIndex index)来获取。DocStringIndex是CDocTemplate类定义的枚举变量以区分七个子串，描述如下（英文是枚举变量名称）。
  
  WindowTitle 应用程序窗口的标题。仅仅对SDI程序指定。
  
  DocName 用来构造缺省文档名的字符串。当用File菜单的菜单项new创建新文档时，缺省文档名由该字符串加一个数字构成。如果空，使用“unitled”。
  
  FileNewName 文档类型的名称，在打开File New对话框时显示。
  
  FilterName 匹配过滤字符串，在File Open对话框用来过滤要显示的文件。如果不指定，File Open对话框的文件类型(file style)不可访问。
  
  FilterExt 该类型文档的扩展名。如果不指定，则不可访问对话框的文件类型(File Style)。
  
  RegFileTypeId 文档类型在Windows 注册库中的存储标识。
  
  RegFileTypeName 文档类型在Windows 注册库中的类型名称。
  
  文档模板被应用程序对象创建和管理。应用程序类CWinApp有一个CDocManager类型的成员变量m_pDocManager，通过该变量来管理应用程序的文档模板列表，把一些相关的操作委派给CDocManager对象处理。
  
  CDocManager使用CPtrList类型的m_templateList变量来存储文档模板，并提供了操作文档模板列表的系列函数。
  
  从语句pDocTemplate = new CSingleDocTemplate(…)可以看出应用程序对象创建模板时传递一个资源ID和三个类的动态创建信息给它：
  
  IDR_MAINFRAME，资源ID
  
  RUNTIME_CLASS(CTDoc)，文档类动态创建信息
  
  RUNTIME_CLASS(CMainFrame),边框窗口类动态创建信息
  
  RUNTIME_CLASS(CTView)，视类动态创建信息
  
  文档模板对象接收这些信息并把它们保存到对应的成员变量里头。然后AddDocTemplate实际调用m_pDocManager->AddDocTemplate，把创建的模板对象加入到文档模板管理器的模板列表中，也就是应用程序对象的文档模板列表中。
2. 文件的创建或者打开

第二步是创建或者打开文件。

对于SDI程序，MFC对象的动态创建过程是在创建或者打开文件中发生的。但是为什么没有看到文件操作相关的语句呢？

CCommandLineInfo

首先，需要弄清楚类CcommandLineInfo，它是用来处理命令行信息的类，CWinApp::PareCommandLine调用CCommandLineInfo的成员函数ParseParm分析启动程序时的参数，把分析结果保存在CCommandLineInfo对象的成员变量里。CCommandLineInfo的定义如下：

class CCommandLineInfo : public CObject

{

BOOL m_bShowSplash;

BOOL m_bRunEmbedded;

BOOL m_bRunAutomated;

enum { FileNew, FileOpen, FilePrint, FilePrintTo, FileDDE,

AppUnregister, FileNothing = -1 } m_nShellCommand;

// not valid for FileNew

CString m_strFileName;

// valid only for FilePrintTo

CString m_strPrinterName;

CString m_strDriverName;

CString m_strPortName;

};

由上述定义可以看出，分析结果分几类：是否OLE激活；应该执行什么动作（FileNew、FileOpen等）；传递的参数（打开或打印的文件名，打印设备、端口等）。

当命令行空时，执行FileNew命令。原因在于CCommandLineInfo的缺省构造函数：

CCommandLineInfo::CCommandLineInfo()

{

m_bShowSplash = TRUE;

m_bRunEmbedded = FALSE;

m_bRunAutomated = FALSE;

m_nShellCommand = FileNew;//指定了SHELL命令操作

}

缺省构造把应该执行的动作指定为FileNew。
处理命令行命令

其次，分析 CWinApp::ProcessShellCommand(CCommandLineInfo& rCmdInfo)的流程，它处理命令行的命令，流程如图5-3所示。

图5-4第三层表示根据命令类型进一步调用的函数，都是CWinApp或者派生类的成员函数。对于FILEDDE类型没有进一步的调用。

命令类型是FILENEW时，调用的函数就是标准命令ID_FILE_NEW对应的处理函数OnFileNew；命令类型是FILEOPEN时调用的函数是OpenDocumentFile，标准命令ID_FILE_OPEN的处理函数OnFileOpen的工作实际上就是由OpenDocumentFile完成的。函数FileNew、OpenDocumentFile导致了窗口、文档的创建。
OnFileNew

接着，分析 CWinApp::OnFileNew流程，如图5-5所示。

图5-5的说明：

应用程序对象得到文档模板管理器指针，调用文档模板管理器的成员函数OnFileNew(m_pDocManager->OnFileNew())；模板管理器获取文档模板对象指针，调用文档模板对象的OpenDocumentFile 函数（pTemplate->OpenDocumentFile(NULL)）。如果模板管理器发现有多个文档模板，就弹出一个对话框让用户选择文档模板。这里和后面的图解中类似于CWinApp::、CDocManager::、CDocTemplate::等的函数类属限制并不表示直接源码中有这样的限制，而是通过指针或者指针的动态约束可以认定调用了某个类的成员函数，其正确性仅仅限于本书图解的MFC的缺省实现。

如图5-5所示，程序员可以覆盖有关虚拟函数或命令处理函数：如果程序员在自己的应用程序类中覆盖了OnFileNew，则可以实现完全不同的处理流程；一般情况下，不会从文档模板类派生新类，如果派生的话，可以覆盖CDocTemplate的虚拟函数。
OnFileOpen

分析了 OnFileNew后，现在分析CWinApp::OnFileOpen()，其流程如图5-6所示。

CWinApp::OnFileOpen和OnFileNew类似，不过，第二步须得到一个要打开的文件的名称，第三步调用的是应用程序对象的OpenDocumentFile，而不是文档模板对象的该函数。
应用程序对象的OpenDocumentFile

分析应用程序的打开文档函数： CWinApp::OpenDocumentFile(LPCSTR name)，其流程如图5-7所示。

　

应用程序对象把打开文件操作委托给文档模板管理器，后者又委托给文档模板对象来执行。如果是SDI程序，则委托给单文档对象；如果是MDI程序，则委托给多文档对象──这是由指针所指对象的实际类型决定的，因为该函数是一个虚拟函数。
文档模板的OpenDocumentFile

不论是FileNew还是FileOpen，最后的操作都归结到由文档模板来打开文件（文件名空则创建文件）。

CSingleDocTemplate::OpenDocumentFile(lpcstr name，BOOL visible)的流程见图5-8。有一点需要指出的是：创建了一个文档对象，并不等于打开了一个文档(件)或者创建了一个新文档(件)。

图5-8显示的流程大致可以描述如下：

如果已经有文档打开，则保存当前的文档；否则，文档对象还没有创建，需要创建一个新的文档对象。因为这时边框窗口还没有生成，所以还要创建边框窗口对象（MFC对象）和边框窗口。MFC边框窗口对象动态创建，HWND边框窗口由LoadFrame创建。MFC边框窗口被创建时，CFrameWnd的缺省构造函数被调用，它把正创建的对象(this所指)加入到模块-线程状态的边框窗口列表m_frameList之首。

边框窗口创建过程中由CreateView动态创建MFC视对象和HWND视窗口。

接着，如果没有指定要打开的文件名，则创建一个新的文件；否则，则打开文件，并使用序列化机制读入文件内容。

通过上述过程，动态地创建了MFC边框窗口对象、视对象、文档对象以及对应的Windows对象，并填写了有关对象的成员变量，建立起这些MFC对象的关系。
打开文件过程中所涉及的消息处理函数和虚拟函数

图5-8描述的整个过程中系列消息处理函数和虚拟函数被调用。例如：在Windwos边框窗口和视窗口被创建时会产生WM_CREATE等消息，导致OnCreate等消息处理函数的调用，CFrameWnd和CView都覆盖了该函数，所以在边框窗口和视窗口的创建中，同样的消息调用了不同的处理函数CFrameWnd::OnCreate和CView::OnCreate。

图5-8涉及的几个虚拟函数的流程分别由图5-9、图5-10图解。图5-9表示CDocument的OnNewDocument的流程；图5-10表示CDocument的OpenDocument的流程。这两个函数分别在创建新文档或者打开一个文档时被调用。从流程可以看出，对于OpenDocument函数，MFC的缺省实现主要用来设置修改标识、序列化读入打开文档的内容。图5-10显示了序列化的操作过程：

首先，使用文档对象打开或者创建的文件句柄创建一个用于读出数据的CArchive对象loadarchive；然后使用它通过Serialize进行序列化操作，完毕，CArchive对象被自动销毁，文件句柄被关闭。

从这些图中可以看到何时、何处调用了什么消息处理函数和虚拟函数，这些函数用来作了什么事情。必要的话，程序员可以在派生类覆盖它们。

在创建工作完成之后，进行初始化，使用文档对象的数据来更新视和显示窗口。

至此，本节描述了MFC的SDI程序从分析命令行到创建或打开文件的处理过程，文档对象已经动态创建。总结如下：

命令行分析→应用程序的FileNew→文档模板的OpenDocumentFile(NULL)→文档的OnNewDocument

命令行分析→应用程序的FileOPen→文档模板的OpenDocumentFile(filename)→文档的OpenDocument

边框窗口对象、视对象的动态创建和对应 Windows对象的创建从LoadFrame开始，这些将在下一节论述。

SDI边框窗口的创建

第三步是创建SDI边框窗口。

图5-8已经分析了创建SDI边框窗口的时机和创建方法，下面，从LoadFrame开始分析整个窗口创建过程。

CFrameWnd::LoadFrame

CFrameWnd::LoadFrame的流程如图5-11所示，其原型如下：

BOOL CFrameWnd::LoadFrame(UINT nIDResource,

DWORD dwDefaultStyle,

CWnd* pParentWnd,

CCreateContext* pContext)

第一个参数是和该框架相关的资源ID，包括字符串、快捷键、菜单、像标等；

第二个参数指定框架窗口的“窗口类”和窗口风格；此处创建SDI窗口时和缺省值相同，为WS_OVERLAPPEDWINDOW | FWS_ADDTOTITLE；

第三个参数指定框架窗口的父窗口，此处和缺省值相同，为NULL；

第四个参数指定创建的上下文，如图5-8所示由CreateNewFrame生成了该变量并传递给LoadFrame。其缺省值为NULL。

创建上下文结构的定义：

struct CCreateContext

{

CRuntimeClass* m_pNewViewClass; //View的动态创建信息

CDocument*m_pCurrentDoc;//指向一文档对象，将和新创建视关联

//用来创建MDI子窗口的信息(C MDIChildFrame::LoadFrame使用)

CDocTemplate* m_pNewDocTemplate;

// for sharing view/frame state from the original view/frame

CView* m_pLastView;

CFrameWnd* m_pCurrentFrame;

};

这里，传递给LoadFrame的CCreateContext变量是：

(视的动态创建信息，新创建的文档对象，当前文档模板，NULL，NULL)。

其中，“新创建的文档对象”就是图 5-8中创建的那个文档对象。从此图中还可以看到，LoadFrame被CreateNewFrame调用，CreateNewFrame是文档模板的成员函数，被文档模板的成员函数OpenDocumentFile所调用，所以，LoadFrame间接地被文档模板调用，“当前文档模板”就是调用它的模板对象。顺便指出，对SDI程序来说是这样的，对MDI程序有所不同。“视的动态创建信息”也是文档模板传递过来的。

对图5-11的说明：

在创建边框窗口之前，先注册“窗口类”。LoadFrame注册了两个“窗口类”，一个为边框窗口，一个为视窗口。关于“窗口类”注册，见2.2.1节。

注册窗口类之后，创建边框窗口，并加载资源。创建边框窗口使用了CFrameWnd的Create虚拟函数，最终调用::CreateEx创建窗口。::CreateEx有11个参数，其最后一个参数就是文档模板传递给LoadFrame的CCreateContext类型的指针，该指针将被传递给窗口过程，进一步由Windows传递给OnCreate函数。顺便指出，创建完毕的边框窗口的窗口过程是统一的MFC窗口过程。

创建边框窗口时，发送消息WM_NCCREATE和WM_CREATE，导致对应的消息处理函数OnNcCreate和OnCreate被调用。CWnd提供了OnNcCreate处理非客户区创建消息，CFrameWnd没有处理该消息，但是提供了OnCreate处理消息WM_CREATE。OnCreate将创建视对象和视窗口。
CFrameWnd::OnCreate

按创建工作的进度，现在要讨论边框窗口创建消息（WM_CREATE）的处理了，处理函数是CFrameWnd的OnCreate，其原型如下：

int CFrameWnd::OnCreate(LPCREATESTRUCT lpcs)

其中，参数指向一个CreateStruct结构（关于CreateStruct的描述见4.4.1节），它包含了窗口创建参数的副本，也就是说CreaeEx窗口创建函数的11个参数被对应地复制到该结构的11个域，例如它的第一个成员就可以转换成CCreateContext类型的指针。

函数OnCreate处理WM_CREATE消息，它从lpcs指向的结构中分离出lpCreateParams并把它转换成为CCreateContext类型的指针pContext，然后，调用OnCreateHelp(lpcs，pContext)，把创建工作委派给它完成。

CFrameWnd::OnCreateHelp的原型如下，流程见图5-11。

int CFrameWnd::OnCreateHelp(LPCREATESTRUCT lpcs,

CCreateContext* pContext)

说明：由于CFrameWnd覆盖了消息处理函数OnCreate来处理WM_CREATE消息，所以CWnd就失去了处理该消息的机会，除非CFrameWnd::OnCreate主动调用基类的该消息处理函数。图5-11展示了对CWnd::OnCreate的调用。

在边框窗口被创建之后，调用虚拟函数OnCreateClient(lpcs，pContext)，它的缺省实现将创建视对象和视窗口。

最后，在状态栏显示“Ready”字样，调用RecalcLayout安排工具栏等的位置。关于WM_SETMESSAGESTRING消息和RecalcLayout函数，见工具栏有关13.2.3节。

到此，SDI的边框窗口已经被创建。下一节将描述视的创建。

视的创建

第四步，创建视。

如前一节所述，若CFrameWnd::OnCreateClient(lpcs，pContext)判断pContext包含了视的动态创建信息，则调用函数CreateView创建视对象和视窗口。CreateView的原型如下，其流程如图5-13所示。

CWnd * CFrameWnd::CreateView(CCreateContext* pContext, UINT nID)

其中：

第一个参数是创建上下文；

第二个参数是创建视 (子窗口)的ID，缺省是AFX_IDW_PANE_FIRST，这里等同缺省值。

说明：

CreateView调用了CWnd的Create函数创建HWND视窗口，视的子窗口ID是AFX_IDW_PANE_FIRST，父窗口是创建它的边框窗口。创建视窗口时的WM_CREATE、WM_NCCREATE消息分别被CView、CWnd的相关消息处理函数处理。处理情况如图5-13所述，这里不作进一步的讨论。

到此，文档对象、边框窗口对象、视窗口对象已经创建，文件已经打开或者创建，边框窗口、视窗口已经创建。现在，是显示和定位窗口、显示文档数据的时候了，这些通过调用CFrameWnd的虚拟函数InitialUpdateFrame完成，如图5-8所示。
窗口初始化

这是第五步，初始化边框窗口、视窗口等。

InitialUpdateFrame的原型如下：

void CFrameWnd::InitialUpdateFrame(CDocument* pDoc, BOOL bMakeVisible)

其中：

第一个参数是当前的文档对象；

第二个参数表示边框窗口是否应该可见并激活。

该函数是在文档模板的OpenDocumentFile中调用的，传递过来的第一个参数是刚才创建的文档，第二个参数是TRUE，见图5-8。

InitialUpdateFrame的处理过程参见图5-14，解释如下：

首先，如果当前边框窗口没有活动视，则获取ID为AFX_IDW_PANE_FIRST的视pView。如果该视不存在，则pView=NULL；否则(pView!=NULL)，调用成员函数SetActiveView(pView，FALSE)把它设置为活动视，参数2为FALSE表示并不通知它成为活动视（见图5-14）。

然后，如果InitialUpdateFrame的参数bMakeVisible为TRUE，则给所有边框窗口的视发送WM_INITIALUPDATE消息，通知它们在显示之前使用文档数据来初始化视。这导致视类的虚拟函数OnInitUpdate被调用，该函数又调用OnUpdate来完成初始化。其他子窗口（如状态栏、工具栏）也将收到WM_INITIALUPDATE消息，导致它们更新状态。

其三，调用pView->OnActivateFrame（WA_INACTIVE，this）给活动视（若存在的话）一个机会来保存当前焦点。这里，解释这个函数：

void CView::OnActivateFrame( UINT nState,CFrameWnd* pFrameWnd );

其中，参数1取值为WA_INACTIVE/WA_ACTIVE/WA_CLICKACTIVE，具体见消息WM_ACTIVE的解释；参数2指向被激活的框架窗口。

视对象通过该虚拟函数在它所属的边框窗口被激活或者失去激活时作一些特别的处理，例如，CFormView用它来保存或者恢复输入焦点控制。

其四，在OnActivateFrame之后，调用成员函数ActivateFrame激活框架窗口。这个过程将产生一个消息WM_ACTIVE（处理该消息的过程在下一节作解释)，它导致OnActiveTopLevel和OnActive被调用。接着，如果活动视非空，则调用成员函数OnActivateView激活它。

至此，参数bMakeVisible为TRUE时显示窗口的处理完毕。

最后，如果参数pDoc非空，则更新边框窗口计数，更新边框窗口的标题。更新边框窗口计数是为了在一个文档对应多个视的情况下，给显示同一文档的不同文档边框窗口编号，编号从1开始，保存在边框窗口的成员变量m_nWindow里。例如有两个边框对应一个文档tt1，则它们的标题分别为“tt1:1”、“tt1:2”。如果只有一个文档只对应一个边框窗口，则成员变量m_nWindow等于-1，标题不含编号，如“tt1”。

当然，对于SDI应用程序，不存在一个文档对应多个视的情况。上述情况是针对MDI应用程序而言的。SDI应用程序执行该过程时，相当于MDI程序的一个特例。

图 5-14涉及的一些函数由图5-15、5-15图解。

　

图5-14中的函数SetActiveView的图解如图5-15所示，其原型如下，：

void CFrameWnd::SetActiveView(CView * pViewNew, BOOL bNotify = TRUE)

其中：

参数1指向被设置的视对象，若非视类型的对象，则为NULL；

参数 2表示是否通知被设置的视。

图5-15中的变量m_pViewActive是CFrameWnd的成员变量，用来保存边框窗口的活动视。

图5-15中的流程可以概括为：Deactivate当前视（m_pViewActive非空时）；设置当前活动视；若参数bNotify为TRUE，通知pViewNew被激活。

图5-14中的函数ActivateFrame图解如图5-16所示，其原型如下，：

void CFrameWnd::ActivateFrame(UINT nCmdShow)

参数nCmdShow用来传递给CWnd::ShowWindow，指定显示窗口的方式。参数缺省为1，图5-14调用时设置为-1。

该函数用来激活(Activate)和恢复(Restore)边框窗口，使得它对用户可见可用。在初始化、OLE事件、DDE事件等需要显示边框窗口的地方调用。图5-16表示的MFC缺省实现是激活边框窗口并把它放到顶层。

程序员可以覆盖该虚拟函数ActivateFrame来控制边框窗口怎样被激活。

图5-16中的函数BringToTop是CFrameWnd内部使用的成员函数(protected)。它调用::BringWindowToTop把窗口放到Z轴上的顶层。

至此，边框窗口初始化的过程已经描述清楚，视的初始化见下一节。
视的初始化

第六步，在边框窗口初始化之后，初始化视。

如图5-14所示，视、工具条窗口处理消息WM_INITAILUPDATE(MFC内部消息)，完成初始化。这里只讨论视的消息处理函数，其原型如下：

void CView::OnInitialUpdate()

图5-14对该函数的注释说明了该函数的特殊之处。其缺省实现是调用OnUpdate(NULL, 0, NULL)更新视。可以覆盖OnInitialUpdate实现自己的初始化。

OnUpdate是一个虚拟函数，其原型如下：

void CView::OnUpdate(CView* pSender, LPARAM lHint, CObject* pHint)

其中：

参数1指向修改文档数据的视；若更新所有的视，设为NULL；

参数2是一个包含了修改信息的long型变量；

参数3指向一个包含修改信息的对象（从CObject派生的对象）。

参数2、参数3是在文档更新对应视的时候传递过来的。

该函数用来更新显示视窗口，反映文档的变化，在MFC中，它为函数CView::OnInitialUpdate和CDocument::UpdateAllViews所调用。其缺省实现是使整个客户区无效。在下一次收到WM_PAINT消息时，重绘无效区。

工具条的初始化见讨论第13章。
激活边框窗口(处理WM_ACTIVE)

第七步，在窗口初始化完成之后，激活并显示出来。

下面讨论边框窗口激活时的处理（对WM_ACTIVE的处理）。

WM_ACTIVE的消息参数

wParam的低阶word指示窗口是被激活还是失去激活：WA_ACTIVE，被鼠标点击以外的方法激活；WA_CLICKACTIVE，由鼠标点击激活；WA_INACTIVE，失去激活；

wParam的高阶word指示窗口是否被最小化；非零表示最小化；

lPararm表示将激活的窗口句柄(WA_INACTIVE)，或者将失去激活的窗口句柄(WA_CLICKACTIVE、WA_ACTIVE)。

在标准Windows消息处理的章节中，曾指出处理WM_ACTIVE消息时，先要调用一个函数_AfxHandleActivate，此函数的原型如下：

static void AFXAPI _AfxHandleActivate(CWnd* pWnd,

WPARAM nState,CWnd* pWndOther)

其中：

参数1是接收消息的窗口；

参数2是窗口状态，为WM_ACTIVE的消息参数wParam;

参数3是WM_ACTIVE的消息参数lParam表示的窗口。

_AfxHandleActivate是MFC内部使用的函数，声明和实现均在WinCore.CPP文件中。实现如下：

如果pWnd指向的窗口不是子窗口，而且pWnd和pWndOther窗口的顶级父窗口(TopLevelParent)不是同一窗口，则发送MFC定义的消息WM_ACTIVATETOPLEVEL给pWnd的顶级窗口，消息参数wParam是nState，消息参数lParam指向一个长度为二的数组，数组里存放pWnd和pWndOther所指窗口的句柄。否则，_AfxHandleActivate不作什么。

从这里可以看出：只有顶层的主边框窗口能处理WM_ACTIVE消息，事实上，Windows系统只会给顶层的非子窗口发送WM_ACTIVE消息。
WM_ACTIVATETOPLEVEL消息的处理

CWnd及派生类CFrameWnd实现了对WM_ACTIVATETOPLEVEL消息的处理，分别解释如下：

消息处理函数CWnd::OnActivateTopLevel如果失去激活，则取消工具栏的提示（TOOLTIP）。

消息处理函数CFrameWnd::OnActivateTopLevel调用CWnd的OnActivateTopLevel；如果接收WM_ACTIVE消息的窗口是线程主窗口，则使得其活动的视窗口变成非活动的（OnActive(FALSE, pActiveView,pActiveView)。

从这里可以知道，在顶层窗口接收到WM_ACTIVE消息后，MFC会进行一些固定的处理，然后才调用WM_ACTIVE消息处理函数。
WM_ACTIVE消息的处理

在_AfxHandleActivate和WM_ACTIVATETOPLEVEL消息处理完之后，才是对WM_ACTIVE的处理。CWnd和CFrameWnd都实现了消息处理。

CWnd的消息处理函数：

void CWnd::OnActive(UINT nState, CWnd* pWndOther, BOOL bMinimized)

其中：

参数1取值为WA_INACTIVE/WA_ACTIVE/WA_CLICKACTIVE；

参数2指向激活或者失去激活的窗口，具体同WM_ACTIVE消息；

参数3表示是否最小化。

此函数的实现是调用Default()，作缺省处理。

CFrameWnd的消息处理函数：

void CFrameWnd::OnActive(UINT nState,CWnd* pWndOther, BOOL bMinimized)

首先调用CWnd::OnActivate。

如果活动视非空，消息是WA_ACTIVE/WA_CLICKACTIVE，并且不是最小化，则重新激活当前视，调用了以下函数：

pActiveView->OnActiveView(TRUE，pActiveView，pActiveView)；

并且，如果活动视非空，通知它边框窗口状态的变化（激活/失去激活），调用以下函数：

pActiveView->OnActivateFrame(nState, this)。

SDI流程的回顾

从InitialInstance开始，首先应用程序对象创建文档模板，文档模板创建文档对象、打开或创建文件；然后，文档模板创建边框窗口对象和边框窗口；接着边框窗口对象创建视对象和视窗口。这些创建是以应用程序的文档模板为中心进行的。在创建这些MFC对象的同时，建立了它们之间的关系。创建这些之后，进行初始化，激活主边框窗口，把边框窗口、视窗口显示出来。

这样，一个SDI应用程序就完成了启动过程，等待着用户的交互或者输入。

5.3.4节将在SDI程序启动流程的基础之上，介绍MDI应用程序的启动流程。两者的相同之处可以这样类比：创建SDI边框窗口、视、文档的过程和创建MDI文档边框窗口、视、文档的过程类似。不同之处主要表现在：主边框窗口的创建不一样；MDI有文档边框窗口的创建，SDI没有；SDI只能一个文档、一个视；MDI可能多文档、多个视。

MDI程序的对象创建

MDI应用程序对象的InitialInstance函数一般含有以下代码：

//第一部分：创建和添加模板

CMultiDocTemplate* pDocTemplate;

pDocTemplate = new CMultiDocTemplate(

IDR_TTTYPE,

RUNTIME_CLASS(CTtDoc),

RUNTIME_CLASS(CChildFrame),//custom MDI child frame

RUNTIME_CLASS(CTtView));

AddDocTemplate(pDocTemplate);

//第二部分：创建MFC框架窗口对象和Windows主边框窗口

// 创建主MDI边框窗口

CMainFrame* pMainFrame = new CMainFrame;

if (!pMainFrame->LoadFrame(IDR_MAINFRAME))

return FALSE;

m_pMainWnd = pMainFrame;

//第三部分：处理命令行，命令行空则执行OnFileNew创建新文档

//分析命令行

CCommandLineInfo cmdInfo;

ParseCommandLine(cmdInfo);

// 处理命令行命令

if (!ProcessShellCommand(cmdInfo))

return FALSE;

第四部分：显示和更新主框架窗口

// 主窗口已被初始化，现在显示和更新主窗口

pMainFrame->ShowWindow(m_nCmdShow);

pMainFrame->UpdateWindow();

SDI应用程序对象的InitialInstance和SDI应用程序对象的InitialInstance比较，有以下的相同和不同之处。相同之处在于：

创建和添加模板；处理命令行。

不同之处在于：

创建的模板类型不同。SDI使用单文档模板，边框窗口类从CFrameWnd派生；MDI使用多文档模板，边框窗口类从CMDIChildWnd派生.
主窗口类型不同。SDI的是从CFrameWnd派生的类；MDI的是从CMDIFrameWnd派生的类。
主框架窗口的创建方式不同。SDI在创建或者打开文档时动态创建主窗口对象，然后加载主窗口(LoadFrame)并初始化；MDI使用第二部分的语句来创建动态主窗口对象和加载主窗口，第四部分语句显示、更新主窗口。
命令行处理的用途不一样。SDI一定要有命令行处理部分的代码，因为它导致了主窗口的创建；MDI可以去掉这部分代码，因为它的主窗口的创建、显示等由第二、四部分的语句来处理。

有别于SDI的主窗口加载过程

和SDI应用程序一样，MDI应用程序使用LoadFrame加载主边框窗口，但因为LoadFrame的虚拟属性，所以MDI调用了CMDIFrameWnd的LoadFrame函数，而不是CFrameWnd的LoadFrame。

LoadFrame的参数1指定了资源ID，其余几个参数取缺省值。和SDI相比，第四个创建上下文参数为NULL，因为MDI主窗口不需要文档、视等的动态创建信息。

图 5-17图解了CMdiFrameWnd::LoadFrame的流程：

首先，用同样的参数调用基类CFrameWnd的LoadFrame，其流程如图5-11所示，但由于参数4表示的创建上下文为空，所以，CFrameWnd::LoadFrame在加载了菜单和快捷键之后，给所有子窗口发送WM_INITUPDATE消息。

另外，WM_CREATE消息怎样处理呢？由于CMDIFrameWnd没有覆盖OnCreate，所以还是由基类CFrameWnd::OnCreate处理。但是它调用虚拟函数OnCreateClient（见图5-12）时，由于CMDIFrameWnd覆盖了该函数，所以动态约束的结果是CMDIFrameWnd::OnCreateClient被调用，它和基类的OnCreateClient不同，后者CreateView创建MFC视对象和视窗口，前者调用虚拟函数CreateClient创建MDI客户窗口。MDI客户窗口负责创建和管理MDI子窗口。

CreateClient是CMDIFrameWnd的虚拟函数，其原型如下：

BOOL CMDIFrameWnd::CreateClient(

LPCREATESTRUCT lpCreateStruct, CMenu* pWindowMenu);

该函数主要用来创建MDI客户区窗口。它使用Windows系统预定义的“mdiclient”窗口类来创建客户区窗口，保存该窗口句柄在CMDIFrameWnd的成员变量m_hWndMDIClient中。调用::CreateWindowEx创建客户窗口时传递给它的窗口创建数据参数（第11个参数）是一个CLIENTCREATESTRUCT结构类型的参数，该结构指定了一个菜单和一个子窗口ID：

typedef struct tagCLIENTCREATESTRUCT{

HMENU hWindowMenu;

UINT idFirstChild;

}CLIENTCREATESTRUCT;

hWindowMenu表示主边框窗口菜单栏上的“Windows弹出菜单项”的句柄。MDICLIENT类客户窗口在创建MDI子窗口时，把每一个子窗口的标题加在这个弹出菜单的底部。idFirstChild是第一个被创建的MDI子窗口的ID号，第二个MDI子窗口ID号为idFirstChild+1，依此类推。

这里，hWindowMenu的指定不是必须的，程序员可以在MDI子窗口激活时进行菜单的处理；idFirstChild的值是AFX_IDM_FIRST_MDICHILD。

综合地讲，CMDIFrameWnd::LoadFrame完成创建MDI主边框窗口和MDI客户区窗口的工作。

创建了MDI边框窗口和客户区窗口之后，接着是处理WM_INITUPDATE消息，进行初始化。但是按SDI应用程序的讨论顺序，下一节先讨论MDI子窗口的创建。
MDI子窗口、视、文档的创建

和SDI应用程序类似，MDI应用程序通过文档模板来动态创建MDI子窗口、视、文档对象。不同之处在于：这里使用了多文档模板，调用的是CMDIChildWnd（或派生类）的消息处理函数和虚拟函数，如果它覆盖了CFrameWnd的有关函数的话。

还是以处理标准命令消息ID_FILE_NEW的OnFileNew为例。

表示OnFileNew的图5-5、表示OnFileOpen的图5-6在多文档应用程序中仍然适用，但表示OpenDocumentFile的图5-8有所不同，其第三步中地单文档模板应当换成多文档模板，关于这一点，参阅图5-8的说明。

（1）多文档模板的OpenDocumentFile

MDI的OpenDocumentFile的原型如下：

CDocument* CMultiDocTemplate::OpenDocumentFile(

LPCTSTR lpszPathName, BOOL bMakeVisible)；

它的原型和单文档模板的该函数原型一样，但处理流程比图5-8要简单些：

第一，不用检查是否已经打开了文档；

第二，不用判断是否需要创建框架窗口或者文档对象，因为不论新建还是打开文档都需要创建新的文档框架窗口(MDI子窗口)和文档对象。

除了这两点，其他处理步骤基本相同，调用同样名字的函数来创建文档对象和MDI子窗口。虽然是名字相同的函数，但是参数的值可能有异，又由于C++的虚拟机制和MFC消息映射机制，这些函数可能来自不同层次类的成员函数，因而导致有不同的处理过程和结果，即SDI创建了CFrameWnd类型的对象和边框窗口；MDI则创建了CMDIChildWnd类型的对象和边框窗口。不同之处解释如下：

（2）CMDIChildWnd的虚拟函数LoadFrame

CMDIChildWnd::LoadFrame代替了图5-8中的CFrameWnd::LoadFrame，两者流程大致相同，可以参见图5-11。但是它们用来创建窗口的函数不同。前者调用了函数CMDIChildWnd::Create(参数1…参数6)；后者调用了CFrameWnd::Create(参数1…参数7)。

这两个窗口创建函数，虽然都是虚拟函数，但是有很多不同之处：

前者是CMDIChildWnd定义的虚拟函数，后者是CWnd定义的虚拟函数；
前者在参数中指定了父窗口，即主创建窗口，后者的父窗口参数为NULL；
前者指定了WS_CHILD风格，创建的是子窗口，后者创建一个顶层窗口；
前者给客户窗口m_hWndMDIClient(CMDIFrameWnd的成员变量)发送WM_MDICREATE消息让客户窗口来创建MDI子窗口（主边框窗口的子窗口是客户窗口，客户窗口的子窗口是MDI子窗口），后者调用::CreateEx函数来创建边框窗口；
前者的窗口创建数据是指向MDICREATESTRUCT结构的指针，该结构的最后一个域存放一个指向CCreateContext结构的指针，后者是指向CCreateContext结构的指针。

MDICREATESTRUCT结构的定义如下：

typedef struct tagMDICREATESTRUCT { // mdic

LPCTSTR szClass;

LPCTSTR szTitle;

HANDLE hOwner;

int x;

int y;

int cx;

int cy;

DWORD style;

LPARAM lParam;

}MDICREATESTRUCT;

该结构的用处和CREATESTRUCT类似，只是它仅用于MDI子窗口的创建上，用来保存创建MDI子窗口时的窗口创建数据。域lParam保存一个指向CCreateContext结构的指针。

WM_CREATE的处理函数不同

创建MDI子窗口时发送的WM_CREATE消息由CMDIChildWnd的成员函数OnCreate(LPCREATESTRUCT lpCreateStruct)处理。

OnCreate函数仅仅从lpCreateStruct指向的数据中取出窗口创建数据，即指向MDICREATESTRUCT结构的指针，并从该结构得到指向CCreateContext结构的指针pContext，然后调用虚拟函数OnCreateHelper(lpCreateStruct，pContext)。

此处动态约束的结果是调用了CFrameWnd的成员函数OnCreateHelper。SDI应用程序的OnCreate也调用了CFrameWnd::OnCreateHelper，所以后面的处理（创建视等）可参见SDI的流程了。

待MDI子窗口、视、文档对象创建完毕，多文档模板的OpenDocumentFile也调用InitialUpdateFrame来进行初始化。

MDI子窗口的初始化和窗口的激活

（1）MDI子窗口的初始化

完成了 MDI子窗口、视、文档的创建之后，多文档模板的OpenDocumenFile调用边框窗口的虚拟函数InitialUpdateFrame进行初始化，该函数流程参见图5-14。不过，这里this指针指向CMDIChildWnd对象，由于C++虚拟函数的动态约束，初始化过程调用了CMDIChildWnd的ActivateFrame函数（不是CFrameWnd的ActivateFrame），来显示MDI子窗口，更新菜单等等，见图5-18。

图5-18的说明：

第一，调用基类CFrameWnd的ActivateFrame显示窗口时，由于当前窗口是文档边框窗口，所以没有发送WM_ACTIVATE消息，而是发送消息WM_MDIACTIVATE。

第二，由于Windows不处理MDI子窗口的激活，所以必须由MFC或者程序员来完成。当一个激活的MDI子窗口被隐藏后从可见变成不可见，但它仍然是活动的，这时需要把下一文档边框窗口激活以便用户看到的就是激活的窗口。在没有其他文档边框窗口时，则把该隐藏的文档边框窗口标记为“伪失去激活”。当一个文档边框窗口从不可见变成可见时，检查变量m_bPseudoInactive，若真则该窗口从Windows角度看仍然是激活的，只需要调用OnMDIActivate把它改成“MFC激活”。OnMDIActivate把变量m_bPseudoInactive的值改变为FALSE。

至此，MDI子窗口初始化调用描述完毕。初始化将导致MDI窗口被显示、激活。下面讨论MDI子窗口的激活。

（2）MDI子窗口的激活

通过给客户窗口发送消息WM_MDIACTIVATE来激活文档边框窗口。客户窗口发送WM_MDIACTIVATE消息给将被激活或者取消激活的MDI子窗口(文档边框窗口)，这些子窗口调用消息处理函数OnMDIActivate响应该消息WM_MDIACTIVATE。关于MDI消息，见表5-12。

用户转向一个子窗口（包括文档边框窗口）导致它的顶层(TOP LEVEL)边框窗口收到WM_ACTIVATE消息而被激活，子窗口是文档边框窗口的话将收到WM_MDIACTIVATE消息。

但是，一个边框窗口被其他方式激活时，它的文档边框窗口不会收到WM_MDIACTIVATE消息，而是最近一次被激活的文档边框窗口收到WM_NCACTIVATE消息。该消息由CWnd::Default缺省处理，用来重绘文档边框窗口的标题栏、边框等等。

MDI子窗口用OnMDIActiveate函数处理WM_MDIACTIVATE消息。其原型如下：

void CMDIChildWnd::OnMDIActivate( BOOL bActivate,

CWnd* pActivateWnd,CWnd* pDeactivateWnd );

其中：

参数1表示是激活(TRUE)，还是失去激活(FALSE)；

参数2表示将被激活的MDI子窗口；

参数3表示将被失去激活的MDI子窗口；

简单地说，该函数把m_bPseudoInactive的值改变为FALSE，调用成员函数OnActivateView通知失去激活的子窗口的视它将失去激活，调用成员函数OnActivateView通知激活子窗口的视它将被激活。

至于MDI主边框窗口，它还是响应WM_ACTIVATE消息而被激活或相反。CMDIFrameWnd没有提供该消息的处理函数，它调用基类CFrameWnd的处理函数OnActivate。

现在，MDI应用程序的启动过程描述完毕。

表5-12 MDI消息

消息	说明
WM_MDIACTIVATE	激活MDI Child窗口
WM_MDICASCADE	CASCADE排列MDI Child窗口
WM_MDICREATE	创建MDI Child窗口
WM_MDIDESTROY	销毁MDI Child窗口
WM_MDIGETACTIVE	得到活动的MDI Child窗口
WM_MDIICONARRANGE	安排最小化了的MDI Child窗口
WM_MDIMAXIMIZE	MDI Child窗口最大化
WM_MDINEXT	激活Z轴顺序的下一MDI Child窗口
WM_MDIREFRESHMENU	根据当前MDI Child窗口更新菜单
WM_MDIRESTORE	恢复MDI Child窗口
WM_MDISETMENU	根据当前MDI Child窗口设置菜单
WM_MDITITLE	TITLE安排MDI Child窗口

应用程序的退出

一个Windows应用程序启动之后，一般是进入消息循环，等待或者处理用户的输入，直到用户关闭应用程序窗口，退出应用程序为止。

例如，用户按主窗口的关闭按钮，或者选择执行系统菜单“关闭”，或者从“文件”菜单选择执行“退出”，都会导致主窗口被关闭。

当用户从“文件”菜单选择执行“退出”时，将发送MFC标准命令消息ID_APP_EXIT。MFC实现了函数CWinApp::OnAppExit()来完成对该命令消息的缺省处理。

void CWinApp::OnAppExit()

{

// same as double-clicking on main window close box

ASSERT(m_pMainWnd != NULL);

m_pMainWnd->SendMessage(WM_CLOSE);

}

可以看出，其实现是向主窗口发送WM_CLOSE消息。主窗口处理完WM_CLOSE消息之后，关闭窗口，发送WM_QUIT消息，退出消息循环（见图5-3），进而退出整个应用程序。
1. 边框窗口对WM_CLOSE的处理

MFC提供了函数CFrameWnd::OnClose来处理各类边框窗口的关闭：不仅包括SDI的边框窗口(从CFrameWnd派生)，而且包括MDI的主边框窗口（从CMDIFrameWnd派生）或者文档边框窗口(从CMDIChildWnd派生)的关闭。

该函数的原型如下，流程如图6-1所示：

void CFrameWnd::OnClose()

从图6-1中可以看出，它首先判断是否可以关闭窗口（m_lpfnCloseProc是函数指针类型的成员变量，用于打印预览等情况下），然后，根据具体情况进行处理：

如果是主窗口被关闭，则关闭程序的所有文档，销毁所有窗口，退出程序；
如果不是主窗口被关闭，则是文档边框窗口被关闭，又分两种情况：若该窗口所显示的文档被且仅被该窗口显示，则关闭文档和文档窗口并销毁窗口；若该窗口显示的文档还被其他文档边框窗口所显示，则仅仅关闭和销毁文档窗口。

下面是处理 WM_CLOSE消息中涉及的一些函数。

BOOL CDocument::SaveModified()

该虚拟函数的缺省实现：首先调用IsModifed判断文档是否被修改，没有修改就返回，否则继续。

当询问用户是否保存被修改的文档时，若用户表示“cancel”，返回FALSE；若用户表示“no”，则返回TRUE；若用户表示“yes”，则存盘失败返回FALSE，存盘成功返回TRUE。存盘处理首先要得到被保存文件的名称，然后调用虚拟函数OnSaveDocument完成存盘工作，并使用SetModifidFlag(FALSE)设置文档为没有修改。

BOOL CDocument::OnSaveDocument(LPCTSTR lpszPathName)

该函数是虚拟函数，用来保存文件。其实现的功能和OpOpenDocument相反，但处理流程类似，描述如下：

根据lpszPathName打开文件pFile；

使用pFile构造一个用于写入数据的CArchive对象，此对象用来保存数据到文件；

设置鼠标为时间瓶形状；

使用Serialize函数完成序列化写；

完毕，恢复鼠标的形状。

CWinApp::SaveAllModified()

CWinApp::CloseAllDocuments(BOOL bEndSession)

这两个函数都遍历模板管理器列表，并分别对列表中的模板管理器对象逐个调用CDocManager的同名成员函数：

CDocManager::SaveAllModified()

CDocManager::CloseAllDocuments(BOOL bEndSession)

这两个函数都遍历其文档模板列表，并分别对列表中的模板对象逐个调用CDocTemplate的同名成员函数：

CDocTemplate::SaveAllModified()

CDocTemplate::CloseAllDocuments(BOOL bEndSession)

这两个函数都遍历其文档列表，并分别对列表中的文档对象逐个调用CDocuemnt的成员函数：

CDocument::SaveModified()

CDocument::OnCloseDocument()

CDocument::SaveModified()

CDocument::OnCloseDocument()

CDocument::SaveModified前面已作了解释。OnCloseDocument是一个虚拟函数，其流程如图6-2所示。

通过文档对象所对应的视，得到所有显示该文档的边框窗口的指针：在SDI程序关闭窗口时，获取的是主边框窗口；在MDI程序关闭窗口时，获取的是MDI子窗口。

然后，关闭并销毁对应的边框窗口。

如果文档对象的 m_bAutoDelete为真，则销毁文档对象自身。

窗口的销毁过程
1. DestroyWindow
  
  从图6-1、图6-2可以看出，销毁窗口是通过调用DestroyWindow来完成的。DestroyWindow是CWnd类的一个虚拟函数。CWnd实现了该函数，而CMDIChildWnd覆盖了该函数。
  
  （1）CWnd::DestroyWindow()
  
  主要就是调用::DestroyWindow销毁m_hWnd(必须非空)，同时销毁其菜单、定时器，以及完成其他清理工作。
  
  ::DestroyWindow使将被销毁的窗口失去激活、失去输入焦点，并发送WM_DESTROY、WM_NCDESTROY消息到该窗口及其各级子窗口。如果被销毁的窗口是子窗口且没有设置WM_NOPARENTNOTFIY风格，则给其父窗口发送WM_PARENTNOFITY消息。
  
  （2）CMDIChildWnd::DestroyWindow()
  
  因为MDI子窗口不能使用::DestroyWindows来销毁，所以CMdiChildWnd覆盖了该函数，CMDIChildWnd主要是调用成员函数MDIDestroy给客户窗口(父窗口)发送消息WM_MDIDESTROY，让客户窗口来销毁自己。
2. 处理WM_DESTROY消息

消息处理函数OnDestroy处理WM_DESTROY消息，CFrameWnd、CMDIChildWnd、CWnd、CView及其派生类（如CEditView等等）、CControlBar等都提供了对该消息的处理函数。这里，主要解释边框、文档边框、视类的消息处理函数OnDestroy。

CWnd::OnDestroy()

调用缺省处理函数Default()。
CFrameWnd::OnDestroy()

首先，销毁工具栏的窗口；然后，设置菜单为缺省菜单；接着，如果要销毁的是主边框窗口，则通知HELP程序本应用程序将退出，没有其他程序使用WINHELP则关闭WINHELP；最后调用CWnd::OnDestroy。
CMDIFrameWnd::OnDestroy()

首先，调整客户窗口的边界类型；然后，调用基类CframeWnd的OnDestroy。这时，MDI子窗口的工具栏窗口列表为空，故没有工具栏窗口可以销毁。
CView::OnDestroy()

首先，判断自身是否是边框窗口的活动视，如果是则调用边框窗口的SetActivateView使自己失去激活；然后，调用基类CWnd的OnDestroy。

处理WM_NCDESTROY消息

窗口的非客户区被销毁时，窗口接收WM_NCDESTROY消息，由OnNcDestroy处理WM_NCDESTROY消息。在MFC中，OnNcDestroy是Windows窗口被销毁时调用的最后一个成员函数。

CWnd、CView的某些派生类提供了对该消息的处理函数，这里只讨论CWnd的实现。

CWnd::OnNcDestroy()

首先判断当前线程的主窗口是否是该窗口，如果是且模块非DLL，则发送WM_QUIT消息，使得程序结束；

然后，判断当前线程的活动窗口是否是该窗口，如果是则设置活动窗口为NULL；

接着，清理Tooltip窗口，调用Default由Windows缺省处理WM_NCDESTROY消息，UNSUBCLASS，把窗口句柄和MFC窗口对象分离(Detach)；

最后，调用虚拟函数PostNcDestoy。
PostNcDestoy

CWnd、CFrameWnd、CView、CControlBar等都覆盖了该函数。文档边框窗口和边框窗口都使用CFrameWnd::PostNcDestroy。

CWnd::PostNcDestroy()

MFC缺省实现空

void CFrameWnd::PostNcDestroy()

调用delete this销毁自身这个MFC对象。

void CView::PostNcDestroy()

调用delete this销毁自身这个MFC对象。

析构函数

delete this导致析构函数的调用。需要提到的是CFrameWnd和CView的析构函数。

CFrameWnd::~CFrameWnd()

边框窗口在创建时，把自身加入到模块-线程状态的边框窗口列表m_frameList中。现在，从列表中移走该窗口对象。

必要的话，删除m_phWndDisable数组。

CView::~CView()

在视创建时，把自身加入到文档对象的视列表中。现在，从列表中移走该视对象。

应用程序调用CloseAllDocument关闭文档时。参数为FALSE，它实际上并没有把视从列表中清除，而最后的清除是由析构函数来完成的。

至此，边框窗口关闭的过程讨论完毕。下面，结合具体情况──SDI窗口的关闭、MDI主窗口的关闭、MDI子窗口的关闭──描述对WM_CLOSE消息的处理。

SDI窗口、MDI主、子窗口的关闭

参考图6-1分析SDI窗口、MDI主、子窗口的关闭流程。

SDI窗口的关闭

在这种情况下，主窗口将被关闭。首先，关闭应用程序的文档对象。文档对象的虚拟函数OnCloseDocument调用时销毁了主窗口（Windows窗口和MFC窗口对象），同时也导致视、工具条窗口的销毁。主窗口销毁后，应用程序的主窗口对象为空，故发送WM_QUIT消息结束程序。
MDI主窗口的关闭

首先，关闭应用程序的所有文档对象。文档对象的OnCloseDocument函数关闭文档时，将销毁文档对象对应的文档边框窗口和它的视窗口。这样，所有的MDI子窗口（包括其子窗口视）被销毁，但应用程序的主窗口还在。接着，调用DestroyWindow成员函数销毁主窗口自身，DestroyWindow发现被销毁的是应用程序的主窗口，于是发送WM_QUIT消息结束程序。
MDI子窗口（文档边框窗口）的关闭

在这种情况下，被关闭的不是主窗口。判断与该文档边框窗口对应的文档对象是否还被其他一个或者多个文档边框窗口使用，如果是，则仅仅销毁该文档边框窗口（包括其子窗口视）；否则，关闭文档，文档对象的OnCloseDocument将销毁该文档边框窗口（包括其子窗口视）。

MFC的DLL

一般的，在介绍Windows编程的书中讲述DLL的有关知识较多，而介绍MFC的书则比较少地提到。即使使用MFC来编写动态链接库，对于初步接触DLL的程序员来说，了解DLL的背景知识是必要的。另外，MFC提供了新的手段来帮助编写DLL程序。所以，本节先简洁的介绍有关概念。
1. DLL的背景知识

静态链接和动态链接

当前链接的目标代码(.obj)如果引用了一个函数却没有定义它，链接程序可能通过两种途径来解决这种从外部对该函数的引用：

静态链接

链接程序搜索一个或者多个库文件(标准库.lib)，直到在某个库中找到了含有所引用函数的对象模块，然后链接程序把这个对象模块拷贝到结果可执行文件(.exe)中。链接程序维护对该函数的所有引用，使它们指向该程序中现在含有该函数拷贝的地方。

动态链接

链接程序也是搜索一个或者多个库文件(输入库.lib)，当在某个库中找到了所引用函数的输入记录时，便把输入记录拷贝到结果可执行文件中，产生一次对该函数的动态链接。这里，输入记录不包含函数的代码或者数据，而是指定一个包含该函数代码以及该函数的顺序号或函数名的动态链接库。

当程序运行时，Windows装入程序，并寻找文件中出现的任意动态链接。对于每个动态链接，Windows装入指定的DLL并且把它映射到调用进程的虚拟地址空间（如果没有映射的话）。因此，调用和目标函数之间的实际链接不是在链接应用程序时一次完成的（静态），相反，是运行该程序时由Windows完成的（动态）。

这种动态链接称为加载时动态链接。还有一种动态链接方式下面会谈到。

动态链接的方法

链接动态链接库里的函数的方法如下：

加载时动态链接(Load_time dynamic linking)

如上所述。Windows搜索要装入的DLL时，按以下顺序：

应用程序所在目录→当前目录→Windows SYSTEM目录→Windows目录→PATH环境变量指定的路径。

运行时动态链接(Run_time dynamic linking)

程序员使用LoadLibrary把DLL装入内存并且映射DLL到调用进程的虚拟地址空间（如果已经作了映射，则增加DLL的引用计数）。首先，LoadLibrary搜索DLL，搜索顺序如同加载时动态链接一样。然后，使用GetProcessAddress得到DLL中输出函数的地址，并调用它。最后，使用FreeLibrary减少DLL的引用计数，当引用计数为0时，把DLL模块从当前进程的虚拟空间移走。

输入库(.lib)：

输入库以.lib为扩展名，格式是COFF(Common object file format)。COFF标准库（静态链接库）的扩展名也是.lib。COFF格式的文件可以用dumpbin来查看。

输入库包含了DLL中的输出函数或者输出数据的动态链接信息。当使用MFC创建DLL程序时，会生成输入库(.lib)和动态链接库(.dll)。
输出文件(.exp)

输出文件以.exp为扩展名，包含了输出的函数和数据的信息，链接程序使用它来创建DLL动态链接库。
映像文件(.map)

映像文件以.map为扩展名，包含了如下信息：

模块名、时间戳、组列表（每一组包含了形式如section::offset的起始地址，长度、组名、类名）、公共符号列表(形式如section::offset的地址，符号名，虚拟地址flat address，定义符号的.obj文件)、入口点如section::offset、fixup列表。
lib.exe工具

它可以用来创建输入库和输出文件。通常，不用使用lib.exe，如果工程目标是创建DLL程序，链接程序会完成输入库的创建。

更详细的信息可以参见MFC使用手册和文档。
链接规范（Linkage Specification ）

这是指链接采用不同编程语言写的函数(Function)或者过程(Procedure)的链接协议。MFC所支持的链接规范是“C”和“C++”，缺省的是“C++”规范，如果要声明一个“C”链接的函数或者变量，则一般采用如下语法：

#if defined(__cplusplus)

extern “C”

{

#endif

//函数声明（function declarations）

…

//变量声明(variables declarations)

#if defined(__cplusplus)

}

#endif

所有的C标准头文件都是用如上语法声明的，这样它们在C++环境下可以使用。
修饰名(Decoration name)

“C”或者“C++”函数在内部（编译和链接）通过修饰名识别。修饰名是编译器在编译函数定义或者原型时生成的字符串。有些情况下使用函数的修饰名是必要的，如在模块定义文件里头指定输出“C++”重载函数、构造函数、析构函数，又如在汇编代码里调用“C””或“C++”函数等。

修饰名由函数名、类名、调用约定、返回类型、参数等共同决定。

调用约定

调用约定(Calling convention)决定以下内容：函数参数的压栈顺序，由调用者还是被调用者把参数弹出栈，以及产生函数修饰名的方法。MFC支持以下调用约定：

_cdecl

按从右至左的顺序压参数入栈，由调用者把参数弹出栈。对于“C”函数或者变量，修饰名是在函数名前加下划线。对于“C++”函数，有所不同。

如函数void test(void)的修饰名是_test；对于不属于一个类的“C++”全局函数，修饰名是?test@@ZAXXZ。

这是MFC缺省调用约定。由于是调用者负责把参数弹出栈，所以可以给函数定义个数不定的参数，如printf函数。
_stdcall

按从右至左的顺序压参数入栈，由被调用者把参数弹出栈。对于“C”函数或者变量，修饰名以下划线为前缀，然后是函数名，然后是符号“@”及参数的字节数，如函数int func(int a, double b)的修饰名是_func@12。对于“C++”函数，则有所不同。

所有的Win32 API函数都遵循该约定。
_fastcall

头两个DWORD类型或者占更少字节的参数被放入ECX和EDX寄存器，其他剩下的参数按从右到左的顺序压入栈。由被调用者把参数弹出栈，对于“C”函数或者变量，修饰名以“@”为前缀，然后是函数名，接着是符号“@”及参数的字节数，如函数int func(int a, double b)的修饰名是@func@12。对于“C++”函数，有所不同。

未来的编译器可能使用不同的寄存器来存放参数。
thiscall

仅仅应用于“C++”成员函数。this指针存放于CX寄存器，参数从右到左压栈。thiscall不是关键词，因此不能被程序员指定。
naked call

采用1-4的调用约定时，如果必要的话，进入函数时编译器会产生代码来保存ESI，EDI，EBX，EBP寄存器，退出函数时则产生代码恢复这些寄存器的内容。naked call不产生这样的代码。

naked call不是类型修饰符，故必须和_declspec共同使用，如下：

__declspec( naked ) int func( formal_parameters )

{

// Function body

}
过时的调用约定

原来的一些调用约定可以不再使用。它们被定义成调用约定_stdcall或者_cdecl。例如：

#define CALLBACK __stdcall

#define WINAPI __stdcall

#define WINAPIV __cdecl

#define APIENTRY WINAPI

#define APIPRIVATE __stdcall

#define PASCAL __stdcall

表7-1显示了一个函数在几种调用约定下的修饰名（表中的“C++”函数指的是“C++”全局函数，不是成员函数），函数原型是void CALLTYPE test(void)，CALLTYPE可以是_cdecl、_fastcall、_stdcall。

表7-1 不同调用约定下的修饰名

调用约定	extern “C”或.C文件	.cpp, .cxx或/TP编译开关
_cdecl	_test	?test@@ZAXXZ
_fastcall	@test@0	?test@@YIXXZ
_stdcall	_test@0	?test@@YGXXZ

MFC的DLL应用程序的类型

静态链接到MFC的规则DLL应用程序

该类DLL应用程序里头的输出函数可以被任意Win32程序使用，包括使用MFC的应用程序。输入函数有如下形式：

extern “C” EXPORT YourExportedFunction( );

如果没有extern “C”修饰，输出函数仅仅能从C++代码中调用。

DLL应用程序从CWinApp派生，但没有消息循环。
动态链接到MFC的规则DLL应用程序

该类DLL应用程序里头的输出函数可以被任意Win32程序使用，包括使用MFC的应用程序。但是，所有从DLL输出的函数应该以如下语句开始：

AFX_MANAGE_STATE(AfxGetStaticModuleState( ))

此语句用来正确地切换MFC模块状态。关于MFC的模块状态，后面第9章有详细的讨论。

其他方面同静态链接到MFC的规则DLL应用程序。
扩展DLL应用程序

该类DLL应用程序动态链接到MFC，它输出的函数仅可以被使用MFC且动态链接到MFC的应用程序使用。和规则DLL相比，有以下不同：

它没有一个从CWinApp派生的对象；
它必须有一个DllMain函数；
DllMain调用AfxInitExtensionModule函数，必须检查该函数的返回值，如果返回0，DllMmain也返回0；
如果它希望输出CRuntimeClass类型的对象或者资源(Resources)，则需要提供一个初始化函数来创建一个CDynLinkLibrary对象。并且，有必要把初始化函数输出。
使用扩展DLL的MFC应用程序必须有一个从CWinApp派生的类，而且，一般在InitInstance里调用扩展DLL的初始化函数。

为什么要这样做和具体的代码形式，将在后面9.4.2节说明。

MFC类库也是以DLL的形式提供的。通常所说的动态链接到MFC 的DLL，指的就是实现MFC核心功能的MFCXX.DLL或者MFCXXD.DLL（XX是版本号，XXD表示调试版）。至于提供OLE（MFCOXXD.DLL或者MFCOXX0.DLL）和NET（MFCNXXD.DLL或者MFCNXX.DLL）服务的DLL就是动态链接到MFC核心DLL的扩展DLL。

其实，MFCXX.DLL可以认为是扩展DLL的一个特例，因为它也具备扩展DLL的上述特点。

DLL的几点说明

DLL应用程序的入口点是DllMain。

对程序员来说，DLL应用程序的入口点是DllMain。

DllMain负责初始化(Initialization)和结束(Termination)工作，每当一个新的进程或者该进程的新的线程访问DLL时，或者访问DLL的每一个进程或者线程不再使用DLL或者结束时，都会调用DllMain。但是，使用TerminateProcess或TerminateThread结束进程或者线程，不会调用DllMain。

DllMain的函数原型符合DllEntryPoint的要求，有如下结构：

BOOL WINAPI DllMain (HANDLE hInst,

ULONG ul_reason_for_call,LPVOID lpReserved)

{

switch( ul_reason_for_call ) {

case DLL_PROCESS_ATTACH:

…

case DLL_THREAD_ATTACH:

…

case DLL_THREAD_DETACH:

…

case DLL_PROCESS_DETACH:

…

}

return TRUE;

}

其中：

参数1是模块句柄；

参数2是指调用DllMain的类别，四种取值：新的进程要访问DLL；新的线程要访问DLL；一个进程不再使用DLL(Detach from DLL)；一个线程不再使用DLL(Detach from DLL)。

参数3保留。

如果程序员不指定DllMain，则编译器使用它自己的DllMain，该函数仅仅返回TRUE。

规则DLL应用程序使用了MFC的DllMain，它将调用DLL程序的应用程序对象(从CWinApp派生)的InitInstance函数和ExitInstance函数。

扩展DLL必须实现自己的DllMain。
_DllMainCRTStartup

为了使用“C”运行库(CRT，C Run time Library)的DLL版本（多线程），一个DLL应用程序必须指定_DllMainCRTStartup为入口函数，DLL的初始化函数必须是DllMain。

_DllMainCRTStartup完成以下任务：当进程或线程捆绑(Attach)到DLL时为“C”运行时的数据(C Runtime Data)分配空间和初始化并且构造全局“C++”对象，当进程或者线程终止使用DLL(Detach)时，清理C Runtime Data并且销毁全局“C++”对象。它还调用DllMain和RawDllMain函数。

RawDllMain在DLL应用程序动态链接到MFC DLL时被需要，但它是静态的链接到DLL应用程序的。在讲述状态管理时解释其原因。
DLL的函数和数据

DLL的函数分为两类：输出函数和内部函数。输出函数可以被其他模块调用，内部函数在定义它们的DLL程序内部使用。

虽然DLL可以输出数据，但一般的DLL程序的数据仅供内部使用。
DLL程序和调用其输出函数的程序的关系

DLL模块被映射到调用它的进程的虚拟地址空间。

DLL使用的内存从调用进程的虚拟地址空间分配，只能被该进程的线程所访问。

DLL的句柄可以被调用进程使用；调用进程的句柄可以被DLL使用。

DLL使用调用进程的栈。

DLL定义的全局变量可以被调用进程访问；DLL可以访问调用进程的全局数据。使用同一DLL的每一个进程都有自己的DLL全局变量实例。如果多个线程并发访问同一变量，则需要使用同步机制；对一个DLL的变量，如果希望每个使用DLL的线程都有自己的值，则应该使用线程局部存储(TLS，Thread Local Strorage)。

输出函数的方法

传统的方法

在模块定义文件的EXPORT部分指定要输入的函数或者变量。语法格式如下：

entryname[=internalname] [@ordinal[NONAME]] [DATA] [PRIVATE]

其中：

entryname是输出的函数或者数据被引用的名称；

internalname同entryname;

@ordinal表示在输出表中的顺序号(index)；

NONAME仅仅在按顺序号输出时被使用（不使用entryname）；

DATA表示输出的是数据项，使用DLL输出数据的程序必须声明该数据项为_declspec(dllimport)。

上述各项中，只有entryname项是必须的，其他可以省略。

对于“C”函数来说，entryname可以等同于函数名；但是对“C++”函数（成员函数、非成员函数）来说，entryname是修饰名。可以从.map映像文件中得到要输出函数的修饰名，或者使用DUMPBIN /SYMBOLS得到，然后把它们写在.def文件的输出模块。DUMPBIN是VC提供的一个工具。

如果要输出一个“C++”类，则把要输出的数据和成员的修饰名都写入.def模块定义文件。
在命令行输出

对链接程序LINK指定/EXPORT命令行参数，输出有关函数。
使用MFC提供的修饰符号_declspec(dllexport)

在要输出的函数、类、数据的声明前加上_declspec(dllexport)的修饰符，表示输出。MFC提供了一些宏，就有这样的作用，如表7-2所示。

表7-2 MFC定义的输入输出修饰符

宏名称	宏内容
AFX_CLASS_IMPORT	__declspec(dllexport)
AFX_API_IMPORT	__declspec(dllexport)
AFX_DATA_IMPORT	__declspec(dllexport)
AFX_CLASS_EXPORT	__declspec(dllexport)
AFX_API_EXPORT	__declspec(dllexport)
AFX_DATA_EXPORT	__declspec(dllexport)
AFX_EXT_CLASS	#ifdef _AFXEXT AFX_CLASS_EXPORT #else AFX_CLASS_IMPORT
AFX_EXT_API	#ifdef _AFXEXT AFX_API_EXPORT #else AFX_API_IMPORT
AFX_EXT_DATA	#ifdef _AFXEXT AFX_DATA_EXPORT #else AFX_DATA_IMPORT
AFX_EXT_DATADEF

像AFX_EXT_CLASS这样的宏，如果用于DLL应用程序的实现中，则表示输出（因为_AFX_EXT被定义，通常是在编译器的标识参数中指定该选项/D_AFX_EXT）；如果用于使用DLL的应用程序中，则表示输入（_AFX_EXT没有定义）。

要输出整个的类，对类使用_declspec(_dllexpot)；要输出类的成员函数，则对该函数使用_declspec(_dllexport)。如：

class AFX_EXT_CLASS CTextDoc : public CDocument

{

…

}

extern “C” AFX_EXT_API void WINAPI InitMYDLL();

这几种方法中，最好采用第三种，方便好用；其次是第一种，如果按顺序号输出，调用效率会高些；最次是第二种。

在“C++”下定义“C”函数，需要加extern “C”关键词。输出的“C”函数可以从“C”代码里调用。

MFC的进程和线程
1. Win32的进程和线程概念

进程是一个可执行的程序，由私有虚拟地址空间、代码、数据和其他操作系统资源（如进程创建的文件、管道、同步对象等）组成。一个应用程序可以有一个或多个进程，一个进程可以有一个或多个线程，其中一个是主线程。

线程是操作系统分时调度分配CPU时间的基本实体。一个线程可以执行程序的任意部分的代码，即使这部分代码被另一个线程并发地执行；一个进程的所有线程共享它的虚拟地址空间、全局变量和操作系统资源。

之所以有线程这个概念，是因为以线程而不是进程为调度对象效率更高：

由于创建新进程必须加载代码，而线程要执行的代码已经被映射到进程的地址空间，所以创建、执行线程的速度比进程更快。
一个进程的所有线程共享进程的地址空间和全局变量，所以简化了线程之间的通讯。

Win32的进程处理简介

因为MFC没有提供类处理进程，所以直接使用了Win32 API函数。
1. 进程的创建
  
  调用CreateProcess函数创建新的进程，运行指定的程序。CreateProcess的原型如下：
  
  BOOL CreateProcess(
  
  LPCTSTR lpApplicationName,
  
  LPTSTR lpCommandLine,
  
  LPSECURITY_ATTRIBUTES lpProcessAttributes,
  
  LPSECURITY_ATTRIBUTES lpThreadAttributes,
  
  BOOL bInheritHandles,
  
  DWORD dwCreationFlags,
  
  LPVOID lpEnvironment,
  
  LPCTSTR lpCurrentDirectory,
  
  LPSTARTUPINFO lpStartupInfo,
  
  LPPROCESS_INFORMATION lpProcessInformation
  
  );
  
  其中：
  
  lpApplicationName指向包含了要运行模块名字的字符串。
  
  lpCommandLine指向命令行字符串。
  
  lpProcessAttributes描述进程的安全性属性，NT下有用。
  
  lpThreadAttributes描述进程初始线程（主线程）的安全性属性，NT下有用。
  
  bInHeritHandles表示子进程（被创建的进程）是否可以继承父进程的句柄。可以继承的句柄有线程句柄、有名或无名管道、互斥对象、事件、信号量、映像文件、普通文件和通讯端口等；还有一些句柄不能被继承，如内存句柄、DLL实例句柄、GDI句柄、URER句柄等等。
  
  子进程继承的句柄由父进程通过命令行方式或者进程间通讯（IPC）方式由父进程传递给它。
  
  dwCreationFlags表示创建进程的优先级类别和进程的类型。创建进程的类型分控制台进程、调试进程等；优先级类别用来控制进程的优先级别，分Idle、Normal、High、Real_time四个类别。
  
  lpEnviroment指向环境变量块，环境变量可以被子进程继承。
  
  lpCurrentDirectory指向表示当前目录的字符串，当前目录可以继承。
  
  lpStartupInfo指向StartupInfo结构，控制进程的主窗口的出现方式。
  
  lpProcessInformation指向PROCESS_INFORMATION结构，用来存储返回的进程信息。
  
  从其参数可以看出创建一个新的进程需要指定什么信息。
  
  从上面的解释可以看出，一个进程包含了很多信息。若进程创建成功的话，返回一个进程信息结构类型的指针。进程信息结构如下：
  
  typedef struct _PROCESS_INFORMATION {
  
  HANDLE hProcess;
  
  HANDLE hThread;
  
  DWORD dwProcessId;
  
  DWORD dwThreadId;
  
  }PROCESS_INFORMATION;
  
  进程信息结构包括进程句柄，主线程句柄，进程ID，主线程ID。
2. 进程的终止

进程在以下情况下终止：

调用ExitProcess结束进程；
进程的主线程返回，隐含地调用ExitProcess导致进程结束；
进程的最后一个线程终止；
调用TerminateProcess终止进程。
当要结束一个GDI进程时，发送WM_QUIT消息给主窗口，当然也可以从它的任一线程调用ExitProcess。

Win32的线程
1. 线程的创建

使用CreateThread函数创建线程，CreateThread的原型如下：

HANDLE CreateThread(

LPSECURITY_ATTRIBUTES lpThreadAttributes,

DWORD dwStackSize,

LPTHREAD_START_ROUTINE lpStartAddress,

LPVOID lpParameter,

DWORD dwCreationFlags, // creation flags

LPDWORD lpThreadId

);

其中：

lpThreadAttributes表示创建线程的安全属性，NT下有用。

dwStackSize指定线程栈的尺寸，如果为0则与进程主线程栈相同。

lpStartAddress指定线程开始运行的地址。

lpParameter表示传递给线程的32位的参数。

dwCreateFlages表示是否创建后挂起线程(取值CREATE_SUSPEND)，挂起后调用ResumeThread继续执行。

lpThreadId用来存放返回的线程ID。

线程的优先级别

进程的每个优先级类包含了五个线程的优先级水平。在进程的优先级类确定之后，可以改变线程的优先级水平。用SetPriorityClass设置进程优先级类，用SetThreadPriority设置线程优先级水平。

Normal级的线程可以被除了Idle级以外的任意线程抢占。

线程的终止

以下情况终止一个线程：

调用了ExitThread函数；
线程函数返回：主线程返回导致ExitProcess被调用，其他线程返回导致ExitThread被调用；
调用ExitProcess导致进程的所有线程终止；
调用TerminateThread终止一个线程；
调用TerminateProcess终止一个进程时，导致其所有线程的终止。

当用TerminateProcess或者TerminateThread终止进程或线程时，DLL的入口函数DllMain不会被执行（如果有DLL的话）。

线程局部存储

如果希望每个线程都可以有线程局部(Thread local)的静态存储数据，可以使用TLS线程局部存储技术。TLS为进程分配一个TLS索引，进程的每个线程通过这个索引存取自己的数据变量的拷贝。

TLS对DLL是非常有用的。当一个新的进程使用DLL时，在DLL入口函数DllMain中使用TlsAlloc分配TLS索引，TLS索引就作为进程私有的全局变量被保存；以后，当该进程的新的线程使用DLL时(Attahced to DLL），DllMain给它分配动态内存并且使用TlsSetValue把线程私有的数据按索引保存。DLL函数可以使用TlsGetValue按索引读取调用线程的私有数据。

TLS函数如下：

DWORD TlsAlloc()

在进程或DLL初始化时调用，并且把返回值（索引值）作为全局变量保存。

BOOL TlsSetValue(

DWORD dwTlsIndex, //TLS index to set value for

LPVOID lpTlsValue //value to be stored

);

其中：

dwTlsIndex是TlsAlloc分配的索引。

lpTlsValue是线程在TLS槽中存放的数据指针，指针指向线程要保存的数据。

线程首先分配动态内存并保存数据到此内存中，然后调用TlsSetValue保存内存指针到TLS槽。

LPVOID TlsGetValue(

DWORD dwTlsIndex // TLS index to retrieve value for

);

其中：

dwTlsIndex是TlsAlloc分配的索引。

当要存取保存的数据时，使用索引得到数据指针。

BOOL TlsFree(

DWORD dwTlsIndex // TLS index to free

);

其中：

dwTlsIndex是TlsAlloc分配的索引。

当每一个线程都不再使用局部存储数据时，线程释放它分配的动态内存。在TLS索引不再需要时，使用TlsFree释放索引。

线程同步

同步可以保证在一个时间内只有一个线程对某个资源（如操作系统资源等共享资源）有控制权。共享资源包括全局变量、公共数据成员或者句柄等。同步还可以使得有关联交互作用的代码按一定的顺序执行。

Win32提供了一组对象用来实现多线程的同步。

这些对象有两种状态：获得信号(Signaled)或者没有或则信号(Not signaled)。线程通过Win32 API提供的同步等待函数（Wait functions）来使用同步对象。一个同步对象在同步等待函数调用时被指定，调用同步函数地线程被阻塞(blocked)，直到同步对象获得信号。被阻塞的线程不占用CPU时间。
1. 同步对象

同步对象有：Critical_section（关键段），Event（事件），Mutex（互斥对象），Semaphores（信号量）。

下面，解释怎么使用这些同步对象。

关键段对象：

首先，定义一个关键段对象cs：

CRITICAL_SECTION cs;

然后，初始化该对象。初始化时把对象设置为NOT_SINGALED，表示允许线程使用资源：

InitializeCriticalSection(&cs);

如果一段程序代码需要对某个资源进行同步保护，则这是一段关键段代码。在进入该关键段代码前调用EnterCriticalSection函数，这样，其他线程都不能执行该段代码，若它们试图执行就会被阻塞。

完成关键段的执行之后，调用LeaveCriticalSection函数，其他的线程就可以继续执行该段代码。如果该函数不被调用，则其他线程将无限期的等待。
事件对象

首先，调用CreateEvent函数创建一个事件对象，该函数返回一个事件句柄。然后，可以设置（SetEvent）或者复位(ResetEvent)一个事件对象，也可以发一个事件脉冲（PlusEvent），即设置一个事件对象，然后复位它。复位有两种形式：自动复位和人工复位。在创建事件对象时指定复位形式。。

自动复位：当对象获得信号后，就释放下一个可用线程（优先级别最高的线程；如果优先级别相同，则等待队列中的第一个线程被释放）。

人工复位：当对象获得信号后，就释放所有可利用线程。

最后，使用CloseHandle销毁创建的事件对象。
互斥对象

首先，调用CreateMutex创建互斥对象；然后，调用等待函数，可以的话利用关键资源；最后，调用RealseMutex释放互斥对象。

互斥对象可以在进程间使用，但关键段对象只能用于同一进程的线程之间。
信号量对象

在Win32中，信号量的数值变为0时给以信号。在有多个资源需要管理时可以使用信号量对象。

首先，调用CreateSemaphore创建一个信号量；然后，调用等待函数，如果允许的话，则利用关键资源；最后，调用RealeaseSemaphore释放信号量对象。
此外，还有其他句柄可以用来同步线程：

文件句柄（FILE HANDLES）

命名管道句柄（NAMED PIPE HANDELS）

控制台输入缓冲区句柄（CONSOLE INPUT BUFFER HANDLES）

通讯设备句柄（COMMUNICTION DEVICE HANDLES）

进程句柄（PROCESS HANDLES）

线程句柄（THREAD HANDLES）

例如，当一个进程或线程结束时，进程或线程句柄获得信号，等待该进程或者线程结束的线程被释放。

等待函数

Win32提供了一组等待函数用来让一个线程阻塞自己的执行。等待函数分三类：

等待单个对象的(FOR SINGLE OBJECT):

这类函数包括：

SignalObjectAndWait

WaitForSingleObject

WaitForSingleObjectEx

函数参数包括同步对象的句柄和等待时间等。

在以下情况下等待函数返回：

同步对象获得信号时返回；

等待时间达到了返回：如果等待时间不限制(Infinite)，则只有同步对象获得信号才返回；如果等待时间为0，则在测试了同步对象的状态之后马上返回。
等待多个对象的(FOR MULTIPLE OBJECTS)

这类函数包括：

WaitForMultipleObjects

WaitForMultipleObjectsEx

MsgWaitForMultipleObjects

MsgWaitForMultipleObjectsEx

函数参数包括同步对象的句柄，等待时间，是等待一个还是多个同步对象等等。

在以下情况下等待函数返回：

一个或全部同步对象获得信号时返回（在参数中指定是等待一个或多个同步对象）；

等待时间达到了返回：如果等待时间不限制(Infinite)，则只有同步对象获得信号才返回；如果等待时间为0，则在测试了同步对象的状态之后马上返回。
可以发出提示的函数(ALTERABLE)

这类函数包括：

MsgWaitForMultipleObjectsEx

SignalObjectAndWait

WaitForMultipleObjectsEx

WaitForSingleObjectEx

这些函数主要用于重叠(Overlapped)的I/O（异步I/O）。

MFC的线程处理

在Win32 API的基础之上，MFC提供了处理线程的类和函数。处理线程的类是CWinThread，函数是AfxBeginThread、AfxEndThread等。

表5-6解释了CWinThread的成员变量和函数。

CWinThread是MFC线程类，它的成员变量m_hThread和m_hThreadID是对应的Win32线程句柄和线程ID。

MFC明确区分两种线程：用户界面线程(User interface thread)和工作者线程(Worker thread)。用户界面线程一般用于处理用户输入并对用户产生的事件和消息作出应答。工作者线程用于完成不要求用户输入的任务，如耗时计算。

Win32 API并不区分线程类型，它只需要知道线程的开始地址以便它开始执行线程。MFC为用户界面线程特别地提供消息泵来处理用户界面的事件。CWinApp对象是用户界面线程对象的一个例子，CWinApp从类CWinThread派生并处理用户产生的事件和消息。
1. 创建用户界面线程

通过以下步骤创建一个用户界面线程：

从CWinThread派生一个有动态创建能力的类。使用DECLARE_DYNCREATE和IMPLEMENT_DYNCREATE宏来支持动态创建。
覆盖CWinThread的一些虚拟函数，可以覆盖的函数见表5-4关于CWinThread的部分。其中，函数InitInstance是必须覆盖的，ExitInstance通常是要覆盖的。
使用AfxBeginThread创建MFC线程对象和Win32线程对象。如果创建线程时没有指定CREATE_SUSPENDED，则开始执行线程。
如果创建线程是指定了CREATE_SUSPENDED，则在适当的地方调用函数ResumeThread开始执行线程。

创建工作者线程

程序员不必从CWinThread派生新的线程类，只需要提供一个控制函数,由线程启动后执行该函数。

然后，使用AfxBeginThread创建MFC线程对象和Win32线程对象。如果创建线程时没有指定CREATE_SUSPENDED（创建后挂起），则创建的新线程开始执行。

如果创建线程是指定了CREATE_SUSPENDED，则在适当的地方调用函数ResumeThread开始执行线程。

虽然程序员没有从CWinThread派生类，但是MFC给工作者线程提供了缺省的CWinThread对象。
AfxBeginThread

用户界面线程和工作者线程都是由AfxBeginThread创建的。现在，考察该函数：MFC提供了两个重载版的AfxBeginThread，一个用于用户界面线程，另一个用于工作者线程，分别有如下的原型和过程：

用户界面线程的AfxBeginThread

用户界面线程的AfxBeginThread的原型如下：

CWinThread* AFXAPI AfxBeginThread(

CRuntimeClass* pThreadClass,

int nPriority,

UINT nStackSize,

DWORD dwCreateFlags,

LPSECURITY_ATTRIBUTES lpSecurityAttrs)

其中：

参数1是从CWinThread派生的RUNTIME_CLASS类；

参数2指定线程优先级，如果为0，则与创建该线程的线程相同；

参数3指定线程的堆栈大小，如果为0，则与创建该线程的线程相同；

参数4是一个创建标识，如果是CREATE_SUSPENDED，则在悬挂状态创建线程，在线程创建后线程挂起，否则线程在创建后开始线程的执行。

参数5表示线程的安全属性，NT下有用。
工作者线程的AfxBeginThread

工作者线程的AfxBeginThread的原型如下：

CWinThread* AFXAPI AfxBeginThread(

AFX_THREADPROC pfnThreadProc,

LPVOID pParam,

int nPriority,

UINT nStackSize,

DWORD dwCreateFlags,

LPSECURITY_ATTRIBUTES lpSecurityAttrs)

其中：

参数1指定控制函数的地址；

参数2指定传递给控制函数的参数；

参数3、4、5分别指定线程的优先级、堆栈大小、创建标识、安全属性，含义同用户界面线程。
AfxBeginThread创建线程的流程

不论哪个AfxBeginThread，首先都是创建MFC线程对象，然后创建Win32线程对象。在创建MFC线程对象时，用户界面线程和工作者线程的创建分别调用了不同的构造函数。用户界面线程是从CWinThread派生的，所以，要先调用派生类的缺省构造函数，然后调用CWinThread的缺省构造函数。图8-1中两个构造函数所调用的CommonConstruct是MFC内部使用的成员函数。

CreateThread和_AfxThreadEntry

MFC使用CWinThread::CreateThread创建线程，不论对工作者线程或用户界面线程，都指定线程的入口函数是_AfxThreadEntry。_AfxThreadEntry调用AfxInitThread初始化线程。

CreateThread和_AfxThreadEntry在线程的创建过程中使用同步手段交互等待、执行。CreateThread由创建线程执行，_AfxThreadEntry由被创建的线程执行，两者通过两个事件对象(hEvent和hEvent2)同步：

在创建了新线程之后，创建线程将在hEvent事件上无限等待直到新线程给出创建结果；新线程在创建成功或者失败之后，触发事件hEvent让父线程运行，并且在hEven2上无限等待直到父线程退出CreateThread函数；父线程(创建线程)因为hEvent的置位结束等待，继续执行，退出CreateThread之前触发hEvent2事件；新线程（子线程）因为hEvent2的置位结束等待，开始执行控制函数（工作者线程）或者进入消息循环（用户界面线程）。

MFC在线程创建中使用了如下数据结构：

struct _AFX_THREAD_STARTUP

{

//传递给线程启动的参数（IN）

_AFX_THREAD_STATE* pThreadState;//父线程的线程状态

CWinThread* pThread; //新创建的MFC线程对象

DWORD dwCreateFlags; //线程创建标识

_PNH pfnNewHandler; //新线程的句柄

HANDLE hEvent; //同步事件，线程创建成功或失败后置位

HANDLE hEvent2; //同步事件，新线程恢复执行后置位

//返回给创建线程的参数，在新线程恢复执行后赋值

BOOL bError; //如果创建发生错误，TRUE

};

该结构作为线程开始函数的参数被传递给_beginthreadex函数来创建和启动线程。_beginthreadex函数是“C”的线程创建函数，具有如下原型：

unsigned long _beginthreadex(

void *security,

unsigned stack_size,

unsigned ( __stdcall *start_address )( void * ),

void *arglist,

unsigned initflag,

unsigned *thrdaddr );

图8-2描述了上述过程。图中表示，_AfxThreadEntry在启动线程时，将创建本线程的线程状态，并且继承父线程的模块状态。关于MFC状态，见第9章。

　

　
线程的结束

从图8-2可以看出，AfxEndThread用来结束调用它的线程：它将清理本线程创建的MFC对象和释放线程局部存储分配的内存空间；调用CWinThread的虚拟函数Delete；调用“C”的结束线程函数_endthreadex释放分配给线程的资源，但是不关闭线程句柄。

CWinThread::Delete的缺省实现是：如果本线程的成员函数m_bDelete为TRUE，则调用“C”运算符号delete销毁MFC线程对象自身（delete this），这将导致线程对象的析构函数被调用。若析构函数检测线程句柄非空则调用CloseHandle关闭它。

通常，让m_bDelete为TRUE以便自动地销毁线程对象，释放内存空间（MFC内存对象在堆中分配）。但是，有时候，在线程结束之后（Win32线程已经不存在）保留MFC线程对象是有用的，当然程序员自己最后要记得销毁该线程对象。
实现线程的消息循环

在MFC中，消息循环是由线程完成的。一般地，可以使用MFC缺省的消息循环（即使用函数CWindThrad::Run），但是，有些时候需要程序员自己实现一个线程的消息循环，比如在用户界面线程进行一个长时间计算处理或者等待另一个线程时。一般有如下形式：

while ( bDoingBackgroundProcessing)

{

MSG msg;

while ( ::PeekMessage( &msg, NULL,0, 0, PM_NOREMOVE ) )

{

if ( !PumpMessage( ) )

{

bDoingBackgroundProcessing = FALSE;

::PostQuitMessage( );

break;

}

// let MFC do its idle processing

LONG lIdle = 0;

while ( AfxGetApp()->OnIdle(lIdle++ ) );

// Perform some background processing here

// using another call to OnIdle

}

该段代码的解释参见图5-3对线程的Run函数的图解。

程序员实现线程的消息循环有两个好处，一是顾及了MFC的Idle处理机制；二是在长时间的处理中可以响应用户产生的事件或者消息。

在同步对象上等待其他线程时，也可以使用同样的方式，只要把条件

bDoingBackgroundProcessing

换成如下形式：

WaitForSingObject(hHandleOfEvent,0) == WAIT_TIMEOUT

即可。

MFC处理线程和进程时还引入了一个重要的概念：状态，如线程状态(Thread State)、进程状态(Process State)、模块状态(Module State)等。由于这个概念在MFC中占有重要地位，涉及的内容比较多，所以专门在下一章来讲述它。

MFC的状态

MFC定义了多种状态信息，这里要介绍的是模块状态、进程状态、线程状态。这些状态可以组合在一起，例如MFC句柄映射就是模块和线程局部有效的，属于模块-线程状态的一部分。
1. 模块状态
  
  这里模块的含义是：一个可执行的程序或者一个使用MFC DLL的DLL，比如一个OLE控件就是一个模块。
  
  一个应用程序的每一个模块都有一个状态，模块状态包括这样一些信息：用来加载资源的 Windows实例句柄、指向当前CWinApp或者CWinThread对象的指针、OLE模块的引用计数、Windows对象与相应的MFC对象之间的映射。只有单一模块的应用程序的状态如图9-1所示。
  
  m_pModuleState 指针是线程对象的成员变量，指向当前模块状态信息（一个AFX_MODULE_STATE结构变量）。当程序运行进入某个特定的模块时，必须保证当前使用的模块状态是有效的模块状态──是这个特定模块的模块状态。所以，每个线程对象都有一个指针指向有效的模块状态，每当进入某个模块时都要使它指向有效模块状态，这对维护应用程序全局状态和每个模块状态的完整性来说是非常重要的。为了作到这一点，每个模块的所有入口点有责任实现模块状态的切换。模块的入口点包括：DLL的输出函数；OLE/COM界面的成员函数；窗口过程。
  
  在讲述窗口过程和动态链接到MFC DLL的规则DLL时，曾提到了语句AFX_MANAGE_STATE(AfxGetStaticModuleState( ))，它就是用来在入口点切换模块状态的。其实现机制将在后面9.4.1节讲解。
  
  多个模块状态之间切换的示意图如图9-2所示。
  
  图9-2中，m_pModuleState总是指向当前模块的状态。
2. 模块、进程和线程状态的数据结构
  
  MFC定义了一系列类或者结构，通过它们来实现状态信息的管理。这一节将描述它们的关系，并逐一解释它们的数据结构、成员函数等。
  1. 层次关系
    
    图9-3显示了线程状态、模块状态、线程-模块状态等几个类的层次关系：
    
    线程状态用类_AFX_THREAD_STATE描述，模块状态用类AFX_MODULE_STATE描述，模块-线程状态用类AFX_MODULE_THREAD_STATE描述。这些类从类CNoTrackObject派生。进程状态类用_AFX_BASE_MODULE_STATE描述，从模块状态类AFX_MODULE_STATE派生。进程状态是了一个可以独立执行的MFC应用程序的模块状态。还有其他状态如DLL的模块状态等也从模块状态类_AFX_MODULE_STATE派生。
    
    图9-4显示了这几个类的交互关系。
    
    从图9-4可以看出：首先，每个线程有一个线程状态，线程状态的指针m_pModuleState和m_pPreModuleState分别指向线程当前运行模块的状态或前一运行模块的状态；其次，每一个模块状态都有一个线程局部的变量用来存储模块-线程状态。
    
    下面各小节列出状态信息管理所涉及的各个类的定义。
  2. CNoTrackObject类
    
    在图9-3中， CnoTrackObject是根类，所有状态类都是从它这里派生的，其定义如下：
    
    class CNoTrackObject
    
    {
    
    public:
    
    void* PASCAL operator new(size_t nSize);
    
    void PASCAL operator delete(void*);
    
    #if defined(_DEBUG) && !defined(_AFX_NO_DEBUG_CRT)
    
    void* PASCAL operator new(size_t nSize, LPCSTR, int);
    
    #endif
    
    virtual ~CNoTrackObject() { }
    
    };
    
    该类的析构函数是虚拟函数；而且，CNoTrackObject重载new操作符用来分配内存，重载delete操作符号用来释放内存，内部通过LocalAlloc/LocalFree提供了一个低层内存分配器（Low_level alloctor)。
  3. AFX_MODULE_STATE类
    
    AFX_MODULE_STATE类的定义如下：
    
    // AFX_MODULE_STATE (global data for a module)
    
    class AFX_MODULE_STATE : public CNoTrackObject
    
    {
    
    public:
    
    #ifdef _AFXDLL
    
    AFX_MODULE_STATE(BOOL bDLL,WNDPROC pfnAfxWndProc,
    
    DWORD dwVersion);
    
    AFX_MODULE_STATE(BOOL bDLL, WNDPROC pfnAfxWndProc,
    
    DWORD dwVersion,BOOL bSystem);
    
    #else
    
    AFX_MODULE_STATE(BOOL bDLL);
    
    #endif
    
    ~AFX_MODULE_STATE();
    
    CWinApp* m_pCurrentWinApp;
    
    HINSTANCE m_hCurrentInstanceHandle;
    
    HINSTANCE m_hCurrentResourceHandle;
    
    LPCTSTR m_lpszCurrentAppName;
    
    BYTE m_bDLL;// TRUE if module is a DLL, FALSE if it is an EXE
    
    //TRUE if module is a “system” module, FALSE if not
    
    BYTE m_bSystem;
    
    BYTE m_bReserved[2]; // padding
    
    //Runtime class data:
    
    #ifdef _AFXDLL
    
    CRuntimeClass* m_pClassInit;
    
    #endif
    
    CTypedSimpleList<CRuntimeClass*> m_classList;
    
    // OLE object factories
    
    #ifndef _AFX_NO_OLE_SUPPORT
    
    #ifdef _AFXDLL
    
    COleObjectFactory* m_pFactoryInit;
    
    #endif
    
    CTypedSimpleList<COleObjectFactory*> m_factoryList;
    
    #endif
    
    // number of locked OLE objects
    
    long m_nObjectCount;
    
    BOOL m_bUserCtrl;
    
    // AfxRegisterClass and AfxRegisterWndClass data
    
    TCHAR m_szUnregisterList[4096];
    
    #ifdef _AFXDLL
    
    WNDPROC m_pfnAfxWndProc;
    
    DWORD m_dwVersion; // version that module linked against
    
    #endif
    
    // variables related to a given process in a module
    
    // (used to be AFX_MODULE_PROCESS_STATE)
    
    #ifdef _AFX_OLD_EXCEPTIONS
    
    // exceptions
    
    AFX_TERM_PROC m_pfnTerminate;
    
    #endif
    
    void (PASCAL *m_pfnFilterToolTipMessage)(MSG*, CWnd*);
    
    #ifdef _AFXDLL
    
    // CDynLinkLibrary objects (for resource chain)
    
    CTypedSimpleList<CDynLinkLibrary*> m_libraryList;
    
    // special case for MFCxxLOC.DLL (localized MFC resources)
    
    HINSTANCE m_appLangDLL;
    
    #endif
    
    #ifndef _AFX_NO_OCC_SUPPORT
    
    // OLE control container manager
    
    COccManager* m_pOccManager;
    
    // locked OLE controls
    
    CTypedSimpleList<COleControlLock*> m_lockList;
    
    #endif
    
    #ifndef _AFX_NO_DAO_SUPPORT
    
    _AFX_DAO_STATE* m_pDaoState;
    
    #endif
    
    #ifndef _AFX_NO_OLE_SUPPORT
    
    // Type library caches
    
    CTypeLibCache m_typeLibCache;
    
    CMapPtrToPtr* m_pTypeLibCacheMap;
    
    #endif
    
    // define thread local portions of module state
    
    THREAD_LOCAL(AFX_MODULE_THREAD_STATE, m_thread)
    
    };
    
    从上面的定义可以看出，模块状态信息分为如下几类：
    
    模块信息，资源信息，对动态链接到MFC DLL的支持信息，对扩展DLL的支持信息，对DAO的支持信息，对OLE的支持信息，模块-线程状态信息。
    
    模块信息包括实例句柄、资源句柄、应用程序名称、指向应用程序的指针、是否为DLL模块、模块注册的窗口类，等等。其中，成员变量m_fRegisteredClasses、m_szUnregisterList曾经在讨论MFC的窗口注册时提到过它们的用处。
    
    在“#ifdef _AFXDLL…#endif”条件编译范围内的是支持MFC DLL的数据；
    
    在“#ifndef _AFX_NO_OLE_SUPPOR…#endif”条件编译范围内的是支持OLE的数据；
    
    在“#ifndef _AFX_NO_OCC_SUPPOR…#endif”条件编译范围内的是支持OLE控件的数据；
    
    在“#ifndef _AFX_NO_DAO_SUPPORT”条件编译范围内的是支持DAO的数据。
    
    THREAD_LOCAL宏定义了线程私有的模块-线程类型的变量m_thread。
  4. _AFX_BASE_MODULE_STATE
    
    该类定义如下：
    
    class _AFX_BASE_MODULE_STATE : public AFX_MODULE_STATE
    
    {
    
    public:
    
    #ifdef _AFXDLL
    
    _AFX_BASE_MODULE_STATE() : AFX_MODULE_STATE(TRUE,
    
    AfxWndProcBase, _MFC_VER)
    
    #else
    
    _AFX_BASE_MODULE_STATE() : AFX_MODULE_STATE(TRUE)
    
    #endif
    
    { }
    
    };
    
    由定义可见，该类没有在_AFX_MODULE_STATE类的基础上增加数据。它类用来实现一个MFC应用程序模块的状态信息。
  5. _AFX_THREAD_STATE
    
    该类定义如下：
    
    class _AFX_THREAD_STATE : public CNoTrackObject
    
    {
    
    public:
    
    _AFX_THREAD_STATE();
    
    virtual ~_AFX_THREAD_STATE();
    
    // override for m_pModuleState in _AFX_APP_STATE
    
    AFX_MODULE_STATE* m_pModuleState;
    
    AFX_MODULE_STATE* m_pPrevModuleState;
    
    // memory safety pool for temp maps
    
    void* m_pSafetyPoolBuffer; // current buffer
    
    // thread local exception context
    
    AFX_EXCEPTION_CONTEXT m_exceptionContext;
    
    // CWnd create, gray dialog hook, and other hook data
    
    CWnd* m_pWndInit;
    
    CWnd* m_pAlternateWndInit; // special case commdlg hooking
    
    DWORD m_dwPropStyle;
    
    DWORD m_dwPropExStyle;
    
    HWND m_hWndInit;
    
    BOOL m_bDlgCreate;
    
    HHOOK m_hHookOldCbtFilter;
    
    HHOOK m_hHookOldMsgFilter;
    
    // other CWnd modal data
    
    MSG m_lastSentMsg; // see CWnd::WindowProc
    
    HWND m_hTrackingWindow; // see CWnd::TrackPopupMenu
    
    HMENU m_hTrackingMenu;
    
    TCHAR m_szTempClassName[96]; // see AfxRegisterWndClass
    
    HWND m_hLockoutNotifyWindow; // see CWnd::OnCommand
    
    BOOL m_bInMsgFilter;
    
    // other framework modal data
    
    CView* m_pRoutingView; // see CCmdTarget::GetRoutingView
    
    CFrameWnd*m_pRoutingFrame;//see CmdTarget::GetRoutingFrame
    
    // MFC/DB thread-local data
    
    BOOL m_bWaitForDataSource;
    
    // common controls thread state
    
    CToolTipCtrl* m_pToolTip;
    
    CWnd* m_pLastHit; // last window to own tooltip
    
    int m_nLastHit; // last hittest code
    
    TOOLINFO m_lastInfo; // last TOOLINFO structure
    
    int m_nLastStatus; // last flyby status message
    
    CControlBar* m_pLastStatus; // last flyby status control bar
    
    // OLE control thread-local data
    
    CWnd* m_pWndPark; // “parking space” window
    
    long m_nCtrlRef; // reference count on parking window
    
    BOOL m_bNeedTerm; // TRUE if OleUninitialize needs to be called
    
    };
    
    从定义可以看出，线程状态的成员数据分如下几类：
    
    指向模块状态信息的指针，支持本线程的窗口创建的变量，MFC命令和消息处理用到的信息，处理工具条提示信息(tooltip)的结构，和处理OLE相关的变量，等等。
  6. AFX_MODULE_THREAD_STATE
  该类定义如下：
  
  // AFX_MODULE_THREAD_STATE (local to thread *and* module)
  
  class AFX_MODULE_THREAD_STATE : public CNoTrackObject
  
  {
  
  public:
  
  AFX_MODULE_THREAD_STATE();
  
  virtual ~AFX_MODULE_THREAD_STATE();
  
  // current CWinThread pointer
  
  CWinThread* m_pCurrentWinThread;
  
  // list of CFrameWnd objects for thread
  
  CTypedSimpleList<CFrameWnd*> m_frameList;
  
  // temporary/permanent map state
  
  DWORD m_nTempMapLock; // if not 0, temp maps locked
  
  CHandleMap* m_pmapHWND;
  
  CHandleMap* m_pmapHMENU;
  
  CHandleMap* m_pmapHDC;
  
  CHandleMap* m_pmapHGDIOBJ;
  
  CHandleMap* m_pmapHimageLIST;
  
  // thread-local MFC new handler (separate from C-runtime)
  
  _PNH m_pfnNewHandler;
  
  #ifndef _AFX_NO_SOCKET_SUPPORT
  
  // WinSock specific thread state
  
  HWND m_hSocketWindow;
  
  CMapPtrToPtr m_mapSocketHandle;
  
  CMapPtrToPtr m_mapDeadSockets;
  
  CPtrList m_listSocketNotifications;
  
  #endif
  
  };
  
  模块-线程状态的数据成员主要有：
  
  指向当前线程对象(CWinThread对象)的指针m_pCurrentWinThread；
  
  当前线程的框架窗口对象(CFrameWnd对象)列表m_frameList（边框窗口在创建时（见图5-8）把自身添加到m-frameList中，销毁时则删除掉，通过列表m_frameList可以遍历模块所有的边框窗口）；
  
  new操作的例外处理函数m_pfnNewHandler；
  
  临时映射锁定标识m_nTempMapLock，防止并发修改临时映射。
  
  系列Windows对象-MFC对象的映射，如m_pmapHWND等。
  
  这些数据成员都是线程和模块私有的。
  
  下一节讨论MFC如何通过上述这些类来实现其状态的管理。
3. 线程局部存储机制和状态的实现
  
  MFC实现线程、模块或者线程-模块私有状态的基础是MFC的线程局部存储机制。MFC定义了CThreadSlotData类型的全局变量_afxThreadData来为进程的线程分配线程局部存储空间：
  
  CThreadSlotData* _afxThreadData;
  
  在此基础上，MFC定义了变量_afxThreadState来管理线程状态，定义了变量_afxBaseModuleState来管理进程状态。
  
  THREAD_LOCAL(_AFX_THREAD_STATE, _afxThreadState)
  
  PROCESS_LOCAL(_AFX_BASE_MODULE_STATE, _afxBaseModuleState)
  
  对于每个THREAD_LOCAL宏定义的变量，进程的每个线程都有自己独立的拷贝，这个变量在不同的线程里头可以有不同的取值。
  
  对于每个PROCESS_LOCAL宏定义的变量，每个进程都有自己独立的拷贝，这个变量在不同的进程里头可以有不同的取值。
  
  分别解释这三个变量。
  1. CThreadSlotData和_afxThreadData
    1. CThreadSlotData的定义
      
      以Win32线程局部存储机制为基础，MFC设计了类CThreadSlotData来提供管理线程局部存储的功能，MFC应用程序使用该类的对象──全局变量_afxThreadData来管理本进程的线程局部存储。CThreadSlotData类的定义如下：
      
      class CThreadSlotData
      
      {
      
      public:
      
      CThreadSlotData();
      
      //Operations
      
      int AllocSlot();
      
      void FreeSlot(int nSlot);
      
      void* GetValue(int nSlot);
      
      void SetValue(int nSlot, void* pValue);
      
      // delete all values in process/thread
      
      void DeleteValues(HINSTANCE hInst, BOOL bAll = FALSE);
      
      // assign instance handle to just constructed slots
      
      void AssignInstance(HINSTANCE hInst);
      
      // Implementation
      
      DWORD m_tlsIndex;// used to access system thread-local storage
      
      int m_nAlloc; // number of slots allocated (in UINTs)
      
      int m_nRover; // (optimization) for quick finding of free slots
      
      int m_nMax; // size of slot table below (in bits)
      
      CSlotData* m_pSlotData; // state of each slot (allocated or not)
      
      //list of CThreadData structures
      
      CTypedSimpleList<CThreadData*> m_list;
      
      CRITICAL_SECTION m_sect;
      
      // special version for threads only!
      
      void* GetThreadValue(int nSlot);
      
      void* PASCAL operator new(size_t, void* p){ return p; }
      
      void DeleteValues(CThreadData* pData, HINSTANCE hInst);
      
      ~CThreadSlotData();
      
      };
      
      通过TLS索引m_tlsIndex，CThreadSlotData对象（_afxThreadData）为每一个线程分配一个线程私有的存储空间并管理该空间。它把这个空间划分为若干个槽，每个槽放一个线程私有的数据指针，这样每个线程就可以存放任意个线程私有的数据指针。
    2. CThreadSlotData的一些数据成员
      
      在CThreadSlotData类的定义中所涉及的类或者结构定义如下：
      
      （1）m_sect
      
      m_sect是一个关键段变量，在_afxThreadData创建时初始化。因为_afxThreadData是一个全局变量，所以必须通过m_sect来同步多个线程对该变量的并发访问。
      
      （2）m_nAlloc和m_pSlotData
      
      m_nAlloc表示已经分配槽的数目，它代表了线程局部变量的个数。每一个线程局部变量都对应一个槽，每个槽对应一个线程局部变量。槽使用CSlotData类来管理。
      
      CSlotData的定义如下：
      
      struct CSlotData{
      
      DWORD dwFlags; // slot flags (allocated/not allocated)
      
      HINSTANCE hInst; // module which owns this slot
      
      };
      
      该结构用来描述槽的使用：
      
      域dwFlags表示槽的状态，即被占用或者没有；
      
      域hInst表示使用该槽的模块的句柄。
      
      m_pSlotData表示一个CSlotData类型的数组，用来描述各个槽。该数组通过成员函数AllocSlot和FreeSlot来动态地管理，见图9-6。
      
      （3）m_list
      
      先讨论CThreadData 类。CThreadData定义如下：
      
      struct CThreadData : public CNoTrackObject{
      
      CThreadData* pNext; // required to be member of CSimpleList
      
      int nCount; // current size of pData
      
      LPVOID* pData; // actual thread local data (indexed by nSlot)
      
      };
      
      该结构用来描述CThreadSlotData为每个线程管理的线程局部空间：
      
      域pNext把各个线程的CThreadData项目链接成一个表，即把各个线程的线程私有空间链接起来；
      
      域nCount表示域pData的尺寸，即存储了多少个线程私有数据；
      
      pData表示一个LPVOID类型的数组，数组中的每一个元素保存一个指针，即线程私有数据指针，该指针指向一个在堆中分配的真正存储线程私有数据的地址。数组元素的个数和槽的个数相同，每个线程局部变量（THREAD_LOCAL定义的变量）都有一个对应的槽号，用该槽号作为下标来引用pData。
      
      m_list表示一个CThreadData类型的指针数组，数组中的各项指向各个线程的线程私有空间，每个线程在数组中都有一个对应项。该数组通过GetValue、SetValue、DeleteValues等成员函数来管理，见图9-6。
    3. _afxThreadData

_afxThreadData仅仅定义为一个CThreadSlotData类型的指针，所指对象在第一次被引用时创建，在此之前该指针为空。下文_afxThreadData含义是它所指的对象。图9-5、9-6图解了MFC的线程局部存储机制的实现。

图9-5表示_afxTheadData使用TLS技术负责给进程分配一个TLS索引，然后使用TLS索引为进程的每一个线程分配线程局部存储空间。

图9-6表示每个线程的的局部存储空间可以分多个槽，每个槽可以放一个线程私有的数据指针。_afxThreadData负责给线程局部变量分配槽号并根据槽号存取数据。图的左半部分描述了管理槽的m_pSlotData及类CSlotData的结构，右半部分描述了管理MFC线程私有空间的m_list及类CThreadData的结构。

结合图9-6，对MFC线程局部存储机制总结如下：

每个线程局部变量（宏THREAD_LOCAL定义）占用一个槽，并有一个槽号。。
每个线程都有自己的MFC局部存储空间（下文多次使用“线程的MFC局部存储空间”，表示和此处相同的概念）。
通过TLS索引得到的是一个指针P1，它指向线程的MFC局部存储空间。
通过指针P1和线程局部变量在空间所占用的槽号，得到该槽所存储的线程私有的数据指针，即真正的线程私有数据的地址P2；
从地址P2得到数据D。

这个过程相当于几重间接寻址：先得到TLS线程私有数据指针，从TLS线程私有数据指针得到线程的MFC线程局部存储空间，再从MFC局部存储空间的对应槽得到一个线程私有的数据指针，从该指针得到最终的线程私有数据。如果没有这种机制，使用Win32 TLS只要一次间接寻址：得到TLS线程私有数据指针，从该指针得到最终的线程私有数据。

线程状态_afxThreadState

从上一节知道了MFC的线程局部存储机制。但有一点还不清楚，即某个线程局部变量所占用的槽号是怎么保存的呢？关于这点可从线程局部的线程状态变量_afxThreadState的实现来分析MFC的作法。变量_afxThreadState的定义如下：

THREAD_LOCAL(_AFX_THREAD_STATE, _afxThreadState)

THREAD_LOCAL 是一个宏，THREAD_LOCAL(class_name, ident_name)宏展开后如下：

AFX_DATADEF CThreadLocal<class_name> ident_name;

这里，CThreadLocal是一个类模板，从CThreadLocalObject类继承。

CThreadLocalObject和CThreadLocal的定义如下：

class CThreadLocalObject

{

public:

// Attributes

CNoTrackObject* GetData(CNoTrackObject* (AFXAPI*

pfnCreateObject)());

CNoTrackObject* GetDataNA();

// Implementation

int m_nSlot;

~CThreadLocalObject();

};

CThreadLocalObject用来帮助实现一个线程局部的变量。成员变量m_nSlot表示线程局部变量在MFC线程局部存储空间中占据的槽号。GetDataNA用来返回变量的值。GetData也可以返回变量的值，但是如果发现还没有给该变量分配槽号(m_slot=0)，则给它分配槽号并在线程的MFC局部空间为之分配一个槽；如果在槽m_nSlot还没有数据（为空），则调用参数pfnCreateObject传递的函数创建一个数据项，并保存到槽m_nSlot中。

template<class TYPE>

class CThreadLocal : public CThreadLocalObject

{

// Attributes

public:

inline TYPE* GetData()

{

TYPE* pData = (TYPE*)CThreadLocalObject::GetData(&CreateObject);

ASSERT(pData != NULL);

return pData;

}

inline TYPE* GetDataNA()

{

TYPE* pData = (TYPE*)CThreadLocalObject::GetDataNA();

return pData;

}

inline operator TYPE*()

{ return GetData(); }

inline TYPE* operator->()

{ return GetData(); }

// Implementation

public:

static CNoTrackObject* AFXAPI CreateObject()

{ return new TYPE; }

};

CThreadLocal模板用来声明任意类型的线程私有的变量，因为通过模板可以自动的正确的转化(cast)指针类型。程序员可以使用它来实现自己的线程局部变量，正如MFC实现线程局部的线程状态变量和模块-线程变量一样。

CThrealLocal的成员函数CreateObject用来创建动态的指定类型的对象。成员函数GetData调用了基类CThreadLocalObject的同名函数，并且把CreateObject函数的地址作为参数传递给它。

另外，CThreadLocal模板重载了操作符号“*”、“->”，这样编译器将自动地进行有关类型转换，例如:

_AFX_THREAD_STATE *pStata = _afxThreadState

是可以被编译器接收的。

现在回头来看_afxThreadState的定义：

从以上分析可以知道，THREAD_LOCAL(class_name, ident_name)定义的结果并没有产生一个名为ident_name的class_name类的实例，而是产生一个CThreadLocal模板类（确切地说，是其派生类）的实例，m_nSlot初始化为0。所以，_afxThreadState实质上是一个CThreadLocal模板类的全局变量。每一个线程局部变量都对应了一个全局的CThreadLoacl模板类对象，模板对象的m_nSlot记录了线程局部变量对象的槽号。
进程模块状态afxBaseModuleState

进程模块状态定义如下：

PROCESS_LOCAL(_AFX_BASE_MODULE_STATE, _afxBaseModuleState)

表示它是一个_AFX_BASE_MODULE_STATE类型的进程局部(process local)的变量。

进程局部变量的实现方法主要是为了用于Win32s下。在Win32s下，一个DLL模块如果被多个应用程序调用，它将让这些程序共享它的全局数据。为了DLL的全局数据一个进程有一份独立的拷贝，MFC设计了进程私有的实现方法，实际上就是在进程的堆(Heap)中分配全局数据的内存空间。

在Win32下，DLL模块的数据和代码被映射到调用进程的虚拟空间，也就是说，DLL定义的全局变量是进程私有的；所以进程局部变量的实现并不为Win32所关心。但是，不是说afxBaseModuleState不重要，仅仅是采用PROCESS_LOCAL技术声明它是进程局部变量不是很必要了。PROCESS_LOCAL(class_name, ident_name)宏展开后如下：

AFX_DATADEF CProcessLocal<class_name> ident_name;

这里，CProcessLocal是一个类模板，从CProcessLocalObject类继承。

CProcessLocalObject和CProcessLocal的定义如下：

class CProcessLocalObject

{

public:

// Attributes

CNoTrackObject* GetData(CNoTrackObject* (AFXAPI*

pfnCreateObject)());

// Implementation

CNoTrackObject* volatile m_pObject;

~CProcessLocalObject();

};

template<class TYPE>

class CProcessLocal : public CProcessLocalObject

{

// Attributes

public:

inline TYPE* GetData()

{

TYPE* pData =(TYPE*)CProcessLocalObject::GetData(&CreateObject);

ASSERT(pData != NULL);

return pData;

}

inline TYPE* GetDataNA()

{ return (TYPE*)m_pObject; }

inline operator TYPE*()

{ return GetData(); }

inline TYPE* operator->()

{ return GetData(); }

// Implementation

public:

static CNoTrackObject* AFXAPI CreateObject()

{ return new TYPE; }

};

类似于线程局部对象，每一个进程局部变量都有一个对应的全局CProcessLocal模板对象。
状态对象的创建
1. 状态对象的创建过程

回顾前一节的三个定义：

CThreadSlotData* _afxThreadData;

THREAD_LOCAL(_AFX_THREAD_STATE, _afxThreadState)

PROCESS_LOCAL(_AFX_BASE_MODULE_STATE, _afxBaseModuleState)

第一个仅仅定义了一个指针；第二和第三个定义了一个模板类的实例。相应的CThreadSlotData对象（全局）、_AFX_THREAD_STATE对象（线程局部）以及_AFX_BASE_MODULE_STATE对象（进程局部）并没有创建。当然，模块状态对象的成员模块-线程对象也没有被创建。这些对象要到第一次被访问时，才会被创建，这样做会提高加载DLL的速度。

下面以一个动态链接到MFC DLL的单模块应用程序为例，说明这些对象的创建过程。

当第一次访问状态信息时，比如使用 AfxGetModuleState得到模块状态，导致系列创建过程的开始，如图9-7所示。

首先分析语句pState=_afxThreadState。如果_afxThreadData、线程状态和模块状态还没有创建，该语句可以导致这些数据的创建。

pState声明为CNoTrackObject对象的指针，_afxThreadState声明为一个模板CThreadLocal的实例，pState=_afxThreadData为什么可以通过编译器的检查呢？因为CThreadLocal模板重载了操作符“”*”和“->”，这两个运算返回CNoTrackObject类型的对象。回顾3.2节CThreadLocalObject、CThreadLocal的定义，这两个操作符运算到最后都是调用CThreadLocalObject的成员函数GetData。

创建_afxThreadData所指对象和线程状态

CThreadLocalObject::GetData用来获取线程局部变量（这个例子中是线程状态）的值，其参数用来创建动态的线程局部变量。图9-7的上面的虚线框表示其流程：

它检查成员变量m_nSlot是否等于0（线程局部变量是否曾经被分配了MFC线程私有空间槽位），检查全局变量_afxTheadData指针是否为空。如果_afxThreadData空，则创建一个CThreadSlotData类对象，让_afxThreadData指向它，这样本程序的MFC线程局部存储的管理者被创建。如果m_nSlot等于0，则让_afxThreadDtata调用AllocSlot分配一个槽位并把槽号保存在m_nSlot中。

得到了线程局部变量（线程状态）所占用的槽位后，委托_afxThreadData调用GetThreadValue(m_nSlot)得到线程状态值（指针）。如果结果非空，则返回它；如果结果是NULL，则表明该线程状态还没有被创建，于是使用参数创建一个动态的线程状态，并使用SetValue把其指针保存在槽m_nSlot中，返回该指针。

创建模块状态

得到了线程状态的值后，通过它得到模块状态m_pModuleState。如果m_pModuleState为空，表明该线程状态是才创建的，其许多成员变量还没有赋值，程序的进程模块状态还没有被创建。于是调用函数_afxBaseModule.GetData，导致进程模块状态被创建。

图9-7的下面一个虚线框表示了CProcessLocalObject::GetData的创建过程：

_afxBaseModule首先检查成员变量m_pObject是否空，如果非空就返回它，即进程模块状态指针；否则，在堆中创建一个动态的_AFX_BASE_MODULE_STATE对象，返回。

从上述两个GetData的实现可以看出，CThreadLocal模板对象负责线程局部变量的创建和管理(查询，修改，删除)；CProcessLocal模板对象负责进程局部变量的创建和管理(查询，修改，删除)。

模块-线程状态的创建

模块状态的成员模块-线程状态m_thread的创建类似于线程状态的创建：当第一次访问m_thread所对应的CThreadLocal模板对象时，给m_thread分配MFC线程局部存储的私有槽号m_nSlot，并动态地创建_AFX_MODULE_THREAD_STATE对象，保存对象指针在m_nSlot槽中。

创建过程所涉及的几个重要函数的算法

创建过程所涉及的几个重要函数的算法描述如下：

AllocSlot

AllocSlot用来分配线程的MFC私有存储空间的槽号。由于该函数要修改全局变量_afxThreadData，所以必须使用m_sect关键段对象来同步多个线程对该函数的调用。

CThreadSlotData::AllocSlot()

{

进入关键段代码（EnterCriticalSection(m_sect);）

搜索m_pSlotData，查找空槽（SLOT）

如果不存在空槽（第一次进入时，肯定不存在）

分配或再分配内存以创建新槽，

指针m_pSlotData指向分配的地址。

得到新槽(SLOT)

标志该SLOT为已用

记录最新可用的SLOT到成员变量m_nRover中。

离开关键段代码（LeaveCriticalSection(m_sect);）

返回槽号

}
GetThreadValue

GetThreadValue用来获取调用线程的第slot个线程局部变量的值。每一个线程局部变量都占用一个且只一个槽位。

CThreadSlotData::GetThreadValue(int slot)

{

//得到一个CThreadData型的指针pData

//pData指向MFC线程私有存储空间。

//m_tlsIndex在_afxThreadData创建时由构造函数创建

pData=(CThreadData*)TlsGetValue(m_tlsIndex)，。

如果指针空或slot>pData->nCount, 则返回空。

否则，返回pData

}
SetValue

SetValue用来把调用线程的第slot个线程局部变量的值（指针）存放到线程的MFC私有存储空间的第slot个槽位。

CThreadSlotData::SetValue(int slot, void *pValue)

{

//通过TLS索引得到线程的MFC私有存储空间

pData = (CThreadData*)TlsGetValue(m_tlsIndex)

//没有得到值或者pValue非空且当前槽号，即

//线程局部变量的个数

//大于使用当前局部变量的线程个数时

if （pData NULL or slot > pData->nCount && pValue！=NULL）

{

if pData NULL //当前线程第一次访问该线程局部变量

{

创建一个CThreadData实例；

添加到CThreadSlotData::m_list；

令pData指向它；

}

按目前为止，线程局部变量的个数为pData->pData分配或重分配内存，

用来容纳指向真正线程数据的指针

调用TlsSetValue(pData)保存pData

}

//把指向真正线程数据的pValue保存在pData对应的slot中

pData->pData[slot] = pValue

}

管理状态

在描述了MFC状态的实现机制之后，现在来讨论MFC的状态管理和相关状态的作用。
1. 模块状态切换

模块状态切换就是把当前线程的线程状态的m_pModuleState指针指向即将运行模块的模块状态。

MFC使用AFX_MANAGE_STATE宏来完成模块状态的切换，即进入模块时使用当前模板的模板状态，并保存原模板状态；退出模块时恢复原来的模块状态。这相当于状态的压栈和出栈。实现原理如下。

先看MFC关于AFX_MANAGE_STATE的定义：

#ifdef _AFXDLL

struct AFX_MAINTAIN_STATE

{

AFX_MAINTAIN_STATE(AFX_MODULE_STATE* pModuleState);

~AFX_MAINTAIN_STATE();

protected:

AFX_MODULE_STATE* m_pPrevModuleState;

};

//AFX_MANAGE_STATE宏的定义：

#define AFX_MANAGE_STATE(p) AFX_MAINTAIN_STATE _ctlState(p);

#else // _AFXDLL

#define AFX_MANAGE_STATE(p)

#endif //!_AFXDLL

如果使用MFC DLL，MFC提供类AFX_MAINTAIN_STATE来实现状态的压栈和出栈，AFX_MANAGE_SATATE宏的作用是定义一个AFX_MAINTAIN_STATE类型的局部变量_ctlState。

AFX_MAINTAIN_STATE的构造函数在其成员变量m_pPrevModuleState中保存当前的模块状态对象，并把参数指定的模块状态设定为当前模块状态。所以该宏作为入口点的第一条语句就切换了模块状态。

在退出模块时，局部变量_ctlState将自动地销毁，这导致AFX_MAINTAIN_STATE的析构函数被调用，析构函数把保存在m_pPrevModuleState的状态设置为当前状态。

AFX_MANAGE_SATATE的参数在不同场合是不一样的，例如，

DLL的输出函数使用

AFX_MANAGE_SATATE(AfxGetStaticModuleState())；

其中，AfxGetStaticModuleState返回DLL的模块状态afxModuleState。

窗口函数使用

AFX_MANAGE_STATE(_afxBaseModuleState.GetData());

其中，_afxBaseModuleState.GetData()返回的是应用程序的全局模块状态。

OLE使用的模块切换方法有所不同，这里不作讨论。

上面讨论了线程执行行不同模块的代码时切换模块状态的情况。在线程创建时怎么处理模块状态呢？

一个进程(使用MFC的应用程序)的主线程创建线程模块状态和进程模块状态，前者是_AFX_THREAD_STATE类的实例，后者是_AFX_BASE_MODULE_STATE类的实例。
当进程的新的线程被创建时，它创建自己的线程状态，继承父线程的模块状态。在线程的入口函数_AfxThreadEntry完成这样的处理，该函数的描述见8.5.3节。

扩展DLL的模块状态

7.3.1节指出扩展DLL的实现必须遵循五条规则，为此，首先在扩展DLL实现文件里头，定义AFX_EXTENSION_MODULE类型的静态扩展模块变量，然后在DllMain入口函数里头使用AfxInitExtension初始化扩展模块变量，并且实现和输出一个初始化函数供扩展DLL的使用者调用。

使用者必须具备一个CWinApp对象，通常在它的InitInstance函数中调用扩展DLL提供的初始化函数。

一般用以下的几段代码完成上述任务。首先是扩展模块变量的定义和初始化：

static AFX_EXTENSION_MODULE extensionDLL;

DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID)

{

if (dwReason == DLL_PROCESS_ATTACH)

{

// Extension DLL one-time initialization

if (!AfxInitExtensionModule(extensionDLL,hInstance))

return 0;

……

}

}

然后是扩展DLL的初始化函数，假定初始化函数命名为InitMyDll，InitMyDll被定义为“C”链接的全局函数，并且被输出。

// wire up this DLL into the resource chain

extern “C” void WINAPI InitMyDll()

{

CDynLinkLibrary* pDLL = new

CDynLinkLibrary(extensionDLL, TRUE);

ASSERT(pDLL != NULL);

…

}

最后是调用者的处理，假定在应用程序对象的InitInstance函数中调用初始化函数：

BOOL CMyApp::InitInstance()

{

InitMyMyDll();

…

}

上述这些代码只有在动态链接到MFC DLL时才有用。下面，对这些代码进行分析和解释
1. _AFX_EXTENSION_MODULE
  
  在分析代码之前，先讨论描述扩展模块状态的_AFX_EXTENSION_MODULE类。_AFX_EXTENSION_MODULE没有基类，其定义如下：
  
  struct AFX_EXTENSION_MODULE
  
  {
  
  BOOL bInitialized;
  
  HMODULE hModule;
  
  HMODULE hResource;
  
  CRuntimeClass* pFirstSharedClass;
  
  COleObjectFactory* pFirstSharedFactory;
  
  };
  
  其中：
  
  第一个域表示该结构变量是否已经被初始化了；
  
  第二个域用来保存扩展DLL的模块句柄；
  
  第三个域用来保存扩展DLL的资源句柄；
  
  第四个域用来保存扩展DLL要输出的CRuntimeClass类；
  
  第五个域用来保存扩展DLL的OLE Factory。
  
  该结构用来描述一个扩展DLL的模块状态信息，每一个扩展DLL都要定义一个该类型的静态变量，例如extensionDLL。
  
  在DllMain中，调用AfxInitExtensionModule函数来初始化本DLL的静态变量该变量(扩展模块状态)，如extensionDLL。函数AfxInitExtensionModule原型如下：
  
  BOOL AFXAPI AfxInitExtensionModule(
  
  AFX_EXTENSION_MODULE& state, HMODULE hModule)
  
  其中：
  
  参数1是DllMain传递给它的扩展DLL的模块状态，如extensionDLL；
  
  参数2是DllMain传递给它的模块句柄。
  
  AfxInitExtensionModule函数主要作以下事情：
  
  （1）把扩展DLL模块的模块句柄hModule、资源句柄hModule分别保存到参数state的成员变量hModule、hResource中；
  
  （2）把当前模块状态的m_classList列表的头保存到state的成员变量pFirstSharedClass中，m_classInit的头设置为模块状态的m_pClassInit。在扩展DLL模块进入DllMain之前，如果该扩展模块构造了静态AFX_CLASSINIT对象，则在初始化时把有关CRuntimeClass信息保存在当前模块状态（注意不是扩展DLL模块，而是应用程序模块）的m_classList列表中。因此，扩展DLL模块初始化的CRuntimeClass信息从模块状态的m_classList中转存到扩展模块状态state的pFirstSharedClass中，模块状态的m_classInit恢复被该DLL改变前的状态。
  
  关于CRuntimeclass信息和AFX_CLASSINIT对象的构造，在3.3.1节曾经讨论过。一个扩展DLL在初始化时，如果需要输出它的CRuntimeClass对象，就可以使用相应的CRuntimeClass对象定义一个静态的AFX_CLASSINIT对象，而不一定要使用IMPLEMENT_SERIAL宏。当然，可以序列化的类必定导致可以输出的CRuntimeClass对象。
  
  （3）若支持OLE的话，把当前模块状态的m_factoryList的头保存到state的成员变量pFirstSharedFactory中。m_factoryList的头设置为模块状态的m_m_pFactoryInit。
  
  （4）这样，经过初始化之后，扩展DLL模块包含了扩展DLL的模块句柄、资源句柄、本模块初始化的CRuntimeClass类等等。
  
  扩展DLL的初始化函数将使用扩展模块状态信息。下面，讨论初始化函数的作用。
2. 扩展DLL的初始化函数
在初始化函数InitMyDll中，创建了一个动态的CDynLinkLibrary对象，并把对象指针保存在pDLL中。CDynLinkLibrary类从CCmdTarget派生，定义如下：

class CDynLinkLibrary : public CCmdTarget

{

DECLARE_DYNAMIC(CDynLinkLibrary)

public:

// Constructor

CDynLinkLibrary(AFX_EXTENSION_MODULE& state,

BOOL bSystem = FALSE);

// Attributes

HMODULE m_hModule;

HMODULE m_hResource; // for shared resources

CTypedSimpleList<CRuntimeClass*> m_classList;

#ifndef _AFX_NO_OLE_SUPPORT

CTypedSimpleList<COleObjectFactory*> m_factoryList;

#endif

BOOL m_bSystem; // TRUE only for MFC DLLs

// Implementation

public:

CDynLinkLibrary* m_pNextDLL; // simple singly linked list

virtual ~CDynLinkLibrary();

#ifdef _DEBUG

virtual void AssertValid() const;

virtual void Dump(CDumpContext& dc) const;

#endif //_DEBUG

};

CDynLinkLibrary的结构和AFX_EXTENSION_MODULE有一定的相似性，存在对应关系。

CDynLinkLibrary构造函数的第一个参数就是经过AfxInitExtensionModule初始化后的扩展DLL的模块状态，如extensionDLL，第二个参数表示该DLL模块是否是系统模块。

创建CDynLinkLibrary对象导致CCmdTarget和CDynLinkLibrary类的构造函数被调用。CCmdTarget的构造函数将获取模块状态并且保存在成员变量m_pModuleState中。CDynLinkLibrary的构造函数完成以下动作：

构造列表m_classList和m_factoryList；

把参数state的域hModule、hResource复制到对应的成员变量m_hModule、m_hResource中；

把state的pFirstSharedClass、pFirstSharedFactory分别插入到m_classList列表、m_factoryList列表的表头；

把参数2的值赋值给成员变量m_bSystem中；

至此，CDynLinkLibrary对象已经构造完毕。之后，CDynLinkLibrary构造函数把CDynLinkLibrary对象自身添加到当前模块状态（调用扩展DLL的应用程序模块或者规则DLL模块）的CDynLinkLibrary列表m_libraryList的表头。为了防止多个线程修改模块状态的m_libraryList，访问m_libraryList时使用了同步机制。

这样，调用模块执行完扩展模块的初始化函数之后，就把该扩展DLL的资源、CRuntimeClass类、OLE Factory等链接到调用者的模块状态中，形成一个链表。图9-8表明了这种关系链。

综合以上分析，可以知道：

扩展DLL的模块仅仅在该DLL调用DllMain期间和调用初始化函数期间被使用，在这些初始化完毕之后，扩展DLL模块被链接到当前调用模块的模块状态中，因此它所包含的资源信息等也就被链接到调用扩展DLL的应用程序或者规则DLL的模块状态中了。扩展DLL扩展了调用者的资源等，这是“扩展DLL”得名的原因之一。

也正因为扩展DLL没有自己的模块状态（指AFX_MODULE_STATE对象，扩展DLL模块状态不是），而且必须由有模块状态的模块来使用，所以只有动态链接到MFC的应用程序或者规则DLL才可以使用扩展DLL模块的输出函数或者输出类。
核心MFC DLL

所谓核心MFC DLL，就是MFC核心类库形成的DLL，通常说动态链接到MFC，就是指核心MFC DLL。

核心MFC DLL实际上也是一种扩展DLL，因为它定义了自己的扩展模块状态coreDLL，实现了自己的DllMain函数，使用AfxInitExtensionModule初始化核心DLL的扩展模块状态coreDLL，并且DllMain还创建了CDynLinkLibrary，把核心DLL的扩展模块状态coreDLL链接到当前应用程序的模块状态中。所有这些，都符合扩展DLL的处理标准。

但是，核心MFC DLL是一种特殊的扩展DLL，因为它定义和实现了MFC类库，模块状态、线程状态、进程状态、状态管理和使用的机制就是核心MFC DLL定义和实现的。例如核心MFC DLL定义和输出的模块状态变量，即_afxBaseModuleState，就是动态链接到MFC的DLL的应用程序的模块状态。

但是MFC DLL不作为独立的模块表现出来，而是把自己作为一个扩展模块来处理。当应用程序动态链接到MFC DLL时，MFC DLL把自己的扩展模块状态coreDLL链接到模块状态afxBaseModuleState，模块状态的成员变量m_hCurrentInstanceHandle指定为应用程序的句柄。当规则DLL动态链接到MFC DLL时，由规则DLL的DllMain把核心MFC DLL的扩展模块状态coreDLL链接到规则DLL的模块状态afxModuleState中，模块状态afxModuleState的m_hCurrentInstanceHandle指定为规则DLL的句柄。

关于afxModuleState和规则DLL的模块状态，见下一节的讨论。
动态链接的规则DLL的模块状态的实现

在本节中，动态链接到MFC DLL（定义了_AFXDLL）的规则DLL在下文简称为规则DLL。

（1）规则DLL的模块状态的定义

规则DLL有自己的模块状态_afxModuleState，它是一个静态变量，定义如下：

static _AFX_DLL_MODULE_STATE afxModuleState;

_AFX_DLL_MODULE_STATE的基类是AFX_MODULE_STATE。

在前面的模块状态切换中提到的AfxGetStaticModuleState函数，其定义和实现如下：

_AFX_MODULE_STATE* AFXAPI AfxGetStaticModuleState()

{

AFX_MODULE_STATE* pModuleState = &afxModuleState;

return pModuleState;

}

它返回规则DLL的模块状态afxModuleState。

规则DLL的内部函数使用afxModuleState作为模块状态；输出函数在被调用的时候首先切换到该模块状态，然后进一步处理。

（2）规则DLL的模块状态的初始化

从用户角度来看，动态链接到MFC DLL的规则DLL不需要DllMain函数，只要提供CWinApp对象即可。其实，MFC内部是在实现扩展DLL的方法基础上来实现规则DLL的，它不仅为规则DLL提供了DllMain函数，而且规则DLL也有扩展DLL模块状态controlDLL。

顺便指出，和扩展DLL相比，规则DLL有一个CWinApp（或其派生类）应用程序对象和一个模块状态afxModuleState。应用程序对象是全局对象，所以在进入规则DLL的DllMain之前已经被创建，DllMain可以调用它的初始化函数InitInstance。模块状态afxModuleState是静态全局变量，也在进入DllMain之前被创建，DllMain访问模块状态时得到的就是该变量。扩展DLL是没有CWinApp对象和模块状态的，它只能使用应用程序或者规则DLL的CWinApp对象和模块状态。

由于核心MFC DLL的DllMain被调用的时候，访问的必定是应用程序的模块状态，要把核心DLL的扩展模块状态链接到规则DLL的模块状态中，必须通过规则DLL的DllMain来实现。

规则DLL的DllMain（MFC内部实现）把参数1表示的模块和资源句柄通过AfxWinInit函数保存到规则DLL的模块状态中。顺便指出，WinMain也通过AfxWinInit函数把资源和模块句柄保存到应用程序的模块状态中。

然后，该DllMain还创建了一个CDynLinkLibrary对象，把核心MFC DLL的扩展模块 coreDLL链接到本DLL的模块状态afxModuleState。

接着，DllMain得到自己的应用程序对象并调用InitInstance初始化。

之后，DllMain创建另一个CDynLinkLibrary对象，把本DLL的扩展模块controlDLL链接到本DLL的模块状态afxModuleState。

（3）使用规则DLL的应用程序可不需要CwinApp对象

规则DLL的资源等是由DLL内部使用的，不存在资源或者CRuntimeClass类输出的问题，这样调用规则DLL的程序不必具有模块状态，不必关心规则DLL的内部实现，不一定需要CwinApp对象，所以可以是任意Win32应用程序，

还有一点需要指出，DllMain也是规则DLL的入口点，在它之前，调用DllMain的RawDllMain已经切换了模块状态，RawDllMain是静态链接的，所以不必考虑状态切换。

状态信息的作用

在分析了MFC模块状态的实现基础和管理机制之后，现在对状态信息的作用进行专门的讨论。
1. MFC资源、运行类信息的查找

MFC内部使用的资源查找函数是：

HINSTANCE AfxFindResourceHandle(LPCTSTR lpszName, LPCTSTR lpszType)：

其中：

参数1是要查找的资源名称，参数2是要查找的资源类型。

返回包含指定资源的模块的句柄。

上述函数的查找算法如下：

如果进程模块状态（主模块）不是系统模块，则使用::FindResource（下同）搜索它，成功则返回；
如果没有找到，则遍历CDynLinkLibrary对象列表，搜索所有的非系统模块，成功则返回；
如果没有找到，则检查主模块的语言资源，成功则返回；
如果没有找到，并且主模块是系统模块，则搜索它，成功则返回；
如果没有找到，则遍历CDynLinkLibrary对象列表，搜索所有的系统模块，成功则返回；
如果没有找到，则使用AfxGetResourceHanlde返回应用程序的资源。

需要指出的是，遍历CDynLinkLibrary对象列表时，必须采取同步措施，防止其他线程改变链表。MFC是通过锁定全局变量CRIT_DYNLINKLIST来实现的，类似的全局变量MFC定义了多个。

运行时类信息的查找算法类似。

3.3.4节指出，对象进行“<<”序列化操作时，首先需要搜索到指定类的运行时信息，方法如下：

CRuntimeClass* PASCAL CRuntimeClass::Load(

CArchive& ar, UINT* pwSchemaNum)

遍历主模块的CRuntimeClass对象列表m_classList，搜索主模块是否实现了指定的CRuntimeClass类；
遍历CDynLinkLibrary对象列表m_libraryList；对每一个CDynLinkLibrary对象，遍历它的CRuntimeClass对象列表m_classList。这样，所有的扩展DLL模块的CRuntimeClass对象都会被搜索到。

模块信息的显示

遍历模块状态和CDynLinkLibrary列表，可以显示模块状态及其扩展模块状态的有关信息。下面，给出一个实现，它显示程序的当前模块名称、句柄和初始化的CRuntimeClass类，然后显示所有扩展模块的名称名称、句柄和初始化的CRuntimeClass类。

#ifdef _DEBUG

AFX_MODULE_STATE* pState = AfxGetModuleState();

//显示应用程序的名称和句柄

TRACE(“APP %s HANDLE %x\r\n”, pState->m_lpszCurrentAppName,

pState->m_hCurrentInstanceHandle);

TCHAR szT[256];

int nClasses;

nClasses=0;

//显示CRuntimeClass类信息

AfxLockGlobals(CRIT_RUNTIMECLASSLIST);

for (CRuntimeClass* pClass = pModuleState->m_classList;

pClass != NULL;pClass = pClass->m_pNextClass)

{

nClasses++;

TRACE(“CRuntimeClass: %s\r\n”,pClass->m_lpszClassName, );

}

AfxUnlockGlobals(CRIT_RUNTIMECLASSLIST);

TRACE(“all %d classes\r\n”, nClasses);

//遍历CDynLinkLibrary列表

AfxLockGlobals(CRIT_DYNLINKLIST);

for (CDynLinkLibrary* pDLL = pState->m_libraryList; pDLL != NULL;

pDLL = pDLL->m_pNextDLL)

{

// 得到模块名并且显示

TCHAR szName[64];

GetModuleFileName(pDLL->m_hModule, szName, sizeof(szName));

TRACE(“MODULE %s HANDLE IS %x \r\n”, szName, pDLL->m_hModule);

//得到CRuntimeClass信息并显示

nClasses = 0;

for (CRuntimeClass* pClass = pDLL->m_classList;

pClass != NULL; pClass = pClass->m_pNextClass)

{

nClasses++;

TRACE(“CRuntimeClass: %s\r\n”,pClass->m_lpszClassName, );

}

wsprintf(szT, _T(” Module %s has %d classes”),szName, nClasses);

}

AfxUnlockGlobals(CRIT_DYNLINKLIST);

#endif

使用MFC提供的调试函数AfxDoForAllClasses可以得到DLL模块的输出CRuntimeClass类的信息。上述实现类似于AfxDoForAllClasses函数的处理，只不过增加了模块名和模块句柄信息。
模块-线程状态的作用

由模块-线程状态类的定义可知，一个模块-线程状态包含了几类Windows对象—MFC对象的映射。下面讨论它们的作用。
1. 只能访问本线程MFC对象的原因

MFC规定：

不能从一个非MFC线程创建和访问MFC对象

如果一个线程被创建时没有用到CWinThread对象，比如，直接使用“C”的_beginthread或者_beginthreadex创建的线程，则该线程不能访问MFC对象；换句话说，只有通过CWinThread创建MFC线程对象和Win32线程，才可能在创建的线程中使用MFC对象。
一个线程仅仅能访问它所创建的MFC对象

这两个规定的原因是：

为了防止多个线程并发地访问同一个MFC对象，MFC对象和Windows对象之间有一个一一对应的关系，这种关系以映射的形式保存在创建线程的当前模块的模块-线程状态信息中。当一个线程使用某个MFC对象指针P时，ASSERT_VALID(P)将验证当前线程的当前模块是否有Windows句柄和P对应，即是否创建了P所指的Windows对象，验证失败导致ASSERT断言中断程序的执行。如果一个线程要使用其他线程的Windows对象，则必须传递Windows对象句柄，不能传递MFC对象指针。

当然一般来说，MFC应用程序仅仅在Debug版本下才检查这种映射关系，所以访问其他线程的MFC对象的程序在Realease版本下表面上不会有问题，但是MFC对象被并发访问的后果是不可预见的。

实现MFC对象和Windows对象之间的映射

MFC提供了几个函数完成MFC对象和Windows对象之间的映射或者解除这种映射关系，以及从MFC对象得到Windows对象或者从Windows对象得到或创建相应的MFC对象。

每一个MFC对象类都有成员函数Attach和Detach，FromHandle和FromHandlePermanent，AssertValid。这些成员函数的形式如下：

Attach(HANDLE Windows_Object_Handle)

例如：CWnd类的是Attach(HANLDE hWnd)，CDC类的是Attach(HDC hDc)。

Attach用来把一个句柄永久性(Perment)地映射到一个MFC对象上：它把一个Windows对象捆绑(Attach)到一个MFC对象上，MFC对象的句柄成员变量赋值为Windows对象句柄，该MFC对象应该已经存在，但是句柄成员变量为空。

Detach（）

Detach用来取消Windows对象到MFC对象的永久性映射。如果该Windows对象有一个临时的映射存在，则Detach不理会它。MFC让线程的Idle清除临时映射和临时MFC对象。

FromHandle(HANDLE Windows_Object)

它是一个静态成员函数。如果该Windows对象没有映射到一个MFC对象，FromHandle则创建一个临时的MFC对象，并把Windows对象映射到临时的MFC对象上，然后返回临时MFC对象。

FromHandlePermanent(HANDLE Windows_Object)

它是一个静态成员函数。如果该Windows对象没有永久地映射到一个MFC对象上，则返回NULL，否则返回对应的MFC对象。

AssertValid()

它是从CObject类继承来的虚拟函数。MFC覆盖该函数，实现了至少一个功能：判断当前MFC对象的指针this是否映射到一个对应的可靠的Windows对象。

图 9-9示意了MFC对映射结构的实现层次，对图9-9解释如下。

图中上面的虚线框表示使用映射关系的高层调用，包括上面讲述的几类函数。MFC和应用程序通过它们创建、销毁、使用映射关系。

图中中间的虚线框表示MFC使用CHandleMap类实现对映射关系的管理。一个CHandleMap对象可以通过两个成员变量来管理两种映射数据：临时映射和永久映射。模块-线程状态给每一类MFC对象分派一个CHandleMap对象来管理其映射数据(见模块-线程类的定义)，例如m_pmapHWND所指对象用来保存CWnd对象（或派生类对象）和Windows window之间的映射。

下面的虚线框表示映射关系的最底层实现，MFC使用通用类CMapPtrToPtr来管理MFC对象指针和Windows句柄之间的映射数据。

对本节总结如下：

MFC的映射数据保存在模块-线程状态中，是线程和模块局部的。每个线程管理自己映射的数据，其他线程不能访问到本线程的映射数据，也就不允许使用本线程的MFC对象。
每一个MFC对象类（CWnd、CDC等）负责创建或者管理这类线程-模块状态的对应CHandleMap类对象。例如，CWnd::Attach创建一个永久性的映射保存在m_pmapHwnd所指对象中，如果m_pmapHand还没有创建，则使用AfxMapHWND创建相应的CHandleMap对象。
映射分两类：永久性的或者临时的。

临时对象的处理

在2.4节就曾经提到了临时对象，现在是深入了解它们的时候了。

临时对象指MFC对象，是MFC或者程序员使用FromHandle或者SelectObject等从一个Windows对象句柄创建的对应的MFC对象。
在模块-线程状态中，临时MFC对象的映射是和永久映射分开保存的。
临时MFC对象在使用完毕后由MFC框架自动删除，MFC在线程的Idle处理中删除本线程的临时MFC对象，为了防止并发修改，通过线程状态m_nTempMapLock（等于0，可以修改，大于0，等待）来同步。所以，临时MFC对象不能保存备用。

状态对象的删除和销毁

至此，本章讨论了MFC的线程局部存储机制，MFC状态的定义、实现和用途。在程序或者DLL退出之前，模块状态被销毁；在线程退出时，线程状态被销毁。状态对象被销毁之前，它活动期间所动态创建的对象被销毁，动态分配的内存被释放。

先解释几个函数：

AfxTermExtensionModule(HANDLE hInstanceOfDll，BOOL bAll);

若bAll为真，则该函数销毁本模块(hInstanceOfDll标识的模块)的模块状态的m_libraryList列表中所有动态分配的CDynLinkLibrary对象，否则，该函数清理本DLL动态分配的CDynLinkLibrary对象，并调用AfxTerLocalData释放本DLL模块为当前线程的线程局部变量分配的堆空间。

AfxTermLocalData(HANDLE hInstance, BOOL bAll);

若bAll为真，则删除MFC线程局部存储的所有槽的指针所指的对象，也就是销毁当前线程的全部局部变量，释放为这些线程局部变量分配的内存；否则，仅仅删除、清理当前线程在hInstance表示的DLL模块中创建的线程局部变量。

参与清理工作的函数有多种、多个，下面结合具体情况简要描述它们的作用。

（1）对动态链接到MFC DLL的应用程序

动态链接到MFC DLL的应用程序退出时，将在DllMain和RawDllMain处理进程分离时清理状态对象，该DllMain和RawDllMain是核心MFC DLL的入口和出口，在DLLINIT.CPP文件中实现，和进程分离时完成如下动作：

DllMain调用AfxTermExtensionModule(coreDll)清理核心MFC DLL的模块状态；调用AfxTermExtensionModule(coreDll, TRUE)清理OLE私有的模块状态；调用AfxTermLocalData(NULL, TRUE)释放本进程或者线程所有的局部变量。

RawDllMain在DllMain之后调用，它调用AfxTlsRealease；AfxTlsRealease减少对_afxThreadData的引用计数，如果引用数为零，则调用对应的CThreadSlotData析构函数清理_afxThreadData所指对象。

（2）对静态链接到MFC DLL的应用程序

如果是静态链接到MFC DLL的应用程序，由于RawDllMain和DllMain不起作用，将由一个静态变量析构时完成状态的清除：

有一个AFX_TERM_APP_STATE类型的静态变量，在程序结束时将被销毁，导致析构函数被调用，析构函数完成以下动作：

调用AfxTermLocalData(NULL, TRUE)释放本进程（主线程）的所用局部数据。

（3）对于动态链接到MFC DLL的规则DLL

对于动态链接到MFC DLL的规则DLL，将在RawDllMain和DllMain中清理状态对象。这两个函数在DllModule.cpp中定义，是规则DLL的入口和出口。当和进程分离时，分别有如下动作：

DllMain清除该模块的模块-线程状态中的所有临时映射，清除临时MFC对象；调用AfxWinTerm；调用AfxTermExtensionModule(controlDLL, TRUE)，释放本DLL模块状态m_libraryList中的所有CDynLinkLibrary对象。

RawDllMain设置线程状态的模块状态指针，使它指向线程状态的m_PrevModuleState所指状态。

（4）对于静态链接到MFC DLL的DLL

对于静态链接到MFC DLL的DLL，只有DllMain会被调用，执行以下动作：

清除该模块的模块-线程状态中的所有临时映射，清除临时MFC对象；调用AfxWinTerm；调用AfxTermLocalData(hInstance, TRUE)清理本DLL模块的当前线程的线程局部数据。

另外，它定义一个_AFX_TERM_DLL_STATE类型的静态变量，在DLL退出时该变量被销毁，导致其析构函数被调用。析构函数完成如下动作：

调用AfxTermateLocalData(NULL, TRUE);调用AfxCriticlTerm结束关键变量；调用AfxTlsRealease。

（5）线程终止时

当使用AFxBeginThread创建的线程终止时，将调用AfxTermThread(HANDLE hInstance)作结束线程的清理工作（参数为NULL）：销毁临时MFC对象，销毁本线程的线程局部变量，等等。

另外，当DLL模块和AfxBeginThread创建的线程分离时，也调用AfxTermThread(hInstance)，参数是模块的句柄，销毁临时MFC对象，销毁本线程在本DLL创建的线程局部变量，等等。所以，AfxTermThread可能被调用两次。

最后，CThreadLocal和CProcessLocal的实例将被销毁，析构函数被调用：如果MFC线程局部存储空间的槽m_nSlot所指的线程局部对象还没有销毁，则销毁它。

_afxThreadData在MFC DLL的RawDllMain或者随着_AFX_TERM_APP_STATE析构函数的调用，_afxThreadData所指对象被销毁。_afxThreadData所指对象销毁之后，所有的状态相关的内存都被释放。

内存分配方式和调试机制
1. M内存分配
  1. 内存分配函数

MFCWin32或者C语言的内存分配API，有四种内存分配API可供使用。

Win32的堆分配函数

每一个进程都可以使用堆分配函数创建一个私有的堆──调用进程地址空间的一个或者多个页面。DLL创建的私有堆必定在调用DLL的进程的地址空间内，只能被调用进程访问。

HeapCreate用来创建堆；HeapAlloc用来从堆中分配一定数量的空间，HeapAlloc分配的内存是不能移动的；HeapSize可以确定从堆中分配的空间的大小；HeapFree用来释放从堆中分配的空间；HeapDestroy销毁创建的堆。
Windows传统的全局或者局部内存分配函数

由于Win32采用平面内存结构模式，Win32下的全局和局部内存函数除了名字不同外，其他完全相同。任一函数都可以用来分配任意大小的内存（仅仅受可用物理内存的限制）。用法可以和Win16下基本一样。

Win32下保留这类函数保证了和Win16的兼容。
C语言的标准内存分配函数

C语言的标准内存分配函数包括以下函数：

malloc，calloc，realloc，free，等。

这些函数最后都映射成堆API函数，所以，malloc分配的内存是不能移动的。这些函数的调式版本为

malloc_dbg，calloc_dbg，realloc_dbg，free_dbg，等。
Win32的虚拟内存分配函数

虚拟内存API是其他API的基础。虚拟内存API以页为最小分配单位，X86上页长度为4KB，可以用GetSystemInfo函数提取页长度。虚拟内存分配函数包括以下函数：

LPVOID VirtualAlloc(LPVOID lpvAddress,

DWORD cbSize,

DWORD fdwAllocationType,

DWORD fdwProtect);

该函数用来分配一定范围的虚拟页。参数1指定起始地址；参数2指定分配内存的长度；参数3指定分配方式，取值MEM_COMMINT或者MEM_RESERVE；参数4指定控制访问本次分配的内存的标识，取值为PAGE_READONLY、PAGE_READWRITE或者PAGE_NOACCESS。

LPVOID VirtualAllocEx(HANDLE process,

LPVOID lpvAddress,

DWORD cbSize,

DWORD fdwAllocationType,

DWORD fdwProtect);

该函数功能类似于VirtualAlloc，但是允许指定进程process。VirtaulFree、VirtualProtect、VirtualQuery都有对应的扩展函数。

BOOL VirtualFree(LPVOID lpvAddress,

DWORD dwSize,

DWORD dwFreeType);

该函数用来回收或者释放分配的虚拟内存。参数1指定希望回收或者释放内存的基地址；如果是回收，参数2可以指向虚拟地址范围内的任何地方，如果是释放，参数2必须是VirtualAlloc返回的地址；参数3指定是否释放或者回收内存，取值为MEM_DECOMMINT或者MEM_RELEASE。

BOOL VirtualProtect(LPVOID lpvAddress,

DWORD cbSize,

DWORD fdwNewProtect,

PDWORD pfdwOldProtect);

该函数用来把已经分配的页改变成保护页。参数1指定分配页的基地址；参数2指定保护页的长度；参数3指定页的保护属性，取值PAGE_READ、PAGE_WRITE、PAGE_READWRITE等等；参数4用来返回原来的保护属性。

DWORD VirtualQuery(LPCVOID lpAddress,

PMEMORY_BASIC_INFORMATION lpBuffer,

DWORD dwLength

);

该函数用来查询内存中指定页的特性。参数1指向希望查询的虚拟地址；参数2是指向内存基本信息结构的指针；参数3指定查询的长度。

BOOL VirtualLock(LPVOID lpAddress,DWORD dwSize);

该函数用来锁定内存，锁定的内存页不能交换到页文件。参数1指定要锁定内存的起始地址；参数2指定锁定的长度。

BOOL VirtualUnLock(LPVOID lpAddress,DWORD dwSize);

参数1指定要解锁的内存的起始地址；参数2指定要解锁的内存的长度。

C++的new 和 delete操作符

MFC定义了两种作用范围的new和delete操作符。对于new，不论哪种，参数1类型必须是size_t，且返回void类型指针。

全局范围内的new和delete操作符

原型如下：

void _cdecl ::operator new(size_t nSize);

void __cdecl operator delete(void* p);

调试版本：

void* __cdecl operator new(size_t nSize, int nType,

LPCSTR lpszFileName, int nLine)
类定义的new和delete操作符

原型如下：

void* PASCAL classname::operator new(size_t nSize);

void PASCAL classname::operator delete(void* p);

类的operator new操作符是类的静态成员函数，对该类的对象来说将覆盖全局的operator new。全局的operator new用来给内部类型对象（如int）、没有定义operator new操作符的类的对象分配内存。

new操作符被映射成malloc或者malloc_dbg，delete被映射成free或者free_dbg。

调试手段

MFC应用程序可以使用C运行库的调试手段，也可以使用MFC提供的调试手段。两种调试手段分别论述如下。
1. C运行库提供和支持的调试功能

C运行库提供和支持的调试功能如下：

调试信息报告函数

用来报告应用程序的调试版本运行时的警告和出错信息。包括：

_CrtDbgReport 用来报告调试信息；

_CrtSetReportMode 设置是否警告、出错或者断言信息；

_CrtSetReportFile 设置是否把调试信息写入到一个文件。
条件验证或者断言宏：

断言宏主要有：

assert 检验某个条件是否满足，不满足终止程序执行。

验证函数主要有：

_CrtIsValidHeapPointer 验证某个指针是否在本地堆中；

_CrtIsValidPointer 验证指定范围的内存是否可以读写；

_CrtIsMemoryBlock 验证某个内存块是否在本地堆中。
内存（堆）调试：

malloc_dbg 分配内存时保存有关内存分配的信息，如在什么文件、哪一行分配的内存等。有一系列用来提供内存诊断的函数：

_CrtMemCheckpoint 保存内存快照在一个_CrtMemState结构中；

_CrtMemDifference 比较两个_CrtMemState；

_CrtMemDumpStatistics 转储输出一_CrtMemState结构的内容；

_CrtMemDumpAllObjectsSince 输出上次快照或程序开始执行以来在堆中分配的所有对象的信息；

_CrtDumpMemoryLeaks 检测程序执行以来的内存漏洞，如果有漏洞则输出所有分配的对象。

MFC提供的调试手段

MFC在C运行库提供和支持的调试功能基础上，设计了一些类、函数等来协助调试。

MFC的TRACE、ASSERT

ASSERT

使用ASSERT断言判定程序是否可以继续执行。

TRACE

使用TRACE宏显示或者打印调试信息。TRACE是通过函数AfxTrace实现的。由于AfxTrace函数使用了cdecl调用约定，故可以接受个数不定的参数，如同printf函数一样。它的定义和实现如下：

void AFX_CDECL AfxTrace(LPCTSTR lpszFormat, …)

{

#ifdef _DEBUG // all AfxTrace output is controlled by afxTraceEnabled

if (!afxTraceEnabled)

return;

#endif

//处理个数不定的参数

va_list args;

va_start(args, lpszFormat);

int nBuf;

TCHAR szBuffer[512];

nBuf = _vstprintf(szBuffer, lpszFormat, args);

ASSERT(nBuf < _countof(szBuffer));

if ((afxTraceFlags & traceMultiApp) && (AfxGetApp() != NULL))

afxDump << AfxGetApp()->m_pszExeName << “: “;

afxDump << szBuffer;

va_end(args);

}

#endif //_DEBUG

在程序源码中，可以控制是否显示跟踪信息，显示什么跟踪信息。如果全局变量afxTraceEnabled为TRUE，则TRACE宏可以输出；否则，没有TRACE信息被输出。如果通过afxTraceFlags指定了跟踪什么消息，则输出有关跟踪信息，例如为了指定“Multilple Application Debug”，令AfxTraceFlags|=traceMultiApp。可以跟踪的信息有：

enum AfxTraceFlags

{

traceMultiApp = 1, // multi-app debugging

traceAppMsg = 2, // main message pump trace (includes DDE)

traceWinMsg = 4, // Windows message tracing

traceCmdRouting = 8, // Windows command routing trace

//(set 4+8 for control notifications)

traceOle = 16, // special OLE callback trace

traceDatabase = 32, // special database trace

traceInternet = 64 // special Internet client trace

};

这样，应用程序可以在需要的地方指定afxTraceEnabled的值打开或者关闭TRACE开关，指定AfxTraceFlags的值过滤跟踪信息。

Visual C++提供了一个TRACE工具，也可以用来完成上述功能。

为了显示消息信息，MFC内部定义了一个AFX_MAP_MESSAG类型的数组allMessages，储存了Windows消息和消息名映射对。例如：

allMessages[1].nMsg = WM_CREATE,

allMessages[1].lpszMsg = “WM_CREATE”

MFC内部还使用函数_AfxTraceMsg显示跟踪消息，它可以接收一个字符串和一个MSG指针，然后，把该字符串和MSG的各个域的信息组合成一个大的字符串并使用AfxTrace显示出来。

allMessages和函数_AfxTraceMsg的详细实现可以参见AfxTrace.cpp。
MFC对象内容转储

对象内容转储是CObject类提供的功能，所有从它派生的类都可以通过覆盖虚拟函数DUMP来支持该功能。在讲述CObject类时曾提到过。

虚拟函数Dump的定义：

class ClassName : public CObject

{

public:

#ifdef _DEBUG

virtual void Dump( CDumpContext& dc ) const;

#endif

…

};

在使用Dump时，必须给它提供一个CDumpContext类型的参数，该参数指定的对象将负责输出调试信息。为此，MFC提供了一个预定义的全局CDumpContext对象afxDump，它把调试信息输送给调试器的调试窗口。从前面AfxTrace的实现可以知道，MFC使用了afxDump输出跟踪信息到调试窗口。

CDumpContext类没有基类，它提供了以文本形式输出诊断信息的功能。

例如：

CPerson* pMyPerson = new CPerson;

// set some fields of the CPerson object…

//…

// now dump the contents

#ifdef _DEBUG

pMyPerson->Dump( afxDump );

#endif
MFC对象有效性检测

对象有效性检测是CObject类提供的功能，所有从它派生的类都可以通过覆盖虚拟函数AssertValid来支持该功能。在讲述CObject类时曾提到过。

虚拟函数AssertValid的定义：

class ClassName : public CObject

{

public:

#ifdef _DEBUG

virtual void AssertValid( ) const;

#endif

…

};

使用ASSERT_VALID宏判断一个对象是否有效，该对象的类必须覆盖了AssertValid函数。形式为：ASSERT_VALID(pObject)。

另外，MFC提供了一些函数来判断地址是否有效，如：

AfxIsMemoryBlock，AfxIsString，AfxIsValidAddress。

内存诊断

MFC使用DEBUG_NEW来跟踪内存分配时的执行的源码文件和行数。

把#define new DEBUG_NEW插入到每一个源文件中，这样，调试版本就使用_malloc_dbg来分配内存。MFC Appwizard在创建框架文件时已经作了这样的处理。

AfxDoForAllObjects

MFC提供了函数AfxDoForAllObjects来追踪动态分配的内存对象，函数原型如下：

void AfxDoForAllObjects( void (*pfn)(CObject* pObject,

void* pContext), void* pContext );

其中：

参数1是一个函数指针，AfxDoForAllObjects对每个对象调用该指针表示的函数。

参数2将传递给参数1指定的函数。

AfxDoForAllObjects可以检测到所有使用new分配的CObject对象或者CObject类派生的对象，但全局对象、嵌入对象和栈中分配的对象除外。
内存漏洞检测

仅仅用于new的DEBUG版本分配的内存。

完成内存漏洞检测，需要如下系列步骤：

调用AfxEnableMemoryTracking(TRUE/FALSE)打开/关闭内存诊断。在调试版本下，缺省是打开的；关闭内存诊断可以加快程序执行速度，减少诊断输出。
使用MFC全局变量afxMemDF更精确地指定诊断输出的特征，缺省值是allocMemDF，可以取如下值或者这些值相或：

afxMemDF，delayFreeMemDF，checkAlwaysMemDF

其中：allocMemDF表示可以进行内存诊断输出；delayFreeMemDF表示是否是在应用程序结束时才调用free或者delete，这样导致程序最大可能的分配内存；checkAlwaysMemDF表示每一次分配或者释放内存之后都调用函数AfxCheckMemory进行内存检测（AfxCheckMemory检查堆中所有通过new分配的内存（不含malloc））。

这一步是可选步骤，非必须。

创建一个CMemState类型的变量oldMemState，调用CMemState的成员函数CheckPoint获得初次内存快照。
执行了系列内存分配或者释放之后，创建另一个CMemState类型变量newMemState，调用CMemState的成员函数CheckPoint获得新的内存快照。
创建第三个CMemState类型变量difMemState，调用CMemState的成员函数Difference比较oldMemState和newMemState，结果保存在变量difMemState中。如果没有不同，则返回FALSE，否则返回TRUE。
如果不同，则调用成员函数DumpStatistics输出比较结果。

例如：

// Declare the variables needed

#ifdef _DEBUG

CMemoryState oldMemState, newMemState, diffMemState;

oldMemState.Checkpoint();

#endif

// do your memory allocations and deallocations…

CString s = “This is a frame variable”;

// the next object is a heap object

CPerson* p = new CPerson( “Smith”, “Alan”, “581-0215” );

#ifdef _DEBUG

newMemState.Checkpoint();

if( diffMemState.Difference( oldMemState, newMemState ) )

{

TRACE( “Memory leaked!\n” );

diffMemState.DumpStatistics();

//or diffMemState.DumpAllObjectsSince();

}

#endif

MFC在应用程序（调试版）结束时，自动进行内存漏洞检测，如果存在漏洞，则输出漏洞的有关信息。

MFC下的文件类

文件操作的方法

使用Visual C++编程，有如下方法进行文件操作：

（1）使用标准C运行库函数，包括fopen、fclose、fseek等。

（2）使用Win16下的文件和目录操作函数，如lopen、lclose、lseek等。不过，在Win32下，这些函数主要是为了和Win16向后兼容。

（3）使用Win32下的文件和目录操作函数，如CreateFile，CopyFile，DeleteFile，FindNextFile，等等。

Win32下，打开和创建文件都由CreateFile完成，成功的话，得到一个Win32下的句柄，这不同于“C”的fopen返回的句柄。在Win16下，该句柄和C运行库文件操作函数相容。但在Win32下，“C”的文件操作函数不能使用该句柄，如果需要的话，可以使用函数_open_osfhandle从Win32句柄得到一个“C”文件函数可以使用的文件句柄。

关闭文件使用Win32的CloseHandle。

在Win32下，CreateFile可以操作的对象除了磁盘文件外，还包括设备文件如通讯端口、管道、控制台输入、邮件槽等等。

（4）使用CFile和其派生类进行文件操作。CFile从CObject派生，其派生类包括操作文本文件的CStdioFile，操作内存文件的CmemFile，等等。

CFile是建立在Win32的文件操作体系的基础上，它封装了部分Win32文件操作函数。

最好是使用CFile类（或派生类）的对象来操作文件，必要的话，可以从这些类派生自己的文件操作类。统一使用CFile的界面可以得到好的移植性。

MFC的文件类

MFC用一些类来封装文件访问的Win32 API。以CFile为基础，从CFile派生出几个类，如CStdioFile，CMemFile，MFC内部使用的CMiororFile，等等。

CFile的结构

CFile定义的枚举类型

CFile类定义了一些和文件操作相关的枚举类型，主要有四种：OpenFlags，Attribute，SeekPosition，hFileNull。下面，分别解释这些枚举类型。

OpenFlags

OpenFlags定义了13种文件访问和共享模式：

enum OpenFlags {

//第一（从右，下同）至第二位，打开文件时访问模式，读/写/读写

modeRead = 0x0000,

modeWrite = 0x0001,

modeReadWrite = 0x0002,

shareCompat = 0x0000, //32位MFC中没用

//第五到第七位，打开文件时的共享模式

shareExclusive = 0x0010,//独占方式，禁止其他进程读写

shareDenyWrite = 0x0020,//禁止其他进程写

shareDenyRead = 0x0030,//禁止其他进程读

shareDenyNone = 0x0040,//允许其他进程写

//第八位，打开文件时的文件继承方式

modeNoInherit = 0x0080,//不允许子进程继承

//第十三、十四位，是否创建新文件和创建方式

modeCreate = 0x1000,//创建新文件，文件长度0

modeNoTruncate = 0x2000,//创建新文件时如文件已存在则打开

//第十五、十六位，文件以二进制或者文本方式打开，在派生类CStdioFile中用

typeText = 0x4000,

typeBinary = (int)0x8000

};

Attribute

Attribute定义了文件属性：正常、只读、隐含、系统文件，文件或者目录等。

enum Attribute {

normal = 0x00,

readOnly = 0x01,

hidden = 0x02,

system = 0x04,

volume = 0x08,

directory = 0x10,

archive = 0x20

}

SeekPosition

SeekPosition定义了三种文件位置：头、尾、当前：

enum SeekPosition{

begin = 0x0,

current = 0x1,

end = 0x2

};

hFileNull

hFileNull定义了空文件句柄

enum { hFileNull = -1 };

CFile的其他一些成员变量

CFile除了定义枚举类型，还定义了一些成员变量。例如：

UINT m_hFile

该成员变量是public访问属性，保存::CreateFile返回的操作系统的文件句柄。MFC重载了运算符号HFILE来返回m_hFile，这样在使用HFILE类型变量的地方可以使用CFile对象。

BOOL m_bCloseOnDelete;

CString m_strFileName;

这两个成员变量是protected访问属性。m_bCloseOnDelete用来指示是否在关闭文件时删除CFile对象；m_strFileName用来保存文件名。

CFile的成员函数

CFile的成员函数实现了对Win32文件操作函数的封装，完成以下动作：打开、创建、关闭文件，文件指针定位，文件的锁定与解锁，文件状态的读取和修改，等等。其中，用到了m_hFile文件句柄的一般是虚拟函数，和此无关的一般是静态成员函数。一般地，成员函数被映射到对应的Win32函数，如表11-1所示。

表11-1 CFile函数对Win32文件函数的封装

虚拟	静态	成员函数	对应的Win32函数
文件的创建、打开、关闭
√		Abort	CloseHandle
√		Duplicate	DuplicateHandle
√		Open	CreateFile
√		Close	CloseHandle
文件的读写
√		Read	ReadFile
		ReadHuge（向后兼容）	调用Read成员函数
√		Write	WriteFile
		WriteHuage(向后兼容)	调用Write成员函数
√		Flush	FlushFileBuffers
文件定位
√		Seek	SetFilePointer
		SeekToBegin	调用Seek成员函数
		SeekToEnd	调用Seek成员函数
√		GetLength	调用Seek成员函数
√		SetLength	SetEndOfFile
文件的锁定/解锁
√		LockRange	LockFile
√		UnlockRange	UnlockFile
文件状态操作函数
√		GetPosition	SetFilePointer
		GetStatus(CFileStatus&)	GetFileTime,GetFileSize等
	√	GetStatus(LPSTR lpszFileName CFileStatus&)	FindFirstFile
√		GetFileName	不是简单地映射到某个函数
√		GetFileTitle
√		GetFilePath
√		SetFilePath
	√	SetStatus
改名和删除
	√	Rename	MoveFile
	√	Remove	DeleteFile

CFile的部分实现

这里主要讨论CFile对象的构造函数和文件的打开/创建的过程。

构造函数

CFile有如下几个构造函数：

CFile()

缺省构造函数，仅仅构造一个CFile对象，还必须使用Open成员函数来打开文件。

CFile(int hFile)

已经打开了一个文件hFile，在此基础上构造一个CFile对象来给它打包。HFile将被赋值给CFile的成员变量m_hFile。

CFile(LPCTSTR lpszFileName, UINT nOpenFlags)

指定一个文件名和文件打开方式，构造CFile对象，调用Open打开/创建文件，把文件句柄保存到m_hFile。

打开/创建文件

Open的原型如下：

BOOL CFile::Open(LPCTSTR lpszFileName, UINT nOpenFlags,

CFileException* pException)

Open调用Win32函数::CreateFile打开文件，并把文件句柄保存到成员变量m_hFile中。

CreateFile函数的原型如下：

HANDLE CreateFile(

LPCTSTR lpFileName,// pointer to name of the file

DWORD dwDesiredAccess,// access (read-write) mode

DWORD dwShareMode,// share mode

LPSECURITY_ATTRIBUTES lpSecurityAttributes, //pointer to security descriptor

DWORD dwCreationDistribution,// how to create

DWORD dwFlagsAndAttributes,// file attributes

HANDLE hTemplateFile// handle to file with attributes to copy

);

显然，Open必须把自己的两个参数lpszFileName和nOpenFlags映射到CreateFile的七个参数上。

从OpenFlags的定义可以看出，（nOpenFlags & 3)表示了读写标识，映射成变量dwAccess，可以取值为Win32的GENERIC_READ、GENERIC_WRITE、GENERIC_READ|GENERIC_WRITE。

（nOpenFlags & 0x70)表示了共享模式，映射成变量dwShareMode，可以取值为Win32的FILE_SHARE_READ、FILE_SHARE_WRITE、FILE_SHARE_WRITE|FILE_SHARE_READ。

Open定义了一个局部的SECURITY_ATTRIBUTES变量sa，(nOpenFlags & 0x80)被赋值给sa.bInheritHandle。

(nOpenFlags & modeCreate)表示了创建方式，映射成变量dwCreateFlag，可以取值为Win32的OPEN_ALWAYS、CREATE_ALWAYS、OPEN_EXISTING。

在生成了上述参数之后，先调用::CreateFile：

HANDLE hFile =::CreateFile(lpszFileName,

dwAccess, dwShareMode, &sa,

dwCreateFlag, FILE_ATTRIBUTE_NORMAL, NULL);

然后，hFile被赋值给成员变量m_hFile，m_bCloseOnDelete被设置为TRUE。

由上可以看出，CFile打开(创建)一个文件时大大简化了:: CreateFile函数的复杂性，即只需要指定一个文件名、一个打开文件的参数即可。若该参数指定为0，则表示以只读方式打开一个存在的文件，独占使用，不允许子进程继承。

在CFile对象使用时，如果它是在堆中分配的，则应该销毁它；如果在栈中分配的，则CFile对象将被自动销毁。销毁时析构函数被调用，析构函数是虚拟函数。若m_bCloseOnDelete为真且m_hFile非空，则析构函数调用Close关闭文件。

至于其他CFile成员函数的实现，这里不作分析了。

CFile的派生类

这里主要简要地介绍CStdioFile和CmemFile及CFileFind。

CStdioFile

CStdioFile对文本文件进行操作。

CStdioFile定义了新的成员变量m_pStream，类型是FILE*。在打开或者创建文件时，使用_open_osfhandle从m_hFile(Win32文件句柄)得到一个“C”的FILE类型的文件指针，然后，在文件操作中，使用“C”的文件操作函数。例如，读文件使用_fread，而不是::ReadFile，写文件使用了_fwrite，而不是::WriteFile，等等。m_hFile是CFile的成员变量。

另外，CStdioFile不支持CFile的Dumplicate、LockRange、UnlockRange操作，但是实现了两个新的操作ReadString和WriteString。

CMemFile

CMemFile把一块内存当作一个文件来操作，所以，它没有打开文件的操作，而是设计了Attach和Detach用来分配或者释放一块内存。相应地，它提供了Alloc、Free虚拟函数来操作内存文件，它覆盖了Read、Write来读写内存文件。

CFileFind

为了方便文件查找，MFC把有关功能归结成为一个类CFileFind。CFileFind派生于CObject类。首先，它使用FindFile和FineNextFile包装了Win32函数::FindFirstFile和::FindNextFile；其次，它提供了许多函数用来获取文件的状态或者属性。

使用CFileStatus结构来描述文件的属性，其定义如下：

struct CFileStatus

{

CTime m_ctime; // 文件创建时间

CTime m_mtime; // 文件最近一次修改时间

CTime m_atime; // 文件最近一次访问时间

LONG m_size; // 文件大小

BYTE m_attribute; // 文件属性

BYTE _m_padding; // 没有实际含义，用来增加一个字节

TCHAR m_szFullName[_MAX_PATH]; //绝对路径

#ifdef _DEBUG

//实现Dump虚拟函数，输出文件属性

void Dump(CDumpContext& dc) const;

#endif

};

例如：

CFileStatus status;

pFile->GetStatus(status);

#ifdef _DEBUG

status.dump(afxDump);

#endif

对话框和对话框类CDialog

对话框经常被使用，因为对话框可以从模板创建，而对话框模板是可以使用资源编辑器方便地进行编辑的。

模式和无模式对话框

对话框分两种类型，模式对话框和无模式对话框。

模式对话框

一个模式对话框是一个有系统菜单、标题栏、边线等的弹出式窗口。在创建对话框时指定WS_POPUP, WS_SYSMENU, WS_CAPTION和 DS_MODALFRAME风格。即使没有指定WS_VISIBLE风格，模式对话框也会被显示。

创建对话框窗口时，将发送WM_INITDIALOG消息（如果指定对话框的DS_SETFONT风格，还有WM_SETFONT消息）给对话框过程。

对话框过程(Dialog box procedure)不是对话框窗口的窗口过程(Window procedure)。在Win32里，对话框的窗口过程由Windows系统提供，用户在创建对话框窗口时提供一个对话框过程由窗口过程调用。

对话框窗口被创建之后，Windows使得它成为一个激活的窗口，它保持激活直到对话框过程调用::EndDialog函数结束对话框的运行或者Windows激活另一个应用程序为止，在激活时，用户或者应用程序不可以激活它的所属窗口（Owner window）。

从某个窗口创建一个模式对话框时，Windows自动地禁止使用（Disable）这个窗口和它的所有子窗口，直到该模式对话框被关闭和销毁。虽然对话框过程可以Enable所属窗口，但是这样做就失去了模式对话框的作用，所以不鼓励这样做。

Windows创建模式对话框时，给当前捕获鼠标输入的窗口（如果有的话）发送消息WM_CANCLEMODE。收到该消息后，应用程序应该终止鼠标捕获(Release the mouse capture)以便于用户能把鼠标移到模式对话框；否则由于Owner窗口被禁止，程序将失去鼠标输入。

为了处理模式对话框的消息，Windows开始对话框自身的消息循环，暂时控制整个应用程序的消息队列。如果Windows收到一个非对话框消息时，则它把消息派发给适当的窗口处理；如果收到了WM_QUIT消息，则把该消息放回应用程序的消息队列里，这样应用程序的主消息循环最终能处理这个消息。

当应用程序的消息队列为空时，Windows发送WM_ENTERIDLE消息给Owner窗口。在对话框运行时，程序可以使用这个消息进行后台处理，当然应该注意经常让出控制给模式对话框，以便它能接收用户输入。如果不希望模式对话框发送WM_ENTERIDlE消息，则在创建模式对话框时指定DS_NOIDLEMSG风格。

一个应用程序通过调用::EndDialog函数来销毁一个模式对话框。一般情况下，当用户从系统菜单里选择了关闭（Close）命令或者按下了确认（OK）或取消（CANCLE）按钮，::EndDialog被对话框过程所调用。调用::EndDialog时，指定其参数nResult的值，Windows将在销毁对话框窗口后返回这个值，一般，程序通过返回值判断对话框窗口是否完成了任务或者被用户取消。

无模式对话框

一个无模式对话框是一个有系统菜单、标题栏、边线等的弹出式窗口。在创建对话框模板时指定WS_POPUP、WS_CAPTION、WS_BORDER和WS_SYSMENU风格。如果没有指定WS_VISIBLE风格，无模式对话框不会自动地显示出来。

一个无模式对话框既不会禁止所属窗口，也不会给它发送消息。当创建一个模式对话框时，Windows使它成为活动窗口，但用户或者程序可以随时改变和设置活动窗口。如果对话框失去激活，那么即使所属窗口是活动的，在Z轴顺序上，它仍然在所属窗口之上。

应用程序负责获取和派发输入消息给对话框。大部分应用程序使用主消息循环来处理，但是为了用户可以使用键盘在控制窗口之间移动或者选择控制窗口，应用程序应该调用::IsDialogMessage函数。

这里，顺便解释::IsDialogMessage函数。虽然该函数是为无模式对话框设计的，但是任何包含了控制子窗口的窗口都可以调用它，用来实现类似于对话框的键盘选择操作。

当::IsDialogMessage处理一个消息时，它检查键盘消息并把它们转换成相应对话框的选择命令。例如，当Tab 键被压下时，下一个或下一组控制被选中，当Down Arrow键按下后，一组控制中的下一个控制被选择。

::IsDialogMessage完成了所有必要的消息转换和消息派发，所以该函数处理的消息一定不要传递给TranslateMessage和DispatchMessage处理。

一个无模式对话框不能像模式对话框那样返回一个值给应用程序。但是对话框过程可以使用::SendMessage给所属窗口传递信息。

在应用程序结束之前，它必须销毁所有的无模式对话框。使用::DestroyWindow销毁一个无模式对话框，不是使用::EndDiaLog。一般来说，对话框过程响应用户输入，如用户选择了“取消”按钮，则调用::DestroyWindow；如果用户没有有关动作，则应用程序必须调用::DestroyWindow。

对话框的MFC实现

在MFC中，对话框窗口的功能主要由CWnd和CDialog两个类实现。

CDialog的设计和实现

MFC通过CDialog来封装对话框的功能。CDialog从CWnd继承了窗口类的功能（包括CWnd实现的有关功能），并添加了新的成员变量和函数来处理对话框。

CDialog的成员变量

CDialog的成员变量有：

protected:

UINT m_nIDHelp; // Help ID (0 for none, see HID_BASE_RESOURCE)

LPCTSTR m_lpszTemplateName; // name or MAKEINTRESOURCE

HGLOBAL m_hDialogTemplate; // indirect (m_lpDialogTemplate == NULL)

// indirect if (m_lpszTemplateName == NULL)

LPCDLGTEMPLATE m_lpDialogTemplate;

void* m_lpDialogInit; // DLGINIT resource data

CWnd* m_pParentWnd; // parent/owner window

HWND m_hWndTop; // top level parent window (may be disabled)

成员变量保存了创建对话框的模板资源、对话框父窗口对象、顶层窗口句柄等信息。三个关于模板资源的成员变量m_lpszTemplateName、m_hDialogTemplate、m_lpDialogTemplate对应了三种模板资源，但在创建对话框时，只要一个模板资源就可以了，可以使用其中的任意一类。

CDialog的成员函数：

构造函数：

CDialog( LPCTSTR lpszTemplateName, CWnd* pParentWnd = NULL );

CDialog( UINT nIDTemplate, CWnd* pParentWnd = NULL );

CDialog( );

CDialog重载了三个构造函数。其中，第三个是缺省构造函数；第一个和第二个构造函数从指定的对话框模板资源创建，pParentWnd指定了父窗口或所属窗口，若空则设置父窗口为应用程序主窗口。

初始化函数

BOOL Create( LPCTSTR lpszTemplateName, CWnd* pParentWnd = NULL );

BOOL Create( UINT nIDTemplate, CWnd* pParentWnd = NULL );

BOOL CreateIndirect( LPCDLGTEMPLATE lpDialogTemplate, CWnd* pParentWnd = NULL );

BOOL CreateIndirect( HGLOBAL hDialogTemplate, CWnd* pParentWnd = NULL );

BOOL InitModalIndirect( LPCDLGTEMPLATE lpDialogTemplate, CWnd* pParentWnd = NULL );

BOOL InitModalIndirect( HGLOBAL hDialogTemplate, CWnd* pParentWnd = NULL );

Create用来根据模板创建无模式对话框；CreateInDirect用来根据内存中的模板创建无模式对话框；InitModalIndirect用来根据内存中的模板创建模式对话框。它们都提供了两个重载版本。

对话框操作函数

void MapDialogRect( LPRECT lpRect ) const;

void NextDlgCtrl( ) const;

void PrevDlgCtrl( ) const;

void GotoDlgCtrl( CWnd* pWndCtrl );

void SetDefID( UINT nID );

void SetHelpID( UINT nIDR );

void EndDialog( int nResult );

虚拟函数

virtual int DoModal( );

virtual BOOL OnInitDialog( );

virtual void OnSetFont( CFont* pFont );

virtual void OnOK( );

virtual void OnCancel( );

MFC模式对话框的实现

从前面的介绍可以知道，Win32 SDK编程下的模式对话框使用了Windows提供给对话框窗口的窗口过程和自己的对话框过程，对话框过程将被窗口过程调用。但在MFC下，所有的窗口类都使用了同一个窗口过程，CDialog也不例外。CDialog对象在创建Windows对话框时，采用了类似于CWnd的创建函数过程，采用子类化的手段将Windows提供给对话框的窗口过程取代为AfxWndProc或者AfxBaseWndProc，同时提供了对话框过程AfxDlgProc。那么，这些“过程”是如何实现或者协调的呢？下文将予以分析。

MFC对话框过程

MFC对话框过程AfxDlgProc的原型和实现如下：

BOOL CALLBACK AfxDlgProc(HWND hWnd,

UINT message, PARAM, LPARAM)

{

if (message == WM_INITDIALOG)

{

//处理WM_INITDIALOG消息

CDialog* pDlg = DYNAMIC_DOWNCAST(CDialog,

CWnd::FromHandlePermanent(hWnd));

if (pDlg != NULL)

return pDlg->OnInitDialog();

else

return 1;

}

return 0;

}

由上可以看出，MFC的对话框函数AfxDlgProc仅处理消息WM_INITDIALOG，其他都留给对话框窗口过程处理。因此，它不同于SDK编程的对话框过程。程序员在SDK的对话框过程处理消息和事件，实现自己的对话框功能。

AfxDlgProc处理WM_INITDIALOG消息时调用虚拟函数OnInitDialog，给程序员一个机会处理对话框的初始化。

模式对话框窗口过程

本小节讨论对话框的窗口过程。

AfxWndProc是所有的MFC窗口类使用的窗口过程，它取代了模式对话框原来的窗口过程（Windows提供），那么，MFC如何完成Win32下对话框窗口的功能呢？

考查模式对话框的创建过程。CDialog::DoModal用来创建模式对话框窗口并执行有关任务，和DoModal相关的是MFC内部使用的成员函数CDialog::PreModal和CDialog::PostModal。下面分别讨论它们的实现。

HWND CDialog::PreModal()

{

// cannot call DoModal on a dialog already constructed as modeless

ASSERT(m_hWnd == NULL);

// allow OLE servers to disable themselves

AfxGetApp()->EnableModeless(FALSE);

// 得到父窗口

CWnd* pWnd = CWnd::GetSafeOwner(m_pParentWnd, &m_hWndTop);

// 如同CWnd处理其他窗口的创建，设置一个窗口创建HOOK

AfxHookWindowCreate(this);

//返回父窗口的句柄

return pWnd->GetSafeHwnd();

}

void CDialog::PostModal()

{

//取消窗口创建前链接的HOOK

AfxUnhookWindowCreate(); // just in case

//MFC对话框对象和对应的Windows对话框窗口分离

Detach(); // just in case

// m_hWndTop是当前对话框的父窗口或所属窗口，则恢复它

if (::IsWindow(m_hWndTop))

::EnableWindow(m_hWndTop, TRUE);

m_hWndTop = NULL;

AfxGetApp()->EnableModeless(TRUE);

}

int CDialog::DoModal()

{

// can be constructed with a resource template or InitModalIndirect

ASSERT(m_lpszTemplateName != NULL ||

m_hDialogTemplate != NULL || m_lpDialogTemplate != NULL);

//加载对话框资源

LPCDLGTEMPLATE lpDialogTemplate = m_lpDialogTemplate;

HGLOBAL hDialogTemplate = m_hDialogTemplate;

HINSTANCE hInst = AfxGetResourceHandle();

//查找资源（见9.5.2节），找到了就加载它

if (m_lpszTemplateName != NULL)

{

hInst = AfxFindResourceHandle(m_lpszTemplateName, RT_DIALOG);

HRSRC hResource =

::FindResource(hInst, m_lpszTemplateName, RT_DIALOG);

hDialogTemplate = LoadResource(hInst, hResource);

}

//锁定加载的资源

if (hDialogTemplate != NULL)

lpDialogTemplate = (LPCDLGTEMPLATE)LockResource(hDialogTemplate);

// return -1 in case of failure to load the dialog template resource

if (lpDialogTemplate == NULL)

return -1;

//创建对话框前禁止父窗口，为此要调用PreModal得到父窗口句柄

HWND hWndParent = PreModal();

AfxUnhookWindowCreate();

CWnd* pParentWnd = CWnd::FromHandle(hWndParent);

BOOL bEnableParent = FALSE;

if (hWndParent != NULL && ::IsWindowEnabled(hWndParent))

{

::EnableWindow(hWndParent, FALSE);

bEnableParent = TRUE;

}

//创建对话框，注意是无模式对话框

TRY

{

//链接一个HOOK到HOOK链以处理窗口创建，

//如同4.4.1节描述的CWnd类窗口创建一样

AfxHookWindowCreate(this);

//CreateDlgIndirect间接调用::CreateDlgIndirect，

//最终调用了::CreateWindowEX来创建对话框窗口。

//HOOK过程_AfxCbtFilterHook用子类化的方法

//取代原来的窗口过程为AfxWndProc。

if (CreateDlgIndirect(lpDialogTemplate, CWnd::FromHandle(hWndParent), hInst))

{

if (m_nFlags & WF_CONTINUEMODAL)

{

// enter modal loop

DWORD dwFlags = MLF_SHOWONIDLE;

//RunModalLoop接管整个应用程序的消息处理

if (GetStyle() & DS_NOIDLEMSG)

dwFlags |= MLF_NOIDLEMSG;

VERIFY(RunModalLoop(dwFlags) == m_nModalResult);

}

// hide the window before enabling the parent, etc.

if (m_hWnd != NULL)

SetWindowPos(NULL, 0, 0, 0, 0, SWP_HIDEWINDOW|

SWP_NOSIZE|SWP_NOMOVE|

SWP_NOACTIVATE|SWP_NOZORDER);

}

CATCH_ALL(e)

{

DELETE_EXCEPTION(e);

m_nModalResult = -1;

}

END_CATCH_ALL

//Enable并且激活父窗口

if (bEnableParent)

::EnableWindow(hWndParent, TRUE);

if (hWndParent != NULL && ::GetActiveWindow() == m_hWnd)

::SetActiveWindow(hWndParent);

//::EndDialog仅仅关闭了窗口，现在销毁窗口

DestroyWindow();

PostModal();

// 必要的话，解锁/释放资源

if (m_lpszTemplateName != NULL || m_hDialogTemplate != NULL)

UnlockResource(hDialogTemplate);

if (m_lpszTemplateName != NULL)

FreeResource(hDialogTemplate);

return m_nModalResult;

}

从DoModal的实现可以看出：

它首先Disable对话框窗口的父窗口；然后使用::CreateIndrectDialog创建对话框窗口，使用子类化的方法用AfxWndProc（或者AfxBaseProc）替换了原来的窗口过程，并把原来的窗口过程保存在CWnd的成员变量m_pfnSuper中。原来的窗口过程就是::DialogBox等创建对话框窗口时指定的，是Windows内部提供的对话框“窗口类”的窗口过程。取代(Subclass)原来“窗口类”的窗口过程的方法如同 4.4.1节描述的CWnd::Create。

在::CreateIndirectDialog创建对话框窗口后，会发送WM_INITDIALOG消息给对话框的对话框过程（必要的话，还有WM_SETFONT消息）。但是MFC取代了原来的对话框窗口过程，这两个消息如何送给对话框过程呢？处理方法如下节所描述。

使用原对话框窗口过程作消息的缺省处理

对话框的消息处理过程和其他窗口并没有什么不同。这里主要分析的是如何把一些消息传递给对话框原窗口过程处理。下面，通过解释MFC对WM_INITDIALOG消息的处理来解释MFC窗口过程和原对话框窗口过程的关系及其协调作用。

MFC提供了WM_INITDIALOG消息的处理函数CDialog::HandleInitDialog，WM_INITDIALOG消息按照标准Windows的处理送给HandleInitDialog处理。

HandleInitDialog调用缺省处理过程Default，导致CWnd的Default函数被调用。CWnd::Default的实现如下：

LRESULT CWnd::Default()

{

// call DefWindowProc with the last message

_AFX_THREAD_STATE* pThreadState = _afxThreadState.GetData();

return DefWindowProc(pThreadState->m_lastSentMsg.message,

pThreadState->m_lastSentMsg.wParam,

pThreadState->m_lastSentMsg.lParam);

}

顺便指出，从Default的实现可以看出线程状态的一个用途：它把本线程最新收到和处理的消息记录在成员变量m_lastSentMsg中。

在Default的实现中，CWnd的DefWindowsProc被调用，其实现如下：

LRESULT CWnd::DefWindowProc(UINT nMsg,

WPARAM wParam, LPARAM lParam)

{

//若“窗口超类（SuperClass）”的窗口过程m_pfnSuper非空，则调用它

if (m_pfnSuper != NULL)

return ::CallWindowProc(m_pfnSuper, m_hWnd, nMsg, wParam, lParam);

//在MFC中，GetSuperWndProcAddr的作用就是返回m_pfnSuper，为什么还

//要再次调用呢？因为虽然该函数现在是Obsolete，但原来曾经是有用的。如

//果返回非空，就调用该窗口过程进行处理，否则，由Windows进行缺省处理。

WNDPROC pfnWndProc;

if ((pfnWndProc = *GetSuperWndProcAddr()) == NULL)

return ::DefWindowProc(m_hWnd, nMsg, wParam, lParam);

else

return ::CallWindowProc(pfnWndProc, m_hWnd, nMsg, wParam, lParam);

}

综合上述分析，HandleInitDialog最终调用了窗口过程m_pfnSuper，即Windows提供给“对话框窗口类”的窗口过程，于是该窗口过程调用了对话框过程AfxDlgProc，导致虚拟函数OnInitDialog被调用。

顺便提一下，CWnd::AfxCallWndProc在处理WM_INITDIALOG消息之前和之后都会有一些特别的处理，如尝试把对话框放到屏幕中间。具体实现这里略。

OnInitDialog的MFC缺省实现主要完成三件事情：

调用ExecInitDialog初始化对话框中的控制；调用UpdateData初始化对话框控制中的数据；确定是否显示帮助按钮。所以，程序员覆盖该函数时，一定要调用基类的实现。

MFC采用子类化的方法取代了对话框的窗口过程，实现了12.1节描述的模式对话框窗口的一些特性，原来SDK下对话框过程要处理的东西大部分转移给MFC窗口过程处理，如处理控制窗口的控制通知消息等。如果不能处理或者必须借助于原来的窗口过程的，则通过缺省处理函数Default传递给原来的窗口过程处理，如同这里对WM_INITDIALOG的处理一样。

Dialog命令消息和控制通知消息的处理

通过覆盖CWnd的命令消息发送函数OnCmdMsg，CDialog实现了自己的命令消息发送路径。在4.4.3.3节，曾经分析了CDialog::OnCmdMsg函数，这里给出其具体实现：

BOOL CDialog::OnCmdMsg(UINT nID, int nCode, void* pExtra,

AFX_CMDHANDLERINFO* pHandlerInfo)

{

//首先，让对话框窗口自己或者基类处理

if (CWnd::OnCmdMsg(nID, nCode, pExtra, pHandlerInfo))

return TRUE;

//如果还未处理，且是控制通知消息或者状态更新消息或者系统命令

//则停止进一步的发送

if ((nCode != CN_COMMAND && nCode != CN_UPDATE_COMMAND_UI) ||

!IS_COMMAND_ID(nID) || nID >= 0xf000)

{

return FALSE; // not routed any further

}

//尝试给父窗口处理

CWnd* pOwner = GetParent();

if (pOwner != NULL)

{

#ifdef _DEBUG

if (afxTraceFlags & traceCmdRouting)

TRACE1(“Routing command id 0x%04X to owner window.\n”, nID);

#endif

ASSERT(pOwner != this);

if (pOwner->OnCmdMsg(nID, nCode, pExtra, pHandlerInfo))

return TRUE;

}

// 最后，给当前线程对象处理

CWinThread* pThread = AfxGetThread();

if (pThread != NULL)

{

#ifdef _DEBUG

if (afxTraceFlags & traceCmdRouting)

TRACE1(“Routing command id 0x%04X to app.\n”, nID);

#endif

if (pThread->OnCmdMsg(nID, nCode, pExtra, pHandlerInfo))

return TRUE;

}

#ifdef _DEBUG

if (afxTraceFlags & traceCmdRouting)

{

TRACE2(“IGNORING command id 0x%04X sent to %hs dialog.\n”, nID,

GetRuntimeClass()->m_lpszClassName);

}

#endif

return FALSE;

}

从上述实现可以看出，CDialog处理命令消息遵循如下顺序：

对话框自身→父窗口→线程对象

例如，模式对话框产生的WM_ENTERIDLE消息就发送给父窗口处理。

从实现中还看到，MFC根据TRACE过滤标识afxTraceFlags的值，把有关命令消息的派发显示到调试窗口。

CDialog::OnCmdMsg不仅适用于模式对话框，也适用于无模式对话框。

消息预处理和Dialog消息

另外，对话框窗口的消息处理还有一个特点，就是增加了对Dialog消息的处理，如同在介绍::IsDialogMessage函数时所述。如果是Dialog消息，MFC框架将不会让它进入下一步的消息循环。为此，MFC覆盖了CDialog的虚拟函数PreTranslateMessage，该函数的实现如下：

BOOL CDialog::PreTranslateMessage(MSG* pMsg)

{

// 用于无模式或者模式对话框的处理

ASSERT(m_hWnd != NULL);

//过滤tooltip messages

if (CWnd::PreTranslateMessage(pMsg))

return TRUE;

//在Shift+F1帮助模式下，不转换Dialog messages

CFrameWnd* pFrameWnd = GetTopLevelFrame();

if (pFrameWnd != NULL && pFrameWnd->m_bHelpMode)

return FALSE;

//处理Escape键按下的消息

if (pMsg->message == WM_KEYDOWN &&

(pMsg->wParam == VK_ESCAPE || pMsg->wParam == VK_CANCEL) &&

(::GetWindowLong(pMsg->hwnd, GWL_STYLE) & ES_MULTILINE) &&

_AfxCompareClassName(pMsg->hwnd, _T(“Edit”)))

{

HWND hItem = ::GetDlgItem(m_hWnd, IDCANCEL);

if (hItem == NULL || ::IsWindowEnabled(hItem))

{

SendMessage(WM_COMMAND, IDCANCEL, 0);

return TRUE;

}

// 过滤来自控制该对话框子窗口的送给该对话框的Dialog消息

return PreTranslateInput(pMsg);

}

从其实现可以看出，如果是Tooltip消息或者Dialog消息，这些消息将在PreTranslateMessage中被处理，不会进入消息发送的处理。

PreTranslateInput是CWnd的成员函数，它调用::IsDialogMessage函数来处理Dialog消息。

PreTranslateMessage的实现不仅用于模式对话框，而且用于无模式对话框。

模式对话框的消息循环

从DoModal的实现可以看出，DoModal调用CreateDlgIndirect创建的是无模式对话框，MFC如何来接管和控制应用程序的消息队列，实现一个模式对话框的功能呢？

CDialog调用了RunModalLoop来实现模式窗口的消息循环。RunModalLoop是CWnd的成员函数，它和相关函数的实现如下：

int CWnd::RunModalLoop(DWORD dwFlags)

{

ASSERT(::IsWindow(m_hWnd)); //窗口必须已经创建且不在模式状态 ASSERT(!(m_nFlags & WF_MODALLOOP));

// 以下变量用于Idle处理

BOOL bIdle = TRUE;

LONG lIdleCount = 0;

BOOL bShowIdle = (dwFlags & MLF_SHOWONIDLE) &&

!(GetStyle() & WS_VISIBLE);

HWND hWndParent = ::GetParent(m_hWnd);

m_nFlags |= (WF_MODALLOOP|WF_CONTINUEMODAL);

MSG* pMsg = &AfxGetThread()->m_msgCur;

//获取和派发消息直到模式状态结束

for (;;)

{

ASSERT(ContinueModal());

//第一阶段，判断是否可以进行Idle处理

while (bIdle &&!::PeekMessage(pMsg, NULL, NULL, NULL, PM_NOREMOVE))

{

ASSERT(ContinueModal());

//必要的话，当Idle时显示对话框窗口

if (bShowIdle)

{

ShowWindow(SW_SHOWNORMAL);

UpdateWindow();

bShowIdle = FALSE;

}

// 进行Idle处理

//必要的话发送WM_ENTERIDLE消息给父窗口

if (!(dwFlags & MLF_NOIDLEMSG) &&hWndParent != NULL && lIdleCount == 0)

{

::SendMessage(hWndParent, WM_ENTERIDLE,

MSGF_DIALOGBOX, (LPARAM)m_hWnd);

}

//必要的话发送WM_KICKIDLE消息给父窗口

if ((dwFlags & MLF_NOKICKIDLE) ||

!SendMessage(WM_KICKIDLE, MSGF_DIALOGBOX, lIdleCount++))

{

//终止Idle处理

bIdle = FALSE;

}

//第二阶段，发送消息

{

ASSERT(ContinueModal());

// 若是WM_QUIT消息，则发送该消息到消息队列，返回；否则发送消息。

if (!AfxGetThread()->PumpMessage())

{

AfxPostQuitMessage(0);

return -1;

}

//必要的话，显示对话框窗口

if (bShowIdle &&

(pMsg->message == 0x118 || pMsg->message == WM_SYSKEYDOWN))

{

ShowWindow(SW_SHOWNORMAL);

UpdateWindow();

bShowIdle = FALSE;

}

if (!ContinueModal())

goto ExitModal;

//在派发了“正常 ”消息后，重新开始Idle处理

if (AfxGetThread()->IsIdleMessage(pMsg))

{

bIdle = TRUE;

lIdleCount = 0;

}

} while (::PeekMessage(pMsg, NULL, NULL, NULL, PM_NOREMOVE));

}

ExitModal:

m_nFlags &= ~(WF_MODALLOOP|WF_CONTINUEMODAL);

return m_nModalResult;

}

BOOL CWnd::ContinueModal()

{

return m_nFlags & WF_CONTINUEMODAL;

}

void CWnd::EndModalLoop(int nResult)

{

ASSERT(::IsWindow(m_hWnd));

// this result will be returned from CWnd::RunModalLoop

m_nModalResult = nResult;

// make sure a message goes through to exit the modal loop

if (m_nFlags & WF_CONTINUEMODAL)

{

m_nFlags &= ~WF_CONTINUEMODAL;

PostMessage(WM_NULL);

}

和CWinThread::Run的处理过程比较，RunModalLoop也分两个阶段进行处理。不同之处在于，这里不同于Run的Idle处理，RunModalLoop是给父窗口发送WM_ENTERIDLE消息（如果需要的话）；另外，当前对话框的父窗口被Disabled，是不接收用户消息的。

RunModalLoop是一个实现自己的消息循环的示例，消息循环的条件是模式化状态没有结束。实现线程自己的消息循环见8.5.6节。

当用户按下按钮“取消”、“确定”时，将导致RunModalLoop退出消息循环，结束对话框模式状态，并调用::EndDialog关闭窗口。有关关闭对话框的处理如下：

void CDialog::EndDialog(int nResult)

{

ASSERT(::IsWindow(m_hWnd));

if (m_nFlags & (WF_MODALLOOP|WF_CONTINUEMODAL))

EndModalLoop(nResult);

::EndDialog(m_hWnd, nResult);

}

void CDialog::OnOK()

{

if (!UpdateData(TRUE)) {

TRACE0(“UpdateData failed during dialog termination.\n”);

// the UpdateData routine will set focus to correct item

return;

}

EndDialog(IDOK);

}

void CDialog::OnCancel()

{

EndDialog(IDCANCEL);

}

上述函数OnOk、OnCancle、EndDialog都可以用来关闭对话框窗口。其中：

OnOk首先进行数据交换，获取对话框中各个控制子窗口的数据，然后调用EndDialog结束对话框。

OnCancle直接EndDialog结束对话框。

EndDialog首先修改m_nFlag的值，表示结束模式循环，然后调用::EndDialog关闭对话框窗口。

对话框的数据交换

对话框数据交换指以下两种动作，或者是把内存数据写入对应的控制窗口，或者是从控制窗口读取数据并保存到内存变量中。MFC为了简化这些操作，以CDataExchange类和一些数据交换函数为基础，提供了一套数据交换和校验的机制。

数据交换的方法

首先，定义保存数据的内存变量──给对话框添加成员变量，每个控制窗口可以对应一个成员变量，或者是控制窗口类型，或者是控制窗口表示的数据的类型。例如，对于对话框的一个编辑控制窗口，可以定义一个CEdit类型的成员变量，或者一个CString类型的成员变量。

其次，覆盖对话框的虚拟函数DoDataExchange，实现数据交换和验证。

ClassWizard可以协助程序员自动地添加成员变量，修改DoDataExchange。例如，一个对话框有两个控制窗口，其中的一个编辑框表示姓名，ID是IDC_NAME，另一个编辑框表示年龄，ID是IDC_AGE，ClassWizard添加如下的成员变量：

// Dialog Data

//{{AFX_DATA(CExDialog)

enum { IDD = IDD_DIALOG2 };

CEdit m_name;

int m_iAge;

//}}AFX_DATA

使用ClassWizard添加成员变量中，一个定义为CEdit，另一个定义为int。这些定义被“//{{AFX_DATA”和“//}}AFX_DATA”引用，表示是ClassWizard添加的，程序员不必修改它们。

相应的DoDataExchange的实现如下：

void CExDialog::DoDataExchange(CDataExchange* pDX)

{

CDialog::DoDataExchange(pDX);

//{{AFX_DATA_MAP(CFtpDialog)

DDX_Control(pDX, IDC_NAME, m_name);

DDX_Text(pDX, IDC_AGE, m_nAge);

DDV_MinMaxInt(pDX, m_nAge, 1, 100);

//}}AFX_DATA_MAP

}

DDX_ Control表示把IDC_NAME子窗口的内容传输到窗口m_name，或者相反。

DDX_ Text表示把IDC_AGE子窗口的内容按整数类型保存到m_nAge，或者相反。

DDV_MinMaxInt表示m_nAge应该在1和100之间取值。

CDataExchange

上文中提到DDX_Xxxxx数据交换函数可以进行双向的数据交换，那么它们如何知道数据传输的方向呢？这通过DDX_Xxxxx函数的第一个参数pDX（也就是DoDataEx change的参数pDX）所指的CDataExchange对象来决定，pDX指向一个CdataExchange对象。CDataExchange定义如下：

class CDataExchange

{

// Attributes

public:

BOOL m_bSaveAndValidate; // TRUE 则保存和验证数据

CWnd* m_pDlgWnd; // 指向一个对话框

// Operations (for implementors of DDX and DDV procs)

HWND PrepareCtrl(int nIDC); //返回指定ID的控制窗口的句柄

HWND PrepareEditCtrl(int nIDC); //返回指定ID的编辑控制窗口句柄

void Fail(); // 用来扔出例外

#ifndef _AFX_NO_OCC_SUPPORT //OLE控制

CWnd* PrepareOleCtrl(int nIDC); // 用于对话框中的OLE控制窗口

#endif

// Implementation

CDataExchange(CWnd* pDlgWnd, BOOL bSaveAndValidate);

HWND m_hWndLastControl; // last control used (for validation)

BOOL m_bEditLastControl; // last control was an edit item

};

DoDataExchange类似于Serialize函数，CDataExchange类似于CArchive。CDataExchange使用成员变量m_pDlgWnd保存要进行数据交换的对话框，使用成员变量m_bSaveAndValidate指示数据传输的方向，如果该变量真，则从控制窗口读取数据到成员变量，如果假，则从成员变量写数据到控制窗口。

在构造一个CDataExchange对象时，将保存有关信息在对象的成员变量中。构造函数如下：

CDataExchange::CDataExchange(CWnd* pDlgWnd, BOOL bSaveAndValidate)

{

ASSERT_VALID(pDlgWnd);

m_bSaveAndValidate = bSaveAndValidate;

m_pDlgWnd = pDlgWnd;

m_hWndLastControl = NULL;

}

构造函数参数指定了进行数据交换的对话框pDlgWnd和数据传输方向bSaveAndValidate。

数据交换和验证函数

在进行数据交换或者验证时，首先使用PrePareCtrl或者PrePareEditCtrl得到控制窗口的句柄，然后使用::GetWindowsText从控制窗口读取数据，或者使用::SetWindowsText写入数据到控制窗口。下面讨论几个例子：

static void AFX_CDECL DDX_TextWithFormat(CDataExchange* pDX,

int nIDC,LPCTSTR lpszFormat, UINT nIDPrompt, …)

{

va_list pData; //用来处理个数可以变化的参数

va_start(pData, nIDPrompt);//得到参数

//得到编辑框的句柄

HWND hWndCtrl = pDX->PrepareEditCtrl(nIDC);

TCHAR szT[32];

if (pDX->m_bSaveAndValidate) //TRUE，从编辑框读出数据

{

// the following works for %d, %u, %ld, %lu

//从编辑框得到内容

::GetWindowText(hWndCtrl, szT, _countof(szT));

//转换编辑框内容为指定的格式，支持“ %d, %u, %ld, %lu”

if (!AfxSimpleScanf(szT, lpszFormat, pData))

{

AfxMessageBox(nIDPrompt);

pDX->Fail(); //数据交换失败

}

else //FALSE，写入数据到编辑框

{

//把要写的内容转换成指定格式

wvsprintf(szT, lpszFormat, pData);//不支持浮点运算

//设置编辑框的内容

AfxSetWindowText(hWndCtrl, szT);

}

va_end(pData);//结束参数分析

}

DDX_TextWithFormat用来按照一定的格式把数据写入或者读出编辑框。首先，它得到编辑框的句柄hWndCtrl，然后，根据传输方向从编辑框读出内容并转换成指定格式（读出时），或者转换内容为指定格式后写入编辑框（写入时）。本函数可以处理个数不定的参数，是多个数据交换和验证函数的基础。

void AFXAPI DDX_Text(CDataExchange* pDX, int nIDC, long& value)

{

if (pDX->m_bSaveAndValidate)

DDX_TextWithFormat(pDX, nIDC, _T(“%ld”), AFX_IDP_PARSE_INT, &value);

else

DDX_TextWithFormat(pDX, nIDC, _T(“%ld”), AFX_IDP_PARSE_INT, value);

}

上述DDX_TEXT用来在编辑框和long类型的数据成员之间交换数据。MFC提供了DDX_TEXT的多个重载函数处理编辑框和不同类型的数据成员之间的数据交换。

void AFXAPI DDX_LBString(CDataExchange* pDX, int nIDC,CString& value)

{

//得到列表框句柄

HWND hWndCtrl = pDX->PrepareCtrl(nIDC);

if (pDX->m_bSaveAndValidate)//TRUE，读取数据

{

//确定列表框当前被选择的条目

int nIndex = (int)::SendMessage(hWndCtrl, LB_GETCURSEL, 0, 0L);

if (nIndex != -1) //列表框有一个条目被选中

{

//得到当前条目的长度

int nLen = (int)::SendMessage(hWndCtrl, LB_GETTEXTLEN, nIndex, 0L);

//读取当前条目的内容到value中

::SendMessage(hWndCtrl, LB_GETTEXT, nIndex,

(LPARAM)(LPVOID)value.GetBufferSetLength(nLen));

}

else //当前列表框没有条目被选中

{

value.Empty();

}

value.ReleaseBuffer();

}

else//FALSE，写内容到列表框

{

// 把value字符串写入当前选中的条目

if (::SendMessage(hWndCtrl, LB_SELECTSTRING,

(WPARAM)-1,(LPARAM)(LPCTSTR)value) == LB_ERR)

{

// no selection match

TRACE0(“Warning: no listbox item selected.\n”);

}

DDX_LBString用来在列表框和CString类型的成员数据之间交换数据。首先，得到列表框的句柄，然后，调用Win32的列表框操作函数读取或者修改列表框的内容。

下面的DDX_Control用于得到一个有效的控制类型窗口对象(MFC对象)。

void AFXAPI DDX_Control(CDataExchange* pDX, int nIDC, CWnd& rControl)

{

if (rControl.m_hWnd == NULL) // 还没有子类化

{

ASSERT(!pDX->m_bSaveAndValidate);

//得到控制窗口句柄

HWND hWndCtrl = pDX->PrepareCtrl(nIDC);

//把hWndCtrl窗口和MFC窗口对象rControl捆绑在一起

if (!rControl.SubclassWindow(hWndCtrl))

{

ASSERT(FALSE); //不允许两次子类化

AfxThrowNotSupportedException();

}

#ifndef _AFX_NO_OCC_SUPPORT//OLE控制相关的操作

else

{

// If the control has reparented itself (e.g., invisible control),

// make sure that the CWnd gets properly wired to its control site.

if (pDX->m_pDlgWnd->m_hWnd != ::GetParent(rControl.m_hWnd))

rControl.AttachControlSite(pDX->m_pDlgWnd);

}

#endif //!_AFX_NO_OCC_SUPPORT

}

DDX_Control用来把控制窗口（Windows窗口）和一个对话框成员（MFC窗口对象）捆绑在一起，这个过程是通过SubclassWindow函数完成的。这样，程序员就可以通过成员变量来操作控制窗口，读、写、修改控制窗口的内容。

MFC还提供了许多其他数据交换函数（“DDX_”为前缀）和数据验证函数(“DDV_”为前缀)。DDV函数和DDX函数类似，这里不再多述。

程序员可以创建自己的数据交换和验证函数并使用它们，可以手工加入这些函数到DoDataExchange中，如果要Classwizard使用这些函数，可以修改DDX.CLW文件，在DDX、DDV函数入口中加入自己创建的函数。

UpdateData函数

有了数据交换类和数据交换函数，怎么来使用它们呢？MFC设计了UpdateData函数来完成上述数据交换和验证的处理。

首先，UpdateData创建CDataExchange对象，然后调用DoDataExchange函数。其实现如下：

BOOL CWnd::UpdateData(BOOL bSaveAndValidate)

{

ASSERT(::IsWindow(m_hWnd)); // calling UpdateData before DoModal?

//创建CDataChange对象

CDataExchange dx(this, bSaveAndValidate);

//防止在UpdateData期间派发通知消息给该窗口

_AFX_THREAD_STATE* pThreadState = AfxGetThreadState();

HWND hWndOldLockout = pThreadState->m_hLockoutNotifyWindow;

ASSERT(hWndOldLockout != m_hWnd); // must not recurse

pThreadState->m_hLockoutNotifyWindow = m_hWnd;

BOOL bOK = FALSE; // assume failure

TRY

{

//数据交换

DoDataExchange(&dx);

bOK = TRUE; // it worked

}

CATCH(CUserException, e)//例外

{

// validation failed – user already alerted, fall through

ASSERT(bOK == FALSE);

// Note: DELETE_EXCEPTION_(e) not required

}

AND_CATCH_ALL(e)

{

// validation failed due to OOM or other resource failure

e->ReportError(MB_ICONEXCLAMATION, FX_IDP_INTERNAL_FAILURE);

ASSERT(!bOK);

DELETE_EXCEPTION(e);

}

END_CATCH_ALL

//恢复原来的值

pThreadState->m_hLockoutNotifyWindow = hWndOldLockout;

return bOK;

}

UpdataDate根据参数创建CDataExchange对象dx，如果参数为TRUE，dx用来写数据，否则dx用来读数据；然后调用DoDataExchange进行数据交换。在数据交换期间，为了防止当前窗口接收和处理命令通知消息，在当前线程的线程状态中记录该窗口的句柄，用来防止给该窗口发送通知消息。

使用MFC的数据交换和验证机制，大大简化了程序员的工作。通常在OnInitDialog中，MFC调用UpdateData(FALSE)把数据送给控制窗口显示；在OnOk中，调用UpdateData(TRUE)从控制窗口中读取数据。

无模式对话框

CFormView是MFC使用无模式对话框的一个典型例子。CFormView是基于对话框模板创建的视，它的直接基类是CSrcollView，CSrcollView的直接基类才是CView。所以，这里先对CScorllView作一个简要的介绍。

CScrollView

CScrollView继承了CView的特性，并且增加了如下的功能：

（1）管理映射模式、窗口尺寸、视口尺寸(Map mode、Window and Viewport size)。Window and Viewport size用来完成页面空间到设备空间的转换。

（2）自动管理滚动条，响应滚动条消息。

为了实现这些功能，CScrollView覆盖CView或者CWnd的一些虚拟函数和消息处理函数，添加了一些新的函数，当然也设计了新的成员变量。

CscrollView新的成员变量

protected:

int m_nMapMode;

CSize m_totalLog; // total size in logical units (no rounding)

CSize m_totalDev; // total size in device units

CSize m_pageDev; // per page scroll size in device units

CSize m_lineDev; // per line scroll size in device units

BOOL m_bCenter; // Center output if larger than total size

BOOL m_bInsideUpdate; // internal state for OnSize callback

CScrollView新的成员函数，用来完成和滚动操作、滚动条等有关的功能

void SetScaleToFitSize(SIZE sizeTotal);

void SetScrollSizes(int nMapMode, SIZE sizeTotal,

const SIZE& sizePage = sizeDefault,

const SIZE& sizeLine = sizeDefault);

这两个函数中的尺寸大小按逻辑单位计算。

SetScaleToFitSize设置视口尺寸为当前的窗口尺寸，这样，在没有滚动条时，逻辑视的内容被放大或者缩小到正好窗口大小。

SetScrollSizes设置窗口的映射模式，窗口尺寸，页和行尺寸。sizeDefualt被定义为（0，0）。

下面几个函数用来实现滚动或者得到滚动条相关的信息

void ScrollToPosition(POINT pt); // set upper left position

void FillOutsideRect(CDC* pDC, CBrush* pBrush);

void ResizeParentToFit(BOOL bShrinkOnly = TRUE);

CPoint GetScrollPosition() const; // upper corner of scrolling

CSize GetTotalSize() const; // logical size

下面两个函数使用了设备坐标单位

CPoint GetDeviceScrollPosition() const;

void GetDeviceScrollSizes(int& nMapMode, SIZE& sizeTotal,

SIZE& sizePage, SIZE& sizeLine) const;

覆盖的消息处理函数

处理WM_SIZE的OnSize；

处理WM_HSCROLL的OnHScroll；

处理WM_VSCROLL的OnVScroll；

覆盖的虚拟函数

CWnd的CalcWindowRect

CView的OnPrepareDC、OnScroll、OnScrollBy

用于DEBUG的Dump和AssertValid

这里，覆盖的消息处理函数和虚拟函数共同完成对滚动条、滚动消息的处理。

在CSrcollView的实现涉及到许多和Windows映射模式、坐标转换等相关的函数的使用。这里，不作具体讨论。

CFormView

CFormView派生于CSrcollView，本身没有增加新的函数，但覆盖了一些基类的虚拟函数，增加了几个成员变量（以下列出的不包含OLE处理）。

增加的成员变量

LPCTSTR m_lpszTemplateName;

CCreateContext* m_pCreateContext;

HWND m_hWndFocus; // last window to have focus

m_lpszTemplateName用来保存创建视图的对话框模板的名称，_pCreateContext用来保存创建上下文，m_hWndFocus用来保存最近一次拥有焦点的控制窗口。在构造CFormView对象时，构造函数把有关信息保存到成员变量中，如下所示：

CFormView::CFormView(LPCTSTR lpszTemplateName)

{

m_lpszTemplateName = lpszTemplateName;

m_pCreateContext = NULL;

m_hWndFocus = NULL; // focus window is font

}

覆盖的虚拟函数

virtual void OnDraw(CDC* pDC); // MFC缺省处理空

virtual BOOL Create(LPCTSTR, LPCTSTR, DWORD,

const RECT&, CWnd*, UINT, CCreateContext*);

virtual BOOL PreTranslateMessage(MSG* pMsg);

virtual void OnActivateView(BOOL, CView*, CView*);

virtual void OnActivateFrame(UINT, CFrameWnd*);

创建基于对话框的视窗口，不同于创建普通视窗口（前者调用CWnd::CreateEx，后者调用CWnd::CreateDlg），故需要覆盖Create虚拟函数。

覆盖PreTranslateMessage是为了过滤对话框消息，把一些消息让CFormView对象来处理。

覆盖了两个消息处理函数：

afx_msg int OnCreate(LPCREATESTRUCT lpcs);

afx_msg void OnSetFocus(CWnd* pOldWnd);

下面，分析几个函数作。Create函数解释了MFC如何使用一个对话框作为视的方法，PreTranslateMessage显示了CFormView不同于CDialog的实现。

CFormView的创建

设计CFormView的创建函数，必须考虑两个问题：

首先，CFormView是一个视，其创建函数必须是一个虚拟函数，原型必须和CWnd::Create(LPSTR…pContext)函数一致，见图5-13视的创建。其次，CFormView使用了对话框创建函数和对话框“窗口类”来创建视，但必须作一些处理使得该窗口具备视的特征。

Create的实现如下：

BOOL CFormView::Create(LPCTSTR /*lpszClassName*/,

LPCTSTR /*lpszWindowName*/,

DWORD dwRequestedStyle, const RECT& rect, CWnd* pParentWnd, UINT nID,

CCreateContext* pContext)

{

ASSERT(pParentWnd != NULL);

ASSERT(m_lpszTemplateName != NULL);

m_pCreateContext = pContext; // save state for later OnCreate

#ifdef _DEBUG

// dialog template must exist and be invisible with WS_CHILD set

if (!_AfxCheckDialogTemplate(m_lpszTemplateName, TRUE))

{

ASSERT(FALSE); // invalid dialog template name

PostNcDestroy(); // cleanup if Create fails too soon

return FALSE;

}

#endif //_DEBUG

//若common control window类还没有注册，则注册

VERIFY(AfxDeferRegisterClass(AFX_WNDCOMMCTLS_REG));

// call PreCreateWindow to get prefered extended style

CREATESTRUCT cs; memset(&cs, 0, sizeof(CREATESTRUCT));

if (dwRequestedStyle == 0)

dwRequestedStyle = AFX_WS_DEFAULT_VIEW;

cs.style = dwRequestedStyle;

if (!PreCreateWindow(cs))

return FALSE;

//::CreateDialogIndirect间接被调用来创建一个无模式对话框

if (!CreateDlg(m_lpszTemplateName, pParentWnd))

return FALSE;

//创建对话框时，OnCreate被调用，m_pCreateContext的作用结束了

m_pCreateContext = NULL;

// we use the style from the template – but make sure that

// the WS_BORDER bit is correct

// the WS_BORDER bit will be whatever is in dwRequestedStyle

ModifyStyle(WS_BORDER|WS_CAPTION, cs.style & (WS_BORDER|WS_CAPTION));

ModifyStyleEx(WS_EX_CLIENTEDGE, cs.dwExStyle & WS_EX_CLIENTEDGE);

SetDlgCtrlID(nID);

CRect rectTemplate;

GetWindowRect(rectTemplate);

SetScrollSizes(MM_TEXT, rectTemplate.Size());

// initialize controls etc

if (!ExecuteDlgInit(m_lpszTemplateName))

return FALSE;

// force the size requested

SetWindowPos(NULL, rect.left, rect.top,

rect.right – rect.left, rect.bottom – rect.top,

SWP_NOZORDER|SWP_NOACTIVATE);

// make visible if requested

if (dwRequestedStyle & WS_VISIBLE)

ShowWindow(SW_NORMAL);

return TRUE;

}

从Create的实现过程可以看出，CreateDialog在创建对话框时使用了Windows预定义的对话框“窗口类”，PreCreateWindow返回的cs在创建对话框窗口时并没有得到体现，所以在CFormView::Create调用PreCreateWindow让程序员修改“窗口类”的风格之后，还要调用ModifyStyle和ModifyStyleEx来按PreCreateWindow返回的cs的值修改窗口风格。

回顾视窗口的创建过程，Create函数被CFrameWnd::CreateView所调用，参数nID取值AFX_IDW_PANE_FIRST。由于CreateDlg设置对话框窗口的ID为对话框模板的ID，所以需要调用函数SetDlgCtrlID(nID)设置视窗口ID为nID(即AFX_IDW_PANE_FIRST)。

由于CFormView是从CScrollView继承，所以调用SetScrollSize设置映射模式，窗口尺寸等。

完成上述动作之后，初始化对话框的控制子窗口。

最后，必要的话，显示视窗口。

这样，一个无模式对话框被创建，它被用作当前MDI窗口或者MDI子窗口的视。如同CDialog的消息处理一样，必要时，消息或者事件将传递给视原来的窗口过程(无模式对话框的原窗口过程)处理，其他的消息处理和通常视一样。

由于是调用对话框创建函数创建视窗口，所以不能向::CreateWindowEX传递创建上下文指针，于是把它保存到成员变量m_pCreateContext中，在OnCreate时使用。OnCreate的实现如下：

int CFormView::OnCreate(LPCREATESTRUCT lpcs)

{

//既然不能通过CreateDialog使用参数传递的方法得到创建上下文

//参数，则使用一个成员变量来传递

return CScrollView::OnCreate(lpcs);

}

CFormView的消息预处理

现在，讨论CFormView 的PreTranslateMessage函数。CDialog覆盖函数PreTranslateMessage的主要目的是处理Tooltip消息、Escape键盘消息和Dialog消息。CFormView覆盖该函数的目的是处理Tooltip消息和Dialog消息。CFormView和CDialog不同之处在于CFormView是一个视，故在把键盘消息当Dialog消息处理之前，必须优先让其父窗口检查按下的键是否是快捷键。PreTranslateMessage函数实现如下：

BOOL CFormView::PreTranslateMessage(MSG* pMsg)

{

ASSERT(pMsg != NULL);

ASSERT_VALID(this);

ASSERT(m_hWnd != NULL);

//过滤Tooltip消息

if (CView::PreTranslateMessage(pMsg))

return TRUE;

//SHIFT+F1上下文帮助模式下，不处理Dialog消息

CFrameWnd* pFrameWnd = GetTopLevelFrame();

if (pFrameWnd != NULL && pFrameWnd->m_bHelpMode)

return FALSE;

//既然IsDialogMessage将把窗口快捷键解释成Dialog消息

//所以在此先调用所有父边框窗口的消息预处理函数

pFrameWnd = GetParentFrame(); // start with first parent frame

while (pFrameWnd != NULL)

{

// allow owner & frames to translate before IsDialogMessage does

if (pFrameWnd->PreTranslateMessage(pMsg))

return TRUE;

// try parent frames until there are no parent frames

pFrameWnd = pFrameWnd->GetParentFrame();

}

// 过滤来自子窗口的消息或者给对话框的消息

return PreTranslateInput(pMsg);

}

由于CFormView是一个视，不是模式对话框，所以它首先要把消息给父窗口（MDI子窗口或者MDI窗口）预处理，如果它们不能处理，则调用PreTranslateInput来过滤Dialog消息。

CFormView的输入焦点

CFormView另一个特性是：在和用户交互中，如果用户离开视窗口，则必须保存CFormView视的哪个控制子窗口拥有输入焦点，以便在重新激活视窗口时，原来的那个窗口重新获得输入焦点。所以，CFormView覆盖了虚拟函数OnActivateView和OnActiveFrame，以便在视窗口失去激活时把它的当前输入焦点保存到成员变量m_hWndFocus中。

为了在适当时候恢复输入焦点，CFormView覆盖了消息处理函数OnSetFocus，以便在视获得输入焦点时把输入焦点传递给m_hWndFocus（如果非空）。

至此，MFC实现对话框的处理分析完毕。

在后面要讨论的工具条等控制窗口，类似于对话框也具备由Windows提供的窗口过程，MFC在SDK的特定控制窗口创建函数的基础上，提供了MFC的窗口创建函数，使用MFC的窗口过程取代了它们原来的窗口过程，然后在必要的时候调用Default把有关消息和事件传递给原来的窗口过程处理。

MFC工具条和状态栏

Windows控制窗口

Windows (Windows95或者以上版本) 提供了系列通用控制窗口，其中包括工具条(ToolBar)、状态栏(StatusBar)、工具条提示窗口(ToolTip)。

Windows在一个DLL加载时注册个控制窗口的“窗口类”。例如，工具条的“窗口类”是“ToolbarWindow32”，状态栏的“窗口类”是“msctls_statusbar32”，工具条提示窗口的“窗口类”是“tooltips_class32”。为了保证该DLL被加载，使用控制“窗口类”前，应该首先调用函数InitCommonControl。MFC在窗口注册函数AfxDeferRegisterClass中实现了这一点。见2.2.1节MFC下窗口的注册。

创建通用控制窗口，可以使用专门的创建函数，如创建工具条的函数::CreateToolBarEx，创建状态栏的函数::CreateStatusBarEx。也可以调用窗口创建函数::CreateWindowEx，但是需要指定预定义的“窗口类”，必要的话还要其他步骤，如使用“ToolbarWindow32”“窗口类”创建工具栏后，还需要在工具栏中添加或者插入按钮。

一般，通用控制可以指定控制窗口风格(Style)。例如，具备风格CCS_TOP，表示该控制窗口放到父窗口客户区的顶部，具备CCS_BOTTOM，表示该控制窗口在客户区的底部。具体的控制窗口类可以有特别的适合于自己的风格，例如，TTS_ALWAYSTIP表示只要光标落在工具栏的按钮上，ToolTip窗口不论激活与否都会显示出来。

每一控制窗口类都有自己的窗口过程来处理自己的窗口消息，实现特定的功能。控制窗口类的窗口过程由Windows提供。

工具条

工具条的窗口过程处理了必要的消息，提供了标准工具条的功能，例如，工具条对客户化特征提供内在的支持，用户可以通过一个客户化对话框来添加、修改、删除或者重新安排工具条按钮。这些特征是否可以被用户所用或者用到什么地步是可以由程序控制的。

工具条的窗口过程将自动设置工具条的尺寸大小和位置，如果指定了控制窗口风格CCS_TOP或者CCS_BOTTOM，则窗口过程把工具条放到父窗口客户区的顶部或者底部。窗口过程任何时候只要收到WM_SIZE或者TB_AUTOSIZE消息就自动地调整工具条的大小和位置。

工具条的按钮被选中后，会产生一个命令消息，它的窗口过程把该消息送给父窗口的窗口过程处理。

工具条中的按钮并不以子窗口的形式出现，而是以字符或者位图按钮的方式显示，每个按钮大小相同，缺省是24*22个像素。每个按钮都有一个索引，索引编号从0开始。每个按钮包括如下属性：

按钮的字符串索引，位图索引，风格，状态，命令ID

按钮可以有两种风格TBSTYLE_BUTTON和TBSTYLE_CHECK，前者像一个标准按钮那样响应用户的按击，后者响应每一次按击，在按下和跳起两种状态之间切换。按钮响应用户的动作，给父窗口发送一个包含了该按钮对应命令ID的命令消息。一般一个按钮的命令ID对应一个菜单项。

工具条维护两个列表，分别用来存放工具条按钮使用的字符串或者位图，列表中的位图或者字符串从0开始编号，编号和按钮的索引相对应。

工具条可以是Dockable（泊位）或者Floatable（漂浮）的。

工具条可以有TBSTYLE_TOOLTIPS风格，如果具有这种风格，则创建和管理一个Tooltip控制，这是一个小的弹出式窗口，用来显示描述按钮的文本，平时该窗口隐藏，当鼠标落到按钮上面并停留约一秒后才弹出，在鼠标附近显示。

由于Tooltip窗口平时是隐藏的，所以不能接收鼠标消息来决定何时显示本窗口。这样，接收鼠标的窗口必须把鼠标消息送给Tooltip窗口，这是通过给Tooptip窗口发送消息TTM_RELAYEVENT来实现的。

状态栏

状态栏类似于工具条，有自己的窗口过程，可以泊位、漂浮。不过，习惯上状态栏都位于屏幕底部。每个状态条分成若干格（Status bar panes），每格从0开始编号，编号作为格的索引。每一个格，如同工具条的按钮一样，并不是一个Windows窗口。

MFC的工具条和状态栏类

MFC使用CToolBarCtrl、CStatusBarCtrl和CToolTipCtrl窗口类分别对工具条、状态栏、Tooltip控制窗口进行了封装。

但是，直接使用这些类还不是很方便。MFC提供了CToolBar、CStatusBar来处理状态栏和工具条，CToolBar、CStatusBar功能更强大，灵活。这两个类都派生于CControlBar。

在MFC下，建议这些控制条子窗口ID介于AFX_IDW_TOOLBARFIRST(0xE800)和AFX_IDW_CONTROLBAR_LAST（0Xe8FF）之间。这256个ID中，前32个又有其特殊性，用于MFC的打印预览中。

CControlBar派生于CWnd类，是控制条窗口类的基类，它派生出CToolBar、CStatusBar、CDockBar、CDialogBar、COleResizeBar类。CControlBar实现了以下功能：

和父窗口（边框窗口）的顶部或者底部或者其他边对齐。
可以包含子条目，这些条目或者是基于HWND的子窗口，或者是基于非HWND的条目。负责分配条目数组。
支持CBRS_TOP（缺省，控制条放在顶部），CBRS_BOTTOM（放在底部），CBRS_NOALIGN（父窗口大小变化时不重新放置控制条）等几种控制风格。
支持派生类的实现。几个派生类有一定的共性，或者其中两个有一定的共性，这样CControlBar实现的函数一部分只适用于某个派生类，一部分适用于两个或者多个派生类，还有一部分适用于所有的派生类。所谓适用，这里指派生类直接继承了CControlBar的实现，或者覆盖了其实现但是建立在扩展其实现的基础上。类似地，CControlBar的成员变量也不是为所有派生类所共同适用的。

CStatusBar和CControlBar一方面建立在CControlBar的基础之上，另一方面以Windows的通用控制状态栏和工具条为基础。它们继承了CControlBar类的特性，但是所封装的窗口句柄是相应的Windows控制窗口的句柄，如同CFormView继承了CSrcollView的视类特性，但是其窗口句柄是无模式对话框窗口句柄一样。

典型地，如果在使用AppWizard生成应用程序时，指定了要求工具条和状态栏的支持，则在主边框窗口的OnCreate函数中包含一段如下的代码，用来创建工具条、状态栏和设置一些特性。

//创建工具栏

if (!m_wndToolBar.Create(this) ||!m_wndToolBar.LoadToolBar(IDR_MAINFRAME))

{

TRACE0(“Failed to create toolbar\n”);

return -1; // fail to create

}

//创建状态栏

if (!m_wndStatusBar.Create(this) ||

!m_wndStatusBar.SetIndicators(indicators, sizeof(indicators)/sizeof(UINT)))

{

TRACE0(“Failed to create status bar\n”);

return -1; // fail to create

}

// TODO: Remove this if you don’t want tool tips or a resizeable toolbar

//对工具栏设置Tooltip特征

m_wndToolBar.SetBarStyle(m_wndToolBar.GetBarStyle() |

CBRS_TOOLTIPS | CBRS_FLYBY | CBRS_SIZE_DYNAMIC);

//使得工具栏可以泊位在边框窗口

// TODO: Delete these three lines if you don’t want the toolbar to

// be dockable

m_wndToolBar.EnableDocking(CBRS_ALIGN_ANY);

EnableDocking(CBRS_ALIGN_ANY);

DockControlBar(&m_wndToolBar);

工具条除了Tooltip，Resizeable，Dockable特性外，还可以是Floatable。应用程序可以使用CFrameWnd::SaveBarState保存边框窗口的控制条的有关信息到INI文件或者Windows Register库，使用LoadBarSate从INI文件或者Register库中读取有关信息并恢复各个控制条的设置。

下文，将讨论工具条等的创建、销毁，从中分析CControlBar和派生类的关系，讨论CControlBar如何实现共性，如何支持派生类的特定要求，派生类又如何实现自己的特定需求等。

控制窗口的创建

创建工具条、状态条、对话框工具栏的方法是不同的，所以必须给每个派生类CToolBar、CStatusBar、CDialogBar设计和实现自己的窗口创建函数Create。但是，它们是也是有共性的，共性由CControlBar的PreCreateWindow处理。在窗口创建之后，各个派生类都要进行的处理（共性）由CControlBar的OnCreate完成，特别的处理通过派生类的OnNcCreate完成。

PreCreateWindow

首先，讨论CControlBar 类的PreCreateWindow的实现。

BOOL CControlBar::PreCreateWindow(CREATESTRUCT& cs)

{

if (!CWnd::PreCreateWindow(cs))

return FALSE;

//修改窗口风格，强制适用clipsliblings，以防重复绘制

cs.style |= WS_CLIPSIBLINGS;

//default border style translation for Win4

//(you can turn off this translation by setting CBRS_BORDER_3D)

if (afxData.bWin4 && (m_dwStyle & CBRS_BORDER_3D) == 0)

{

DWORD dwNewStyle = 0;

switch (m_dwStyle & (CBRS_BORDER_ANY|CBRS_ALIGN_ANY))

{

case CBRS_LEFT: //控制条在边框窗口的左边显示

dwNewStyle = CBRS_BORDER_TOP|CBRS_BORDER_BOTTOM;

break;

case CBRS_TOP://控制条在边框窗口的顶部显示

dwNewStyle = CBRS_BORDER_TOP;

break;

case CBRS_RIGHT://控制条在边框窗口的右边显示

dwNewStyle = CBRS_BORDER_TOP|CBRS_BORDER_BOTTOM;

break;

case CBRS_BOTTOM://控制条在边框窗口的底部显示

dwNewStyle = CBRS_BORDER_BOTTOM;

break;

}

// set new style if it matched one of the predefined border types

if (dwNewStyle != 0)

{

m_dwStyle &= ~(CBRS_BORDER_ANY);

m_dwStyle |= (dwNewStyle | CBRS_BORDER_3D);

}

return TRUE;

}

其中，afxData是一个全局变量，MFC用它来记录系统信息，如版本信息等。这里afxData.bWin4表示Windows版本是否高于4.0。

CToolBar的PreCreateWindow函数修改了窗口风格，也修改状态栏、工具栏等的CBRS_风格。CBRS_风格的改变不会影响窗口风格。因为这些CBRS_风格被保存在成员变量m_dwStyle中。

除了上述在程序中用到的影响工具条、状态栏等显示位置的CBRS_风格外，还有和泊位相关的CBRS_风格，CBRS_ALIGN_LEFT、CBRS_ALIGN_RIGHT、CBRS_ALIGN_BOTTOM、CBRS_ALIGN_TOP、CBRS_ALIGN_ANY，分别表示工具条可以在停泊在边框窗口的左边、右边、底部、顶部或者所有这些位置；和漂浮相关的CBRS_风格CBRS_FLOAT_MULTI，表示多个工具条可以漂浮在一个微型边框窗口中；和Tooltips相关的CBRS_风格CBRS_TOOLTIPS和CBRS_FLYBY。

派生类如果没有特别的要求，可以不覆盖PreCreateWindow函数。CStatusBar因为有更具体和特殊的风格要求，所以它覆盖了PreCreateWindow。CStatusBar的覆盖实现调用了CControlBar的实现。

派生类也可以在覆盖实现中修改PreCreateWindow参数cs，改变窗口风格；修改m_dwStyle，改变CBRS_风格。

控制条的窗口创建

CControlBar派生类实现了自己的窗口创建函数Create，CControlBar的PreCreateWindow被派生类的Create函数直接或者间接地调用。以CToolBar为例讨论窗口创建函数和创建过程。

CToolBar的窗口创建函数Create

Create函数实现如下：

BOOL CToolBar::Create(CWnd* pParentWnd, DWORD dwStyle, UINT nID)

{

ASSERT_VALID(pParentWnd); // must have a parent

ASSERT (!((dwStyle & CBRS_SIZE_FIXED) &&

(dwStyle & CBRS_SIZE_DYNAMIC)));

// 保存dwStyle指定的CBRS_风格

m_dwStyle = dwStyle;

if (nID == AFX_IDW_TOOLBAR)

m_dwStyle |= CBRS_HIDE_INPLACE;

//去掉参数dwStyle包含的CBRS_风格

dwStyle &= ~CBRS_ALL;

//设置窗口风格

dwStyle |=

CCS_NOPARENTALIGN|CCS_NOMOVEY|CCS_NODIVIDER|CCS_NORESIZE;

//初始化通用控制，可以导致InitCommonControl的调用

VERIFY(AfxDeferRegisterClass(AFX_WNDCOMMCTLS_REG));

//创建窗口，将调用PreCreateWindow,OnCreate, OnNcCreate等

CRect rect; rect.SetRectEmpty();

if (!CWnd::Create(TOOLBARCLASSNAME, NULL, dwStyle,

rect, pParentWnd, nID))

return FALSE;

// Note: Parent must resize itself for control bar to be resized

return TRUE;

}

其中：

Create函数的参数1表示工具条的父窗口。参数2指定窗口风格和CBRS_风格，缺省值为 WS_CHILD | WS_VISIBLE | CBRS_TOP，其中WS_CHILD和WS_VISIBLE是窗口风格，CBRS_TOP是CBRS_风格。参数3指定工具条ID，缺省值为AFX_IDW_TOOLBAR（0X0E800或者59392）。如果还有多个工具栏要显示，在创建它们时则必须给每个工具栏指明ID。

首先，Create函数把参数2（dwStyle）指定的窗口风格和CBRS_风格分离出来，窗口风格保留在dwStyle中，CBRS_风格保存到成员变量m_dwStyle中。CToolBar::PreCreateWindow将进一步修改这些风格。

接着，Create函数调用了函数AfxDeferRegisterClass。它如果没有注册TOOLBARCLASSNAME表示的“窗口类”，就注册该类；否则，返回TRUE，表示已经注册。TOOLBARCLASSNAME表示的字符串是“ToolbarWindow32”，即“窗口类”名称。

然后，调用CWnd::Create(7个参数)使用“ToolbarWindow32”“窗口类”创建工具栏。

Create在创建窗口的过程中，用MFC的标准窗口过程取代原来的窗口过程，如同CFormView和CDialog窗口创建时窗口过程被取代一样，并发送WM_CREATE和WM_NCCREATE消息。

至于添加向工具栏添加按钮，则由函数LoadToolBar完成。在分析LoadToolBar函数之前，先讨论OnCreate、OnNcCreate等函数。

处理WM_CREATE消息

CControlBar提供了消息处理函数OnCreate来处理WM_CREATE消息。

int CControlBar::OnCreate(LPCREATESTRUCT lpcs)

{

//调用基类的实现

if (CWnd::OnCreate(lpcs) == -1)

return -1;

//针对工具栏，是否有Tooltip特性

if (m_dwStyle & CBRS_TOOLTIPS)

EnableToolTips();

//得到父窗口，并添加自身到其控制条列表中

CFrameWnd *pFrameWnd = (CFrameWnd*)GetParent();

if (pFrameWnd->IsFrameWnd())

{

m_pDockSite = pFrameWnd;

m_pDockSite->AddControlBar(this);

}

return 0;

}

如果需要支持Tooltips，则OnCreate调用EnableTooltips。

m_pDockSite是CControlBar的和泊位相关的成员变量，这里把它初始化为拥有工具栏的父边框窗口，该边框窗口把控制条加入其控制条列表m_listControlBars中。

在处理WM_CREATE之前，派生类先处理消息WM_NCCREAE。例如，CToolBar覆盖了OnNcCreate函数。

处理WM_NCCREATE消息

CToolBar对WM_NCCREATE消息的处理如下：

BOOL CToolBar::OnNcCreate(LPCREATESTRUCT lpCreateStruct)

{

if (!CControlBar::OnNcCreate(lpCreateStruct))

return FALSE;

// if the owner was set before the toolbar was created, set it now

if (m_hWndOwner != NULL)

DefWindowProc(TB_SETPARENT, (WPARAM)m_hWndOwner, 0);

DefWindowProc(TB_BUTTONSTRUCTSIZE, (WPARAM)sizeof(TBBUTTON), 0);

return TRUE;

}

CToolBar覆盖CcontrolBar的该函数用来设置工具条的所属窗口和描述工具条按钮结构的大小，这两个动作都是通过给工具条窗口发送消息来实现的。因为这些消息被送给控制窗口类的窗口过程（Windows提供的）来处理，所以直接调用DefWindowProc，省却了消息发送的过程。

在控制窗口创建之后，对于工具条来说，下一步就是向工具栏添加按钮。

向工具栏添加按钮

通过函数LoadToolBar完成向工具栏添加按钮的任务，其实现如下：

BOOL CToolBar::LoadToolBar(LPCTSTR lpszResourceName)

{

ASSERT_VALID(this);

ASSERT(lpszResourceName != NULL);

//查找并确认按钮位图、字符串等资源的位置

HINSTANCE hInst = AfxFindResourceHandle(lpszResourceName, RT_TOOLBAR);

HRSRC hRsrc = ::FindResource(hInst, lpszResourceName, RT_TOOLBAR);

if (hRsrc == NULL)

return FALSE;

//锁定资源

HGLOBAL hGlobal = LoadResource(hInst, hRsrc);

if (hGlobal == NULL)

return FALSE;

CToolBarData* pData = (CToolBarData*)LockResource(hGlobal);

if (pData == NULL)

return FALSE;

ASSERT(pData->wVersion == 1);

//复制与各个位图对应的命令ID到数组pItem

UINT* pItems = new UINT[pData->wItemCount];

for (int i = 0; i < pData->wItemCount; i++)

pItems[i] = pData->items()[i];

//添加按钮到工具栏，指定各个按钮对应的ID

BOOL bResult = SetButtons(pItems, pData->wItemCount);

delete[] pItems;

//设置按钮的位图

if (bResult)

{

// set new sizes of the buttons

CSize sizeimage(pData->wWidth, pData->wHeight);

CSize sizeButton(pData->wWidth + 7, pData->wHeight + 7);

SetSizes(sizeButton, sizeimage);

// load bitmap now that sizes are known by the toolbar control

bResult = LoadBitmap(lpszResourceName);

}

UnlockResource(hGlobal);

FreeResource(hGlobal);

return bResult;

}

LoadToolBar函数的参数指定了资源。ToolBar资源的类型是RT_TOOLBAR，ToolBar位图资源的类型是RT_BITMAP。

在RT_TOOLBAR类型的资源读入内存之后，可以用CToolBarData结构描述。一个这样的结构包括了ToolBar资源的如下信息：

工具条位图的版本，宽度，高度，个数，各个位图对应的命令ID。

然后，LoadToolBar把这些命令ID被复制到数组pItem中；根据位图宽度、高度形成按钮尺寸sizeButton和位图尺寸sizeimage。

接着，调用SetBottons添加按钮到工具栏，把各个按钮和命令ID对应起来；调用SetSizes设置按钮和位图的尺寸大小；调用LoadBitmap添加或者取代工具条的位图列表。这些动作都是调用工具栏“窗口类”的窗口过程完成的。例如，SetButtons的实现：

BOOL CToolBar::SetButtons(const UINT* lpIDArray, int nIDCount)

{

ASSERT_VALID(this);

ASSERT(nIDCount >= 1); // must be at least one of them

ASSERT(lpIDArray == NULL ||

AfxIsValidAddress(lpIDArray, sizeof(UINT) * nIDCount, FALSE));

//首先，删除工具条中现有的按钮

int nCount = (int)DefWindowProc(TB_BUTTONCOUNT, 0, 0);

while (nCount–)

VERIFY(DefWindowProc(TB_DELETEBUTTON, 0, 0));

if (lpIDArray != NULL)//命令ID数组非空

{

//添加新按钮

TBBUTTON button; memset(&button, 0, sizeof(TBBUTTON));

int iimage = 0;

for (int i = 0; i < nIDCount; i++)

{

button.fsState = TBSTATE_ENABLED;

if ((button.idCommand = *lpIDArray++) == 0)

{

//按钮之间分隔

button.fsStyle = TBSTYLE_SEP;

//按钮之间隔8个像素

button.iBitmap = 8;

}

else

{

//有位图和命令ID的按钮

button.fsStyle = TBSTYLE_BUTTON;

button.iBitmap = iimage++;//设置位图索引

}

//添加按钮

if (!DefWindowProc(TB_ADDBUTTONS, 1, (LPARAM)&button))

return FALSE;

}

else//命令ID数组空，添加空按钮

{

TBBUTTON button; memset(&button, 0, sizeof(TBBUTTON));

button.fsState = TBSTATE_ENABLED;

for (int i = 0; i < nIDCount; i++)

{

ASSERT(button.fsStyle == TBSTYLE_BUTTON);

if (!DefWindowProc(TB_ADDBUTTONS, 1, (LPARAM)&button))

return FALSE;

}

//记录按钮个数到成员变量m_nCount中

m_nCount = (int)DefWindowProc(TB_BUTTONCOUNT, 0, 0);

//稍后放置按钮

m_bDelayedButtonLayout = TRUE;

return TRUE;

}

函数的参数1是一个数组，数组的各个元素就是命令ID；参数2是按钮的个数。首先，SetButtons删除工具条原来的按钮；然后，添加新的按钮，若命令ID数组非空，则把每一个按钮和命令ID对应并分配位图索引，否则设置空按钮并返回FALSE；最后，记录按钮个数。

从SetButtons的实现可以看出，对工具条的所有操作都是通过工具条“窗口类”的窗口过程完成的，SetSizes、LoadBitmap也是如此，这里不作讨论。

状态栏和对话框工具栏的创建

至此，分析了MFC创建工具条窗口的过程。对于状态栏和对话框工具栏有类似的步骤，但也有不同之处。

CStatusBar的Create使用“msctls_statusbar32”“窗口类”创建状态栏，窗口ID为AFX_IDW_STATUS_BAR(0XE801)，然后通过成员函数SetIndictors给状态栏分格，类似于给工具条添加按钮的过程，它实际上是通过状态栏“窗口类”的窗口过程完成的。

CDialogBar的Create使用CreateDlg创建对话框工具栏，类似于CFormView的过程。在工具栏窗口创建之后，要添加到父窗口的工具栏列表中，这通过CControlBar::OnCreate完成。这样创建的结果导致窗口过程使用MFC的统一的窗口过程，相应“窗口类”的窗口过程也将在缺省处理中被调用，这一点如同CFormView和CDialog中所描述的。在初始化对话框的时候完成了各个控制按钮的添加。

CStatusBar和CdialogBar都没有处理消息WM_NCCREATE。

关于CStautsBar和CDialogBar创建过程的具体实现，这里不作详细讨论了。

控制条的销毁

描述了控制条的创建，顺便考察其销毁的设计。

工具条、状态栏等这些控制窗口都要使用DestroyWindow来销毁，所有有关操作集中由CControlBar处理。CControlBar覆盖了虚拟函数DestroyWindow、PostNcDestroy和消息处理函数OnDestroy。

当然，各个派生类的虚拟析构函数被实现。如果成员变量m_bAutoDelete为TRUE，则动态创建的MFC窗口将自动销毁。

处理控制条的位置

计算控制条位置的过程和算法

工具条等控制条是作为一个子窗口在父边框窗口内显示的。为了处理控制条的布置(Layout)，首先需要计算出控制条的尺寸大小，这个工作被委派给工具条等控制窗口自己来完成。为此，CControlBar提供了两个函数来达到这个目的：CalcFixLayout，CalcDynamicLayout。这两个函数都是虚拟函数。各个派生类都覆盖了这两个或者其中一个函数，用来计算自身的尺寸大小。这些计算比较琐碎，在此不作详细讨论。其次，在父窗口位置或者大小变化时，控制条的大小和位置要作相应的调整。

下面，描述MFC确定或者更新工具条、状态栏等位置的步骤：

（1）边框窗口在必要的时候调用虚拟函数RecalcLayout来重新放置它的控制条和客户窗口，例如在创建窗口时、响应消息WM_SIZE时（见5.3.3.5节)边框窗口的初始化）。

（2）CFrameWnd::RecalcLayout调用CWnd的成员函数RepositionBars完成控制条窗口的重新放置。

（3）CWnd::RepositionBars作如下的处理：

RepositionBars首先给各个控制子窗口发送（Send）MFC内部使用的消息WM_SIZEPARENT，把窗口客户区矩形指针传递给它们，给它们一个机会来确认自己的尺寸。

然后，各个控制子窗口用OnSizeParent响应WM_SIZEPARENT消息；ControlBar实现了消息处理函数OnSizeParent，它调用CalcDynamicLayout等函数确定本窗口的大小，并从客户区矩形中减去自己的尺寸。

在所有的控制子窗口处理了OnSizeParent消息之后，RepositonBars利用返回的信息调用函数CalcWindowRect计算客户区窗口（MDI客户窗口、View等）的大小。

最后，调用::EndDeferWindowPos或者::SetWindowPos放置所有的窗口（控制子窗口和客户窗口）。

在窗口被放置的时候，发送消息WM_WINDOWPOSCHANGING和WM_WINDOWPOSCHANGED。MFC的实现中，控制窗口响应了前一个消息，消息处理函数是OnWindowPosChanging。CControlBar、CToolBar和CStatusBar等实现了消息处理函数OnWindowPosChanging。

上述处理过程所涉及的这些函数中，RecalcLayout是CFrameWnd定义的虚拟函数；RepostionBars是CWnd的成员函数；CalcaWindowRect是CWnd的虚拟函数；OnSizeParent是CControlBar定义的消息处理函数；OnWindowPosChanging是CToolbar、CStatusBar、CDockBar等CControlBar派生类定义的消息处理函数。

下面，对其中两个函数RecalcLayout和RepositionBars作一些分析。

CFrameWnd的虚拟函数RecalcLayout

RecalcLayout的实现如下：

void CFrameWnd::RecalcLayout(BOOL bNotify)

{

//RecalcLayout是否正在被调用

if (m_bInRecalcLayout)

return;

m_bInRecalcLayout = TRUE;

// clear idle flags for recalc layout if called elsewhere

if (m_nIdleFlags & idleNotify)

bNotify = TRUE;

m_nIdleFlags &= ~(idleLayout|idleNotify);

//与OLE相关的处理

#ifndef _AFX_NO_OLE_SUPPORT

// call the layout hook — OLE support uses this hook

if (bNotify && m_pNotifyHook != NULL)

m_pNotifyHook->OnRecalcLayout();

#endif

//是否包含浮动(floating)控制条的边框窗口(CMiniFrameWnd类)

if (GetStyle() & FWS_SNAPTOBARS)

{

//计算控制条和边框窗口的位置、尺寸并设置它们的位置

CRect rect(0, 0, 32767, 32767);

RepositionBars(0, 0xffff, AFX_IDW_PANE_FIRST, reposQuery,

&rect, &rect, FALSE);

RepositionBars(0, 0xffff, AFX_IDW_PANE_FIRST, reposExtra,

&m_rectBorder, &rect, TRUE);

CalcWindowRect(&rect);

SetWindowPos(NULL, 0, 0, rect.Width(), rect.Height(),

SWP_NOACTIVATE|SWP_NOMOVE|SWP_NOZORDER);

}

else

//是普通边框窗口，则设置其所有子窗口的位置、尺寸

RepositionBars(0, 0xffff, AFX_IDW_PANE_FIRST,

reposExtra, &m_rectBorder);

//本函数处理完毕

m_bInRecalcLayout = FALSE;

}

该函数主要的目的是调用RepositionBars函数，它分两种情况来调用RepositionBars函数。一种情况是当前边框窗口为浮动控制条的包容窗口（微型边框窗口）时；另一种情况是当前边框窗口为普通边框窗口时。

CWnd的成员函数RepositionBars

RepositionBars的实现如下：

void CWnd::RepositionBars(UINT nIDFirst, UINT nIDLast, UINT nIDLeftOver,

UINT nFlags, LPRECT lpRectParam, LPCRECT lpRectClient, BOOL bStretch)

{

ASSERT(nFlags == 0 || nFlags == reposQuery || nFlags == reposExtra);

AFX_SIZEPARENTPARAMS layout;

HWND hWndLeftOver = NULL;

layout.bStretch = bStretch;

layout.sizeTotal.cx = layout.sizeTotal.cy = 0;

if (lpRectClient != NULL)

layout.rect = *lpRectClient; //从参数6得到客户区

else

//参数lpRectClient空，得到客户区域

GetClientRect(&layout.rect);

if (nFlags != reposQuery)

//准备放置各个子窗口(layout)

layout.hDWP = ::BeginDeferWindowPos(8); // reasonable guess

else

layout.hDWP = NULL; // not actually doing layout

//按一定顺序给各个控制条发送父窗口resize的消息；

//各个控制条窗口收到消息后，从客户区中扣除自己使用的区域；

//并且必要的话每个控制窗口调用::DeferWindowPos

//剩下的区域留给nIDLeftOver子窗口

for (HWND hWndChild = ::GetTopWindow(m_hWnd); hWndChild != NULL;

hWndChild = ::GetNextWindow(hWndChild, GW_HWNDNEXT))

{

UINT nIDC = _AfxGetDlgCtrlID(hWndChild);

CWnd* pWnd = CWnd::FromHandlePermanent(hWndChild);

//如果是指定的nIDLeftOver子窗口，则保存其窗口句柄；

//否则，是控制条窗口，给它们发送WM_SIZEPARENT消息

if (nIDC == nIDLeftOver)

hWndLeftOver = hWndChild;

else if (nIDC >= nIDFirst && nIDC <= nIDLast && pWnd != NULL)

//如果layout->hDWP非空， OnSizeParent则将执行窗口布置的操作

::SendMessage(hWndChild, WM_SIZEPARENT, 0, (LPARAM)&layout);

}

//如果是reposQuery，则得到客户区矩形，返回

if (nFlags == reposQuery)

{

ASSERT(lpRectParam != NULL);

if (bStretch)

::CopyRect(lpRectParam, &layout.rect);

else

{

lpRectParam->left = lpRectParam->top = 0;

lpRectParam->right = layout.sizeTotal.cx;

lpRectParam->bottom = layout.sizeTotal.cy;

}

return;

}

//其他情况下（reposDefault、reposExtra），则需要执行Layout操作

//处理hWndLeftOver(nIDLeftOver子窗口)

if (nIDLeftOver != 0 && hWndLeftOver != NULL)

{

CWnd* pLeftOver = CWnd::FromHandle(hWndLeftOver);

// allow extra space as specified by lpRectBorder

if (nFlags == reposExtra)

{

ASSERT(lpRectParam != NULL);

layout.rect.left += lpRectParam->left;

layout.rect.top += lpRectParam->top;

layout.rect.right -= lpRectParam->right;

layout.rect.bottom -= lpRectParam->bottom;

}

//基于layout.rect表示的客户尺寸计算出窗口尺寸

pLeftOver->CalcWindowRect(&layout.rect);

//导致函数::DeferWindowPos的调用

AfxRepositionWindow(&layout, hWndLeftOver, &layout.rect);

}

//给所有的窗口设置尺寸、位置(size and layout)

if (layout.hDWP == NULL || !::EndDeferWindowPos(layout.hDWP))

TRACE0(“Warning: DeferWindowPos failed – low system resources.\n”);

}

RepositionBars用来改变客户窗口中控制条的尺寸大小或者位置，其中：

参数1和参数2定义了需要重新放置的子窗口ID的范围，一般是0到0xFFFF。

参数3指定了一个子窗口ID，它拥有客户窗口剩下的空间，一般是AFX_IDW_PANE_FIRST，表示视的窗口ID。

参数4指定了操作类型，缺省是CWnd::ReposDefault，表示执行窗口放置操作，参数5不会用到；若取值CWnd::ReposQuery，则表示尝试进行窗口放置（Layout），但最后不执行这个操作，只是把参数5初始化成客户区的尺寸大小；若取值CWnd::ReposExtra，则把参数5的值加到参数2表示的子窗口的客户区域，并执行窗口放置操作。

参数6表示传递给函数的可用窗口客户区的尺寸，如果空则使用窗口客户区尺寸。

如果执行layout操作的话，该函数的核心处理就是：

首先，调用::BeginDeferWindowPos初始化一个Windows内部的多窗口位置结构（Multiple-window – position structure）hDWP；

然后，让各个子窗口逐个调用::DeferWindowPos，更新hDWP。在调用::DeferWindowPos之前，要作一个确定子窗口大小的工作。这些工作通过给各个控制子窗口发送消息WM_SIZEPARENT来完成。

控制子窗口通过函数OnSizeParent响应WM_SIZEPARENT消息，先确定自己的尺寸，然后，如果需要进行窗口布置(WM_SIZEPARENT消息参数lParam包含了一个非空的HDWP结构（lpLayout->hDWP）)，则OnSizeParent将调用AfxRepositionWindow函数计算本控制窗口的位置，结果保存到hDWP中。

在所有的控制窗口尺寸确定之后，剩下的留给窗口hWndLeftOver（如果存在的话）。确定了hWndLeftOver的大小之后，调用AfxRepositionWindow函数计算其位置，结果保存到hDWP中。

上面提到的函数AfxRepositionWindow间接调用了::DeferWindowPos。

最后，::EndDeferWindowPos，使用hDWP安排所有子窗口的位置和大小。

至于其他函数，如OnSizeparent、OnWindowPosChanging、CalcWindowRect，这里不作进一步的分析。

工具条、状态栏和边框窗口的接口

应用程序在状态栏中显示信息

MFC内部通过给边框窗口发送消息WM_SETMESSAGESTRING、WM_POPMESSAGESTRING的方式在状态栏中显示信息。这两个消息在afxpriv.h里头定义。

WM_SETMESSAGESTRING消息表示在状态栏中显示和某个ID对应的字符串信息或者指定的字符串信息，消息参数wParam指定了字符串资源ID，消息参数lParam指定了字符串指针，两个消息参数只有一个有用。一般，一个命令ID对应了一个字符串ID，对应的字符串是命令ID的说明。

消息WM_POPMESSAGESTRING用来重新设置状态栏。

这两个消息对应的消息处理函数分别是OnSetMessageString和OnPopMessageString，OnSetMessageString和OnPopMessageString分别实现如下：

OnSetMessageString

LRESULT CFrameWnd::OnSetMessageString(WPARAM wParam, LPARAM lParam)

{

//最近一次被显示的消息字符串IDS（一个消息对应的字符串）

UINT nIDLast = m_nIDLastMessage;

m_nFlags &= ~WF_NOPOPMSG;

//得到状态栏

CWnd* pMessageBar = GetMessageBar();

if (pMessageBar != NULL)

{

LPCTSTR lpsz = NULL;

CString strMessage;

//设置状态栏文本

if (lParam != 0) //指向一个字符串

{

ASSERT(wParam == 0); // can’t have both an ID and a string

lpsz = (LPCTSTR)lParam; // set an explicit string

}

else if (wParam != 0)//一个字符串资源IDS

{

//打印预览时映射SC_CLOSE成AFX_IDS_PREVIEW_CLOSE;

if (wParam == AFX_IDS_SCCLOSE && m_lpfnCloseProc != NULL)

wParam = AFX_IDS_PREVIEW_CLOSE;

//得到资源ID所标识的字符串

GetMessageString(wParam, strMessage);

lpsz = strMessage;

}

//在状态栏中显示文本

pMessageBar->SetWindowText(lpsz);

// 根据最近一次选择的消息更新状态条所属窗口的有关记录

CFrameWnd* pFrameWnd = pMessageBar->GetParentFrame();

if (pFrameWnd != NULL)

{

//记录最近一次显示的消息字符串

pFrameWnd->m_nIDLastMessage = (UINT)wParam;

//记录最近一次Tracking的命令ID和字符串IDS

pFrameWnd->m_nIDTracking = (UINT)wParam;

}

m_nIDLastMessage = (UINT)wParam; // new ID (or 0)

m_nIDTracking = (UINT)wParam; // so F1 on toolbar buttons work

return nIDLast;

}

OnSetMessageString函数直接或者从ID从字符串资源中得到字符串指针。如果是从ID得到字符串指针，则函数GetMessageString被调用。

和命令ID对应的字符串由两部分组成，前一部分用于在状态栏显示，后一部分用于Tooltip显示，分隔符号是“\n”。例如，字符串ID_APP_EXIT（对应“退出”菜单、按钮）是“Exit Application\nExit”，当鼠标落在“退出”按钮上时，状态栏显示“Exit Application”，Tooltip显示“Exit”。根据这种格式，GetMessageString分离出第一部分的文本信息。至于第二部分的用途将在讨论Tooltip的章节将用到。

得到了字符串之后，OnSetMessageString调用状态栏的SetWindowText函数。SetWindowText导致消息WM_SETTEXT消息发送给状态栏，状态栏的消息处理函数OnSetText被调用，实际上等于调用了SetPaneText(0, lpsz)，即在状态栏的第0格中显示字符串lpsz的信息。对于工具栏来说，SetWindowText可以认为是SetPaneText(0, lpsz)的简化版本。

顺便指出，pMessageBar->GetParentFrame()返回主边框窗口，即使pMessageBar指向漂浮的工具条。关于泊位和漂浮，见后面13.2.5节的描述。

关于OnSetText，其实现如下：

LRESULT CStatusBar::OnSetText(WPARAM, LPARAM lParam)

{

ASSERT_VALID(this);

ASSERT(::IsWindow(m_hWnd));

int nIndex = CommandToIndex(0); //返回0

if (nIndex < 0)

return -1;

return SetPaneText(nIndex, (LPCTSTR)lParam) ? 0 : -1;

}

OnPopMessageString

LRESULT CFrameWnd::OnPopMessageString(WPARAM wParam,

LPARAM lParam)

{

//WF_NOPOPMSG表示边框窗口不处理WM_POPMESSAGESTRING

if (m_nFlags & WF_NOPOPMSG)

return 0;

//调用OnSetMessageString

return SendMessage(WM_SETMESSAGESTRING, wParam, lParam);

}

一般，在清除状态栏消息时，发送WM_POPMESSAGESTRING，通过消息参数wParam指定一个字符串资源，其ID 为AFX_IDS_IDLEMESSAGE，对应的字符串是“Ready”。

状态栏显示菜单项的提示信息

状态栏的一个重要作用是显示菜单命令或者工具条按钮的提示信息。本节讨论如何显示菜单命令的提示信息，关于工具条按钮在这方面的讨论见后面13.2.4.4章节。

显示菜单命令的提示信息，就是每当一个菜单项被选中之后，在状态栏显示该菜单的功能、用法等信息。这些信息以字符串资源的形式保存，字符串ID对应于菜单项的命令ID。

所以，必须处理菜单选择消息WM_MENUSELECT。CFrameWnd实现了消息处理函数OnMenuSelect，其实现如下：

void CFrameWnd::OnMenuSelect(UINT nItemID,

UINT nFlags, HMENU /*hSysMenu*/)

{

CFrameWnd* pFrameWnd = GetTopLevelFrame();

ASSERT_VALID(pFrameWnd);

//跟踪被选中的菜单项

if (nFlags == 0xFFFF)

{

//取消菜单操作

m_nFlags &= ~WF_NOPOPMSG;

if (!pFrameWnd->m_bHelpMode)

m_nIDTracking = AFX_IDS_IDLEMESSAGE;

else

m_nIDTracking = AFX_IDS_HELPMODEMESSAGE;

//在状态栏显示

SendMessage(WM_SETMESSAGESTRING, (WPARAM)m_nIDTracking);

ASSERT(m_nIDTracking == m_nIDLastMessage);

// update right away

CWnd* pWnd = GetMessageBar();

if (pWnd != NULL)

pWnd->UpdateWindow();

}

else

{

//选中分隔栏、Popup子菜单或者没有选中一个菜单项

if (nItemID == 0 || nFlags & (MF_SEPARATOR|MF_POPUP))

{

// nothing should be displayed

m_nIDTracking = 0;

}

else if (nItemID >= 0xF000 && nItemID < 0xF1F0) // max of 31 SC_s

{

//系统菜单的菜单项被选中

m_nIDTracking = ID_COMMAND_FROM_SC(nItemID);

ASSERT(m_nIDTracking >= AFX_IDS_SCFIRST &&

m_nIDTracking < AFX_IDS_SCFIRST + 31);

}

else if (nItemID >= AFX_IDM_FIRST_MDICHILD)

{

//如果选中的菜单项表示一个MDI子窗口

m_nIDTracking = AFX_IDS_MDICHILD;

}

else

{

//选中了一个菜单项

m_nIDTracking = nItemID;

}

pFrameWnd->m_nFlags |= WF_NOPOPMSG;

}

// when running in-place, it is necessary to cause a message to

// be pumped through the queue.

if (m_nIDTracking != m_nIDLastMessage && GetParent() != NULL)

PostMessage(WM_KICKIDLE);

}

OnMenuSelect的作用在于跟踪当前选中的菜单项，把菜单项对应的ID保存在CFrameWnd的成员变量m_nIDTracking中。

如果菜单项没有选中，或者选中的是一个子菜单，则设置nIDTracking为0。

如果选中的是系统菜单，则把系统菜单ID转换成一个对应的命令ID；保存该值到nIDTracking中。

如果选中的菜单是MDI子窗口创建时添加的（用来表示MDI子窗口），则转换菜单ID为AFX_IDS_MDICHILD，所有对应MDI子窗口的菜单项都使用AFX_IDS_MDICHILD，保存该值到nIDTracking中。

其他情况，就是选中菜单项的ID，把它保存到nIDTracking中。

跟踪被选择的菜单项并保存其ID在m_nIDTracking中，OnEnterIdle将用到m_nIDTracking。OnEnterIlde是消息WM_ENTERIDLE的处理函数，CFrameWnd的实现如下。

void CFrameWnd::OnEnterIdle(UINT nWhy, CWnd* pWho)

{

CWnd::OnEnterIdle(nWhy, pWho);

//若不是因为菜单选择进入该函数

//或者当前跟踪到的菜单项ID是最近一次处理的，则返回

if (nWhy != MSGF_MENU || m_nIDTracking == m_nIDLastMessage)

return;

//将发送消息WM_SETMESSAGETEXT

//在状态栏显示m_nIDTracking对应的字符串

SetMessageText(m_nIDTracking);

ASSERT(m_nIDTracking == m_nIDLastMessage);

}

当一个对话框或者菜单被显示的时候，Windows发送WM_ENTERIDLE消息。消息参数wParam取值为MSGF_DIALOGBOX或者MSGF_MENU。前者表示显示对话框时发送该消息，这时消息参数lParam表示对话框的句柄；后者表示显示菜单时发送该消息，这时消息参数lParam表示菜单的句柄。

经过消息映射，wParam的值传递给OnEnterIdle的参数nWhy，参数lParam的值传给参数who。如果参数1取值为MSGF_MENU，并且OnEnterIdle最近一次在菜单显示被调用时的菜单ID不同于这一次，则调用SetMessageText在状态栏显示对应ID命令的字符串，并且记录当前菜单ID到变量m_nIDTracking中（见消息处理函数OnSetMessageText）。

这样，在菜单选择期间，用户选择的菜单项ID被OnMenuSelect记录，在消息WM_ENTERIDLE处理时在状态栏显示ID命令的提示。

控制条的消息分发处理

工具条（包括对话框工具条）是一个子窗口，它们可以响应各种消息。如果按标准的Windows消息和命令消息的分发途径，一些消息不能送到拥有工具条的边框窗口，因为这些消息都将被工具条（对话框工具条）处理掉。所以，CControlBar覆盖了虚拟函数PreTranslateMessage和WindowProc以便实现特定的消息分发路径。

WindowProc

CControlBar 的WindowProc实现了如下的消息分发路径：

用户对控制条的输入消息或者分发给CControlBar及其派生类处理，或者送给拥有控制条的边框窗口处理，或者送给Windows控制“窗口类”的窗口过程处理。

WindowProc的实现如下：

LRESULT CControlBar::WindowProc(UINT nMsg,

WPARAM wParam, LPARAM lParam)

{

ASSERT_VALID(this);

LRESULT lResult;

switch (nMsg)

{

//本函数处理以下消息

case WM_NOTIFY:

case WM_COMMAND:

case WM_DRAWITEM:

case WM_MEASUREITEM:

case WM_DELETEITEM:

case WM_COMPAREITEM:

case WM_VKEYTOITEM:

case WM_CHARTOITEM:

//首先，工具条处理上述消息，如果没有处理，则接着给所属边框窗口处理

if (OnWndMsg(nMsg, wParam, lParam, &lResult))

return lResult;

else

return GetOwner()->SendMessage(nMsg, wParam, lParam);

}

// 最后，给基类CWnd，按缺省方式处理

lResult = CWnd::WindowProc(nMsg, wParam, lParam);

return lResult;

}

从上述实现可以看出，对于case范围内的一些消息，如WM_COMMAND、WM_NOTIFY等，控制条如果不能处理，则优先分发给其父窗口（边框窗口）处理，然后进入缺省处理，对于其他消息直接调用基类CWnd的实现（缺省处理）。基于这样的机制，可以把用户对工具条按钮或者对话框工具条内控制的操作解释成相应的命令消息，执行对应的命令处理。

对于工具条，当用户选中某个按钮时（鼠标左键弹起，消息是WM_LBUTTONUP），工具条窗口接收到WM_LBUTTONUP消息，该消息不在CControlBar::WindowProc特别处理的消息范围内，于是进行缺省处理，也就是说，把该消息派发给控制条对应的Windows控制的窗口过程处理（即被MFC统一窗口过程所取代的原窗口过程），该窗口过程则把该消息转换成一条命令消息WM_COMMAND，命令ID就是选中按钮对应的ID，然后，发送该命令消息给拥有工具条的边框窗口，导致相应的命令处理函数被调用。

对于对话框工具条，当工具条的某个控制子窗口被选中之后，则产生一条命令通知消息WM_COMMAND，wParam是控制子窗口的ID。CControlBar::WindowProc处理该消息。WindowProc首先调用OnWndMsg把消息发送给对话框工具条或者对话框工具条的基类处理，如果没有被处理的话，则OnWndMsg返回FALSE。接着，WindowPoc把命令消息传递给父窗口（边框窗口）处理。由于工具条的控制窗口的ID对应的是命令ID，所以，这条WM_COMMAND消息传递给边框窗口时，被解释成一个命令消息，相应的命令处理函数被调用。

PreTranslateMessage

CControlBar覆盖PreTranslateMessage函数，主要是为了在光标落在工具条按钮上时显示FLYBY信息，并且让对话框工具条过滤Dialog消息。

BOOL CControlBar::PreTranslateMessage(MSG* pMsg)

{

ASSERT_VALID(this);

ASSERT(m_hWnd != NULL);

//过滤Tooltip消息

if (CWnd::PreTranslateMessage(pMsg))

return TRUE; //是Tooltip消息，已经被处理

UINT message = pMsg->message;

//控制条的父窗口，对工具条和对话框工具条，总是创建它的边框窗口

CWnd* pOwner = GetOwner();

//必要的话，在状态条显示工具栏按钮的提示

if (((m_dwStyle & CBRS_FLYBY) ||

message == WM_LBUTTONDOWN || message == WM_LBUTTONUP) &&

((message >= WM_MOUSEFIRST && message <= WM_MOUSELAST) ||

(message >= WM_NCMOUSEFIRST &&

message <= WM_NCMOUSELAST)))

{

_AFX_THREAD_STATE* pThreadState = AfxGetThreadState();

//确认鼠标在工具栏的哪个按钮上

CPoint point = pMsg->pt;

ScreenToClient(&point);

TOOLINFO ti; memset(&ti, 0, sizeof(TOOLINFO));

ti.cbSize = sizeof(TOOLINFO);

int nHit = OnToolHitTest(point, &ti);

if (ti.lpszText != LPSTR_TEXTCALLBACK)

free(ti.lpszText);

BOOL bNotButton =

message == WM_LBUTTONDOWN && (ti.uFlags & TTF_NOTBUTTON);

if (message != WM_LBUTTONDOWN && GetKeyState(VK_LBUTTON) < 0)

nHit = pThreadState->m_nLastStatus;

//更新状态栏的提示信息

if (nHit < 0 || bNotButton)

{

if (GetKeyState(VK_LBUTTON) >= 0 || bNotButton)

{

SetStatusText(-1);

KillTimer(ID_TIMER_CHECK);

}

else

{

if (message == WM_LBUTTONUP)

{

SetStatusText(-1);

ResetTimer(ID_TIMER_CHECK, 200);

}

else

{

if ((m_nStateFlags & statusSet) || GetKeyState(VK_LBUTTON) < 0)

SetStatusText(nHit);

else if (nHit != pThreadState->m_nLastStatus)

ResetTimer(ID_TIMER_WAIT, 300);

}

pThreadState->m_nLastStatus = nHit;

}

// don’t translate dialog messages when in Shift+F1 help mode

CFrameWnd* pFrameWnd = GetTopLevelFrame();

if (pFrameWnd != NULL && pFrameWnd->m_bHelpMode)

return FALSE;

//在IsDialogMessage之前调用边框窗口的PreTranslateMessage，

//给边框窗口一个处理快捷键的机会

while (pOwner != NULL)

{

// allow owner & frames to translate before IsDialogMessage does

if (pOwner->PreTranslateMessage(pMsg))

return TRUE;

// try parent frames until there are no parent frames

pOwner = pOwner->GetParentFrame();

}

//过滤给对话框的消息和来自子窗口的消息

return PreTranslateInput(pMsg);

}

函数PreTranslateMessage主要是针对工具栏的，用来处理工具栏的CBRS_FLYBY特征。

对于对话框工具栏，也可以有CBRS_FLYBY特征。但在这种情况下，还需要把一些用户键盘输入解释成对话框消息。为了防止快捷键被解释成对话框消息，在调用函数PreTranslateInput之前，必须调用所有父边框窗口的PreTranslateMessage，给父边框窗口一个机会处理用户的输入消息，判断快捷键是否被按下。

关于Tooltip和本PreTranslateMessage函数处理Tooltip的详细解释见下一节的讨论。

Tooltip

工具条（或对话框工具条）如果指定了CBRS_TOOLTIPS风格（创建时指定或者创建后用SetBarStyle设置），则当鼠标落在某个按钮上（或者对话框的子控制窗口）时，在鼠标附近弹出一个文本框──Tooltip提示窗口。

如果还指定了CBRS_FLYBY风格，则还在状态栏显示和按钮（或子控制窗口）ID对应的字符串信息。当然，鼠标左键在某个按钮（或子控制窗口）按下时，也要在状态栏显示按钮的提示信息，当左键弹起时，则重置状态栏的状态。

如前所述，Tooltip窗口是Windows控制窗口。MFC使用了CToolTipCtrl类封装Tooltip的HWND窗口。在一个线程的生存期间，至多拥有一个Tooltip窗口，该窗口对象的指针保存在线程状态的成员变量m_pToolTip中。线程状态类AFX_THREAD_STATE的析构函数如果检测到m_pToolTip，则销毁MFC窗口对象和相应的Windows窗口对象。

CWnd对Tooltip消息的预处理

为了支持Tooltip显示，CWnd提供了以下函数：EnableTooltip，CancelTooltip，PreTranslateMessage，FilterTooltipMessage，OnToolHitTest。

EnableTooltip设置CBRS_TOOLTIP风格，相反CancelTootip取消这种风格。

PreTranslateMessage调用了FilterTooltipMessage过滤Tooltip消息。

OnToolHitTest是一个由CWnd定义的虚拟函数。CToolBar通过覆盖该函数，来检测对话框工具栏的控制子窗口或者工具栏按钮是否被选中、哪个被选中。

CWnd的PreTranslateMessage在4.5节讨论过，它的实现如下：

BOOL CWnd::PreTranslateMessage(MSG* pMsg)

{

//处理Tooltip消息

AFX_MODULE_STATE* pModuleState = _AFX_CMDTARGET_GETSTATE();

if (pModuleState->m_pfnFilterToolTipMessage != NULL)

//导致调用FilterTooltipMessage

(*pModuleState->m_pfnFilterToolTipMessage)(pMsg, this);

//不是Tooltip消息

return FALSE;

}

至于为什么MFC在模块状态中保存一个处理Tooltip消息的函数地址，通过该函数调用FilterTooltipMessage，是因为Tooltip窗口是模块线程局部有效的。

FilterTooltipMessage检测是否是Tooltip消息。如果是，在必要时创建一个CTooltipCtrl对象和对应的HWND，调用OnToolHitTest确定被选中的按钮或者控制的ID，接着弹出Tooltip窗口。

其他函数和CTooltipCtrl这里不作详细论述了。

处理TTN_NEEDTEXT通知消息

Tooltip窗口在弹出之前，它给工具条（或者对话框工具栏）的父窗口发送通知消息TTN_NEEDTEXT，请求得到要显示的文本。

CFrameWnd类处理了TTN_NEEDTEXT通知消息，消息处理函数是OnToolTipText。

消息映射的定义：

ON_NOTIFY_EX_RANGE(TTN_NEEDTEXTW, 0, 0xFFFF, OnToolTipText)

ON_NOTIFY_EX_RANGE(TTN_NEEDTEXTA, 0, 0xFFFF, OnToolTipText)

这里，使用了扩展消息映射宏把子窗口ID在0和0xFFFF之间的控制条窗口的通知消息TTN_NEEDTEXTA和TTN_NEEDTEXTW映射到函数OnToolTipText。

消息映射的实现：

BOOL CFrameWnd::OnToolTipText(UINT, NMHDR* pNMHDR, LRESULT* pResult)

{

ASSERT(pNMHDR->code == TTN_NEEDTEXTA ||

pNMHDR->code == TTN_NEEDTEXTW);

//让上一层的边框窗口优先处理该消息

if (GetRoutingFrame() != NULL)

return FALSE;

//分ANSI and UNICODE两个处理版本

TOOLTIPTEXTA* pTTTA = (TOOLTIPTEXTA*)pNMHDR;

TOOLTIPTEXTW* pTTTW = (TOOLTIPTEXTW*)pNMHDR;

TCHAR szFullText[256];

CString strTipText;

UINT nID = pNMHDR->idFrom;

//如果idFrom是一个子窗口，则得到其ID。

if (pNMHDR->code == TTN_NEEDTEXTA &&

(pTTTA->uFlags & TTF_IDISHWND) ||

pNMHDR->code == TTN_NEEDTEXTW &&

(pTTTW->uFlags & TTF_IDISHWND))

{

//idFrom是工具条的句柄

nID = _AfxGetDlgCtrlID((HWND)nID);

}

if (nID != 0) //若是0，为一分隔栏，不是按钮

{

//得到nID对应的字符串

AfxLoadString(nID, szFullText);

//从上面得到的字符串中取出Tooltip使用的文本

AfxExtractSubString(strTipText, szFullText, 1, ‘\n’);

}

//复制分离出的文本

#ifndef _UNICODE

if (pNMHDR->code == TTN_NEEDTEXTA)

lstrcpyn(pTTTA->szText, strTipText, _countof(pTTTA->szText));

else

_mbstowcsz(pTTTW->szText, strTipText, _countof(pTTTW->szText));

#else

if (pNMHDR->code == TTN_NEEDTEXTA)

_wcstombsz(pTTTA->szText, strTipText, _countof(pTTTA->szText));

else

lstrcpyn(pTTTW->szText, strTipText, _countof(pTTTW->szText));

#endif

*pResult = 0;

//显示Tooltip窗口

::SetWindowPos(pNMHDR->hwndFrom, HWND_TOP, 0, 0, 0, 0,

SWP_NOACTIVATE|SWP_NOSIZE|SWP_NOMOVE);

return TRUE; //消息处理完毕

}

OnToolTipText是一个扩展映射宏定义的消息处理函数，所以有一个UINT参数并且返回BOOL类型的值。不过，由于第二个参数（NMHDR）的idFrom域包含了有关信息，所以第一个UINT类型的参数没有用上。

OnToolTipText也是一个处理通知消息的例子。其中，通知参数wParam的结构如4.4.4.2节所述，具体如下：

typedef struct {

NMHDR hdr; //WM_NOTIFY消息要求的头

LPTSTR lpszText; //接收工具条按钮对应文本的缓冲区

WCHAR szText[80]; //接收Tooltip显示文本的缓冲区

HINSTANCE hinst; //包含了szText的实例句柄

UINT uflags; //标识了NMHDR的idFrom成员的意义

} TOOLTIPTEXT, FAR *LPTOOLTIPTEXT;

uflags如果等于TTF_IDISHWND，则表示通知消息来自对话框工具条的一个子窗口，而不是包含工具条按钮。

OnToolTipText根据子窗口ID或者工具条按钮对应的ID，得到字符串ID。如前所述，字符串ID由两部分组成，第二部分用于Tooltip显示，分隔符号是“\n”。根据这种格式OnToolTipText分离出Tooltip文本。

得到了Tooltip文本之后，可以有三种方法返回文本信息：把文本信息复制到szText缓冲区；把文本地址复制到lpszText；复制字符串资源的ID到lpszText、复制包含资源的实例句柄到hint。本函数采用了第一种方法。

在得到了返回的Tooltip文本之后，该文本在Tooltip窗口中被显示出来。

其他的OnToolHist等函数的实现不作详细的解释了。下面，讨论CBRS_FLYBY风格的实现。

CBRS_FLYBY风格的实现

CBRS_FLYBY是MFC提供的特征。当鼠标落在工具条按钮（或者对话框工具条的子窗口）上且稳定300ms后，在状态栏显示对应的提示信息。如果选中某个按钮或者子窗口（鼠标左键按下），则在相应命令消息处理之前在状态栏显示有关提示信息，之后（鼠标左键弹起），重新设置状态栏的状态信息。

为了支持这种特征，CControlBar覆盖虚拟函数PreTranslateMessage来处理和CBRS_FLYBY相关的消息，该函数前面已经讨论过，这里解释它如何处理CBRS_FLYBY特征。

如果同时具备

条件1：控制条具有CBRS_FLYBY特征或者当前消息是WM_LBUTTONUP或者WM_LBUTTONDOWN。

条件2：当前消息是鼠标消息（在WM_MOUSEFIRST和WM_MOUSELAST之间或者在WM_NCMOUSEFIRST和WM_NCMOUSELAST之间）。

则进行FLYBY处理。

首先，调用OnToolHitTest测试用户是否选中了工具条的按钮或者子窗口；

如果没有按钮或者子窗口被选中，则重新设置状态栏的状态，取消曾经设置的Check定时器。重置状态栏的状态时调用了SetStatusText（int nHit）函数，它是CControlBar内部使用的函数，若nHit等于-1，它向父窗口发送WM_POPMESSAGETEXT，消息参数是AFX_IDS_IDLEMESSAGE，结果导致状态栏显示“Ready”字样；否则发送WM_SETMESSAGETEXT消息，wParm设置为nHit，结果导致在状态栏显示ID为nHit的字符串。

如果有按钮或者子窗口被选中，若左键弹起，则重新设置状态栏信息，取消Wait定时器，并重新设置Check定时器，定时是200ms；若左键按下，则在状态栏显示消息ID对应的提示信息；若是其他鼠标消息，如果当前鼠标所在按钮（子窗口）不同于最近一次，则取消Check定时器，重新设置Wait定时器，定时300毫秒。

CControlBar覆盖了消息处理函数OnTimer，在指定时间之后，检查鼠标位置，如果鼠标还在某个按钮或者子窗口上，则在状态条显示提示信息。Wait定时器在等待之后准备在状态条显示信息，触发一次后被取消；Check定时器在等待之后，判断是否需要取消状态条当前显示的信息，重新设置状态条，若这样的话，同时也取消Check定时器。

注意，这些鼠标消息被处理之后，并没有终止，它们将继续被发送给控制条的窗口过程处理。

至此，CBRS_FLYBY特征的支持实现描述完毕。

禁止和允许

在MFC下，工具条、状态条还有一个重要的特征，就是自动地根据条件禁止或者允许使用某个按钮、窗格等。在4.4.5节命令消息的处理中，曾详细讨论了其实现原理，现在，详细地分析所涉及函数是如何实现的。有关的消息处理函数和虚拟函数如下。

处理WM_INITIALUPDATE消息的OnInitialUpdate；

处理WM_IDLEUPDATECMDUI消息的OnIdleUpdateCmdUI；

虚拟函数OnUpdateCmdUI。

回顾5.3.3.5节，在边框窗口的创建之后，给所有的子窗口发送初始化消息，控制子窗口用OnInitialUpdate响应它，调用OnIdleUpdateCmdUI完成状态的初始化。

OnIdleUpdateCmdUI还在IDLE处理时进行状态的更新处理，它生成用于处理状态更新消息的命令目标pTarget，然后调用虚拟函数OnUpdateCmdUI(pTarget，…)来更新工具栏或者状态栏的状态。

CControlBar的子类都实现了自己的OnUpdateCmdUI函数，用该函数生成适当的CCmdUI对象state，然后调用CCmdUI的DoUpdate（pTarget，…）给pTarget所指对象发送状态更新消息。为了完成具体的状态更新，从CCmdUI派生出CToolCmdUI和CStatusCCmUI，它们实现了自己的Enable、SetCheck等等。

初始化控制窗口

CControlBar使用OnInitialUpdate消息处理函数初始化控制窗口的状态。

void CControlBar::OnInitialUpdate()

{

//在窗口显示之前，更新状态

OnIdleUpdateCmdUI(TRUE, 0L);

}

CControlBar实现了OnInitialUpdate函数，通过它来处理WM_INITIALUPDATE消息。各个子类不必覆盖该消息处理函数。

处理Idle消息更新工具条状态

CControlBar使用OnIdleUpdateCmdUI消息处理函数处理IDLE消息。

LRESULT CControlBar::OnIdleUpdateCmdUI(WPARAM wParam, LPARAM)

{

// handle delay hide/show

BOOL bVis = GetStyle() & WS_VISIBLE;

UINT swpFlags = 0;

if ((m_nStateFlags & delayHide) && bVis)

swpFlags = SWP_HIDEWINDOW;

else if ((m_nStateFlags & delayShow) && !bVis)

swpFlags = SWP_SHOWWINDOW;

m_nStateFlags &= ~(delayShow|delayHide);

if (swpFlags != 0)

{

SetWindowPos(NULL, 0, 0, 0, 0, swpFlags|

SWP_NOMOVE|SWP_NOSIZE|SWP_NOZORDER|SWP_NOACTIVATE);

}

// the style must be visible and if it is docked

// the dockbar style must also be visible

if ((GetStyle() & WS_VISIBLE) &&

(m_pDockBar == NULL || (m_pDockBar->GetStyle() & WS_VISIBLE)))

{

//得到父边框窗口，状态更新消息将发送给它

CFrameWnd* pTarget = (CFrameWnd*)GetOwner();

if (pTarget == NULL || !pTarget->IsFrameWnd())

pTarget = GetParentFrame();

if (pTarget != NULL)

OnUpdateCmdUI(pTarget, (BOOL)wParam);

}

return 0L;

}

OnIdleUpdateCmdUI或者在初始化时被OnInitialUpdate调用，或者作为消息处理函数来处理WM_IDLEUPDATECMDUI消息。

CControlBar实现了OnIdleUpdateCmdUI函数，把具体的用户界面更新动作委托给虚拟函数OnUpdateCmdUI完成。

由于各个用户界面的特殊性，所以CControlBar本身没有实现OnUpdateCmdUI，而是留给各个派生类去实现。例如，CToolBar覆盖了OnUpdateCmdUI，其实现如下：

void CToolBar::OnUpdateCmdUI(CFrameWnd* pTarget, BOOL bDisableIfNoHndler)

{

//定义一个CCmdUI对象，CToolCmdUI派生于CCmdUI

CToolCmdUI state;

//给CCmdUI的各个成员赋值

state.m_pOther = this;

//得到总的按钮数目

state.m_nIndexMax = (UINT)DefWindowProc(TB_BUTTONCOUNT, 0, 0);

//逐个按钮进行状态更新

for (state.m_nIndex = 0; state.m_nIndex < state.m_nIndexMax; state.m_nIndex++)

{

//获取按钮状态信息

TBBUTTON button;

_GetButton(state.m_nIndex, &button);

//得到按钮的ID

state.m_nID = button.idCommand;

// ignore separators

if (!(button.fsStyle & TBSTYLE_SEP))

{

//优先让CToolBar对象处理状态更新消息

if (CWnd::OnCmdMsg(state.m_nID,

CN_UPDATE_COMMAND_UI, &state, NULL))

continue;//处理了更新消息，更新下一个按钮

//CToolBar没有处理，将发送给pTarget处理状态更新消息

//第二个参数bDisableIfNoHndler往下传

state.DoUpdate(pTarget, bDisableIfNoHndler);

}

//更新加到控制条中的对话框控制的状态

UpdateDialogControls(pTarget, bDisableIfNoHndler);

}

CToolBar的OnUpdateCmdUI函数完成工具条按钮的状态更新。它接受两个参数，参数1表示接收状态更新命令消息的对象，由CControlBar的函数OnIdleUpdateCmdUI传递过来，一般是边框窗口对象；参数2表示如果某条命令消息没有处理函数时，对应的用户接口对象是否被禁止。

OnUpdateCmdUI通过发送状态更新通知消息，逐个更新按钮的状态。更新消息首先让工具条对象处理，如果没有处理的话，送给边框窗口对象处理，导致状态更新命令消息的处理函数被调用，参见4.4.5节。

CStatusBar的OnUpdateCmdUI类似于此。

CDialogBar的OnUpdateCmdUI则调用了虚拟函数UpdateDialogControls来进行状态更新，CWnd提供了该函数的实现，过程类似于CToolBar的函数OnUpdateCmdUI。

菜单项的自动更新

那么，菜单项的自动更新如何实现的呢？OnInitMenuPopup在菜单项状态的自动更新中曾经被提到，其实现如下：

void CFrameWnd::OnInitMenuPopup(CMenu* pMenu, UINT, BOOL bSysMenu)

{

AfxCancelModes(m_hWnd);

if (bSysMenu)

return; // don’t support system menu

ASSERT(pMenu != NULL);

// check the enabled state of various menu items

CCmdUI state;

state.m_pMenu = pMenu;

ASSERT(state.m_pOther == NULL);

ASSERT(state.m_pParentMenu == NULL);

//判断菜单是否在顶层菜单(top level menu)中弹出，如果这样

//则设置m_pParentMenu指向顶层菜单，否则m_pParentMenu

//为空，表示它是一个二级弹出菜单

HMENU hParentMenu;

//是否是浮动式的弹出菜单（floating pop up menu）

if (AfxGetThreadState()->m_hTrackingMenu == pMenu->m_hMenu)

state.m_pParentMenu = pMenu; // parent == child for tracking popup

else if ((hParentMenu = ::GetMenu(m_hWnd)) != NULL)//

{

CWnd* pParent = GetTopLevelParent();

// child windows don’t have menus — need to go to the top!

//得到顶层窗口的菜单

if (pParent != NULL &&

(hParentMenu = ::GetMenu(pParent->m_hWnd)) != NULL)

{

int nIndexMax = ::GetMenuItemCount(hParentMenu);

//确定顶层窗口的菜单是否包含本菜单项

for (int nIndex = 0; nIndex < nIndexMax; nIndex++)

{

if (::GetSubMenu(hParentMenu, nIndex) == pMenu->m_hMenu)

{

//顶层窗口菜单是本菜单的父菜单

state.m_pParentMenu = CMenu::FromHandle(hParentMenu);

break;

}

//本菜单的菜单项(menu item)数量

state.m_nIndexMax = pMenu->GetMenuItemCount();

//对所有菜单项逐个进行状态更新

for (state.m_nIndex = 0; state.m_nIndex < state.m_nIndexMax;

state.m_nIndex++)

{

state.m_nID = pMenu->GetMenuItemID(state.m_nIndex);

if (state.m_nID == 0)

continue; // menu separator or invalid cmd – ignore it

ASSERT(state.m_pOther == NULL);

ASSERT(state.m_pMenu != NULL);

if (state.m_nID == (UINT)-1)

{

// 可能是一个popup菜单，得到其第一个子菜单项目

state.m_pSubMenu = pMenu->GetSubMenu(state.m_nIndex);

if (state.m_pSubMenu == NULL ||

(state.m_nID = state.m_pSubMenu->GetMenuItemID(0)) == 0 ||

state.m_nID == (UINT)-1)

{

continue; // 找不到popup菜单的子菜单项

}

//popup菜单不会被自动的禁止

state.DoUpdate(this, FALSE);

}

else

{

//正常的菜单项，若边框窗口的m_bAutoMenuEnable设置为

//TURE且菜单项非系统菜单，则自动enable/disable该菜单项

state.m_pSubMenu = NULL;

state.DoUpdate(this, m_bAutoMenuEnable && state.m_nID < 0xF000);

}

//经过菜单状态的更新处理，可能增加或删除了一些菜单项

UINT nCount = pMenu->GetMenuItemCount();

if (nCount < state.m_nIndexMax)

{

state.m_nIndex -= (state.m_nIndexMax – nCount);

while (state.m_nIndex < nCount &&

pMenu->GetMenuItemID(state.m_nIndex) == state.m_nID)

{

state.m_nIndex++;

}

state.m_nIndexMax = nCount;

}

菜单弹出之前，发送WM_INITMENUPOPUP消息，OnInitMenuPopup消息处理函数被调用，逐个更新菜单项目（menu item）的状态。程序员可以处理它们对应的状态更新消息，禁止/允许菜单项目被使用（disable/enable)，在菜单项目上打钩或者取消（checked/unchecked），等等。

显示或者隐藏工具栏和状态栏

这里讨论显示或者隐藏工具栏、状态栏的操作，以及工具栏、状态栏被显示/隐藏时，相关的两个菜单项ID_VIEW_STATUS_BAR、ID_VIEW_TOOLBAR的状态更新。这两个菜单命令及对应的状态更新命令是标准命令消息所包含的。MFC边框窗口实现了菜单命令消息的处理和菜单项状态的更新。

CFrameWnd提供了OnBarCheck来响应与ID_VIEW_STATUS_BAR、ID_VIEW_TOOLBAR菜单项对应的命令。

消息映射：

ON_COMMAND_EX(ID_VIEW_STATUS_BAR, OnBarCheck)

ON_COMMAND_EX(ID_VIEW_TOOLBAR, OnBarCheck)

这里，使用了扩展命令消息映射宏把ID_VIEW_STATUS_BAR和ID_VIEW_TOOLBAR命令映射给同一个函数OnBarCheck处理。

OnBarCheck函数的实现：

BOOL CFrameWnd::OnBarCheck(UINT nID)

{

ASSERT(ID_VIEW_STATUS_BAR == AFX_IDW_STATUS_BAR);

ASSERT(ID_VIEW_TOOLBAR == AFX_IDW_TOOLBAR);

//得到工具条或者状态条

CControlBar* pBar = GetControlBar(nID);

if (pBar != NULL)

{

//若控制条可见，则隐藏它；否则，显示它

ShowControlBar(pBar, (pBar->GetStyle() & WS_VISIBLE) == 0, FALSE);

//处理完毕

return TRUE;

}

//可以让下一个命令目标继续处理

return FALSE;

}

由于是扩展映射宏定义的消息处理函数，所以OnBarCheck函数有一个UINT类型的参数和一个BOOL返回值。

当用户从“View”菜单选择打了钩的“Toolbar”时，消息处理函数OnBarCheck被调用，参数就是菜单项的ID号ID_VIEW_TOOLBAR，它等于工具条的子窗口IDAFX_IDW_TOOLBAR。处理结果，工具条被隐藏；当再次选择该菜单项则工具条被显示。

处理状态条的过程类似于工具条的处理。

ShowControlBar是CFrameWnd的成员函数，参数1表示控制条对象指针，参数2表示显示(TRUE)或者隐藏(FALSE)，参数3表示是立即显示（FALSE）或者延迟显示（TRUE）。

如果工具条或者状态条被隐藏，则相应的菜单项ID_VIEW_STATUS_BAR 或者ID_VIEW_TOOLBAR 变成uncheked（菜单项被标记为没有选择），否则，checked（菜单项被标记选择）。CFrameWnd实现了这两个菜单项的状态更新处理，列举其中一个如下：

声明处理ID_VIEW_TOOLBAR的状态更新消息：

ON_UPDATE_COMMAND_UI(ID_VIEW_TOOLBAR, OnUpdateControlBarMenu)

函数的实现：

void CFrameWnd::OnUpdateControlBarMenu(CCmdUI* pCmdUI)

{

ASSERT(ID_VIEW_STATUS_BAR ==

AFX_IDW_STATUS_BAR);

ASSERT(ID_VIEW_TOOLBAR == AFX_IDW_TOOLBAR);

CControlBar* pBar = GetControlBar(pCmdUI->m_nID);

//存在工具栏

if (pBar != NULL)

{

//工具条窗口被显示则checked，被隐藏则uncheked

pCmdUI->SetCheck((pBar->GetStyle() & WS_VISIBLE) != 0);

return;

}

pCmdUI->ContinueRouting();

}

GetControlBar是CFrameWnd的成员函数，用来返回边框窗口的指定ID的控制条对象（指定ID是控制条的子窗口ID）。

泊位和漂浮

工具条可以泊位在边框窗口的任一边(上、下、左、右)，或者漂浮在屏幕上的任何地方。

实现泊位的方法

首先，边框窗口调用CFrameWnd::EnableDocking函数使控制条泊位在边框窗口中有效，指明在边框窗口的哪边接受泊位。如果想在任何边都可以泊位，则使用参数CBRS_ALIGN_ANY。

然后，工具条调用ControlBar::EnableDocking使泊位对工具条有效，如果在调用ControlBar::EnableDocking时指定的泊位目的边和边框窗口能够泊位的边不符合，那么工具条不能泊位，它将漂浮。

最后，边框窗口调用CFrameWnd::DockControlBar泊位工具条。

泊位后形成窗口层次关系

边框窗口、泊位条、工具条的包含关系如下：

边框窗口

泊位条1

工具条1

工具条2

…

泊位条2

…

边框窗口包含1到4个泊位条子窗口，每个泊位条包含若干个控制条子窗口。

泊位的实现

CFrameWnd::EnableDocking指定哪边接受泊位，则为泊位准备一个泊位条。泊位条用CDockBar描述，派生于CControlBar。如果指定任何边都可以泊位，则创建四个CDockBar对象和对应的HWND窗口。然后，调用ControlBar::EnableDocking在对应的泊位条内安置工具条。

MFC设计了CDockBar类和CFrameWnd的一些函数来实现泊位，具体代码实现在此不作详细讨论。

实现漂浮工具条的方法：

边框窗口调用FloatControlBar实现工具条的漂浮。

漂浮的实现：

首先，创建一个微型漂浮边框窗口，该边框窗口有一个泊位条。

然后，在微型边框窗口的泊位条内放置工具条。

MFC设计了微型边框类CMiniFrameWnd，在此基础上派生出微型泊位边框窗口类CMiniDockFrameWnd。CMiniDockFrameWnd增加了一个CDockBar类型成员变量m_wndDockBar，即泊位条。

在CMiniDockFrameWnd对象被创建时，创建泊位条m_wndDockBar。泊位条m_wndDockBar的父窗口如同CMiniDockFrameWnd的父窗口一样，是调用FloatControlBar的边框窗口，而不是微型泊位边框窗口。微型边框窗口和泊位条创建完成之后，调用ControlBar::DockControlBar泊位工具条在CMiniDockFrameWnd窗口。

具体的代码实现略。

SOCKET类的设计和实现

WinSock基本知识

这里不打算系统地介绍socket或者WinSock的知识。首先介绍WinSock API函数，讲解阻塞/非阻塞的概念；然后介绍socket的使用。

WinSock API

Socket接口是网络编程（通常是TCP/IP协议，也可以是其他协议）的API。最早的Socket接口是Berkeley接口，在Unxi操作系统中实现。WinSock也是一个基于Socket模型的API，在Microsoft Windows操作系统类中使用。它在Berkeley接口函数的基础之上，还增加了基于消息驱动机制的Windows扩展函数。Winscok1.1只支持TCP/IP网络，WinSock2.0增加了对更多协议的支持。这里，讨论TCP/IP网络上的API。

Socket接口包括三类函数：

第一类是WinSock API包含的Berkeley socket函数。这类函数分两部分。第一部分是用于网络I/O的函数，如

accept、Closesocket、connect、recv、recvfrom、Select、Send、Sendto

另一部分是不涉及网络I/O、在本地端完成的函数，如

bind、getpeername、getsockname、getsocketopt、htonl、htons、inet_addr、inet_nton

ioctlsocket、listen、ntohl、ntohs、setsocketopt、shutdow、socket等

第二类是检索有关域名、通信服务和协议等Internet信息的数据库函数，如

gethostbyaddr、gethostbyname、gethostname、getprotolbyname

getprotolbynumber、getserverbyname、getservbyport。

第三类是Berkekley socket例程的Windows专用的扩展函数，如gethostbyname对应的WSAAsynGetHostByName（其他数据库函数除了gethostname都有异步版本），select对应的WSAAsynSelect，判断是否阻塞的函数WSAIsBlocking，得到上一次Windsock API错误信息的WSAGetLastError，等等。

从另外一个角度，这些函数又可以分为两类，一是阻塞函数，一是非阻塞函数。所谓阻塞函数，是指其完成指定的任务之前不允许程序调用另一个函数，在Windows下还会阻塞本线程消息的发送。所谓非阻塞函数，是指操作启动之后，如果可以立即得到结果就返回结果，否则返回表示结果需要等待的错误信息，不等待任务完成函数就返回。

首先，异步函数是非阻塞函数；

其次，获取远地信息的数据库函数是阻塞函数（因此，WinSock提供了其异步版本）；

在Berkeley socket函数部分中，不涉及网络I/O、本地端工作的函数是非阻塞函数；

在Berkeley socket函数部分中，网络I/O的函数是可阻塞函数，也就是它们可以阻塞执行，也可以不阻塞执行。这些函数都使用了一个socket，如果它们使用的socket是阻塞的，则这些函数是阻塞函数；如果它们使用的socket是非阻塞的，则这些函数是非阻塞函数。

创建一个socket时，可以指定它是否阻塞。在缺省情况下，Berkerley的Socket函数和WinSock都创建“阻塞”的socket。阻塞socket通过使用select函数或者WSAAsynSelect函数在指定操作下变成非阻塞的。WSAAsyncSelect函数原型如下。

int WSAAsyncSelect(

SOCKET s,

HWND hWnd,

u_int wMsg,

long lEvent

);

其中，参数1指定了要操作的socket句柄；参数2指定了一个窗口句柄；参数3指定了一个消息，参数4指定了网络事件，可以是多个事件的组合，如：

FD_READ 准备读

FD_WRITE 准备写

FD_OOB 带外数据到达

FD_ACCEPT 收到连接

FD_CONNECT 完成连接

FD_CLOSE 关闭socket。

用OR操作组合这些事件值，如FD_READ|FD_WRITE

WSAAsyncSelect函数表示对socket s监测lEvent指定的网络事件，如果有事件发生，则给窗口hWnd发送消息wMsg。

假定应用程序的一个socket s指定了监测FD_READ事件，则在FD_READ事件上变成非阻塞的。当read函数被调用时，不管是否读到数据都马上返回，如果返回一个错误信息表示还在等待，则在等待的数据到达后，消息wMsg发送给窗口hWnd，应用程序处理该消息读取网络数据。

对于异步函数的调用，以类似的过程最终得到结果数据。以gethostbyname的异步版本的使用为例进行说明。该函数原型如下：

HANDLE WSAAsyncGetHostByName(

HWND hWnd,

u_int wMsg,

const char FAR *name,

char FAR *buf,

int buflen

);

在调用WSAAsyncGetHostByName启动操作时，不仅指定主机名字name，还指定了一个窗口句柄hWnd，一个消息ID wMsg，一个缓冲区及其长度。如果不能立即得到主机地址，则返回一个错误信息表示还在等待。当要的数据到达时，WinSock DLL给窗口hWnd发送消息wMsg告知得到了主机地址，窗口过程从指定的缓冲区buf得到主机地址。

使用异步函数或者非阻塞的socket，主要是为了不阻塞本线程的执行。在多进程或者多线程的情况下，可以使用两个线程通过同步手段来完成异步函数或者非阻塞函数的功能。

Socket的使用

WinSock以DLL的形式提供，在调用任何WinSock API之前，必须调用函数WSAStartup进行初始化，最后，调用函数WSACleanUp作清理工作。

MFC使用函数AfxSocketInit包装了函数WSAStartup，在WinSock应用程序的初始化函数IninInstance中调用AfxSocketInit进行初始化。程序不必调用WSACleanUp。

Socket是网络通信过程中端点的抽象表示。Socket在实现中以句柄的形式被创建，包含了进行网络通信必须的五种信息：连接使用的协议，本地主机的IP地址，本地进程的协议端口，远地主机的IP地址，远地进程的协议端口。

要使用socket，首先必须创建一个socket；然后，按要求配置socket；接着，按要求通过socket接收和发送数据；最后，程序关闭此socket。

为了创建socket，使用socket函数得到一个socket句柄：

socket_handle = socket(protocol_family. Socket_type, protocol);

其中：protocol_family指定socket使用的协议，取值PF_INET，表示Internet(TCP/IP)协议族；Socket_type指socket面向连接或者使用数据报；第三个参数表示使用TCP或者UDP协议。

当一个socket被创建时，WinSock将为一个内部结构分配内存，在此结构中保存此socket的信息，到此，socket连接使用的协议已经确定。

创建了socket之后，配置socket。

对于面向连接的客户，WinSock自动保存本地IP地址和选择协议端口，但是必须使用connect函数配置远地IP地址和远地协议端口：

result = connect(socket_handle, remote_socket_address, address_length)

remote_socket_address是一个指向特定socket结构的指针，该地址结构为socket保存了地址族、协议端口、网络主机地址。

面向连接的服务器则使用bind指定本地信息，使用listen和accept获取远地信息。

使用数据报的客户或者服务器使用bind给socket指定本地信息，在发送或者接收数据时指定远地信息。

bind给socket指定一个本地IP地址和协议端口，如下：

result = bind( socket_hndle, local_socket_address, address_length)

参数类型同connect。

函数listen监听bind指定的端口，如果有远地客户请求连接，使用accept接收请求，创建一个新的socket，并保存信息。

socket_new = accept(socket_listen, socket_address, address_length)

在socket配置好之后，使用socket发送或者接收数据。

面向连接的socket使用send发送数据，recv接收数据；

使用数据报的socket使用sendto发送数据，recvfrom接收数据。

MFC对WinSockt API的封装

MFC提供了两个类CAsyncSocket和CSocket来封装WinSock API，这给程序员提供了一个更简单的网络编程接口。

CAsyncSocket在较低层次上封装了WinSock API，缺省情况下，使用该类创建的socket是非阻塞的socket，所有操作都会立即返回，如果没有得到结果，返回WSAEWOULDBLOCK，表示是一个阻塞操作。

CSocket建立在CAsyncSocket的基础上，是CAsyncSocket的派生类。也就是缺省情况下使用该类创建的socket是非阻塞的socket，但是CSocket的网络I/O是阻塞的，它在完成任务之后才返回。CSocket的阻塞不是建立在“阻塞”socket的基础上，而是在“非阻塞”socket上实现的阻塞操作，在阻塞期间，CSocket实现了本线程的消息循环，因此，虽然是阻塞操作，但是并不影响消息循环，即用户仍然可以和程序交互。

CAsyncSocket

CAsyncSocket封装了低层的WinSock API，其成员变量m_hSocket保存其对应的socket句柄。使用CAsyncSocket的方法如下：

首先，在堆或者栈中构造一个CAsyncSocket对象，例如：

CAsyncSocket sock；或者

CAsyncSocket *pSock = new CAsyncSocket；

其次，调用Create创建socket，例如：

使用缺省参数创建一个面向连接的socket

sock.Create()

指定参数参数创建一个使用数据报的socket，本地端口为30

pSocket.Create(30, SOCK_DGRM)；

其三，如果是客户程序，使用Connect连接到远地；如果是服务程序，使用Listen监听远地的连接请求。

其四，使用成员函数进行网络I/O。

最后，销毁CAsyncSocket，析构函数调用Close成员函数关闭socket。

下面，分析CAsyncSocket的几个函数，从中可以看到它是如何封装低层的WinSock API，简化有关操作的；还可以看到它是如何实现非阻塞的socket和非阻塞操作。

socket对象的创建和捆绑

（1）Create函数

首先，讨论Create函数，分析socket句柄如何被创建并和CAsyncSocket对象关联。Create的实现如下：

BOOL CAsyncSocket::Create(UINT nSocketPort, int nSocketType,

long lEvent, LPCTSTR lpszSocketAddress)

{

if (Socket(nSocketType, lEvent))

{

if (Bind(nSocketPort,lpszSocketAddress))

return TRUE;

int nResult = GetLastError();

Close();

WSASetLastError(nResult);

}

return FALSE;

}

其中：

参数1表示本socket的端口，缺省是0，如果要创建数据报的socket，则必须指定一个端口号。

参数2表示本socket的类型，缺省是SOCK_STREAM，表示面向连接类型。

参数4表示本socket的IP地址字符串，缺省是NULL。

Create调用Socket函数创建一个socket，并把它捆绑在this所指对象上，监测指定的网络事件。参数2和3被传递给Socket函数，如果希望创建数据报的socket，不要使用缺省参数，指定参数2是SOCK_DGRM。

如果上一步骤成功，则调用bind给新的socket分配端口和IP地址。

（2）Socket函数

接着，分析Socket函数，其实现如下：

BOOL CAsyncSocket::Socket(int nSocketType, long lEvent,

int nProtocolType, int nAddressFormat)

{

ASSERT(m_hSocket == INVALID_SOCKET);

m_hSocket = socket(nAddressFormat,nSocketType,nProtocolType);

if (m_hSocket != INVALID_SOCKET)

{

CAsyncSocket::AttachHandle(m_hSocket, this, FALSE);

return AsyncSelect(lEvent);

}

return FALSE;

}

其中：

参数1表示Socket类型，缺省值是SOCK_STREAM。

参数2表示希望监测的网络事件，缺省值同Create，指定了全部事件。

参数3表示使用的协议，缺省是0。实际上，SOCK_STREAM类型的socket使用TCP协议，SOCK_DGRM的socket则使用UDP协议。

参数4表示地址族（地址格式），缺省值是PF_INET（等同于AF_INET）。对于TCP/IP来说，协议族和地址族是同值的。

在socket没有被创建之前，成员变量m_hSocket是一个无效的socket句柄。Socket函数把协议族、socket类型、使用的协议等信息传递给WinSock API函数socket，创建一个socket。如果创建成功，则把它捆绑在this所指对象。

（3）捆绑（Attatch）

捆绑过程类似于其他Windows对象，将在模块线程状态的WinSock映射中添加一对新的映射：this所指对象和新创建的socket对象的映射。

另外，如果本模块线程状态的“socket窗口”没有创建，则创建一个，该窗口在异步操作时用来接收WinSock的通知消息，窗口句柄保存到模块线程状态的m_hSocketWindow变量中。函数AsyncSelect将指定该窗口为网络事件消息的接收窗口。

函数AttachHandle的实现在此不列举了。

（4）指定要监测的网络事件

在捆绑完成之后，调用AsyncSelect指定新创建的socket将监测的网络事件。AsyncSelect实现如下：

BOOL CAsyncSocket::AsyncSelect(long lEvent)

{

ASSERT(m_hSocket != INVALID_SOCKET);

_AFX_SOCK_THREAD_STATE* pState = _afxSockThreadState;

ASSERT(pState->m_hSocketWindow != NULL);

return WSAAsyncSelect(m_hSocket, pState->m_hSocketWindow,

WM_SOCKET_NOTIFY, lEvent) != SOCKET_ERROR;

}

函数参数lEvent表示希望监视的网络事件。

_ afxSockThreadState得到的是当前的模块线程状态，m_ hSocketWindow是本模块在当前线程的“socket窗口”，指定监视m_hSocket的网络事件，如指定事件发生，给窗口m_hSocketWindow发送WM_SOCKET_NOTIFY消息。

被指定的网络事件对应的网络I/O将是异步操作，是非阻塞操作。例如：指定FR_READ导致Receive是一个异步操作，如果不能立即读到数据，则返回一个错误WSAEWOULDBLOCK。在数据到达之后，WinSock通知窗口m_hSocketWindow，导致OnReceive被调用。

指定FR_WRITE导致Send是一个异步操作，即使数据没有送出也返回一个错误WSAEWOULDBLOCK。在数据可以发送之后，WinSock通知窗口m_hSocketWindow，导致OnSend被调用。

指定FR_CONNECT导致Connect是一个异步操作，还没有连接上就返回错误信息WSAEWOULDBLOCK，在连接完成之后，WinSock通知窗口m_hSocketWindow，导致OnConnect被调用。

对于其他网络事件，就不一一解释了。

所以，使用CAsyncSocket时，如果使用Create缺省创建socket，则所有网络I/O都是异步操作，进行有关网络I/O时则必须覆盖以下的相关函数：

OnAccept、OnClose、OnConnect、OnOutOfBandData、OnReceive、OnSend。

（5）Bind函数

经过上述过程，socket创建完毕，下面，调用Bind函数给m_hSocket指定本地端口和IP地址。Bind的实现如下：

BOOL CAsyncSocket::Bind(UINT nSocketPort, LPCTSTR lpszSocketAddress)

{

USES_CONVERSION;

//使用WinSock的地址结构构造地址信息

SOCKADDR_IN sockAddr;

memset(&sockAddr,0,sizeof(sockAddr));

//得到地址参数的值

LPSTR lpszAscii = T2A((LPTSTR)lpszSocketAddress);

//指定是Internet地址类型

sockAddr.sin_family = AF_INET;

if (lpszAscii == NULL)

//没有指定地址，则自动得到一个本地IP地址

//把32比特的数据从主机字节序转换成网络字节序

sockAddr.sin_addr.s_addr = htonl(INADDR_ANY);

else

{

//得到地址

DWORD lResult = inet_addr(lpszAscii);

if (lResult == INADDR_NONE)

{

WSASetLastError(WSAEINVAL);

return FALSE;

}

sockAddr.sin_addr.s_addr = lResult;

}

//如果端口为0，则WinSock分配一个端口（1024—5000）

//把16比特的数据从主机字节序转换成网络字节序

sockAddr.sin_port = htons((u_short)nSocketPort);

//Bind调用WinSock API函数bind

return Bind((SOCKADDR*)&sockAddr, sizeof(sockAddr));

}

其中：函数参数1指定了端口；参数2指定了一个包含本地地址的字符串，缺省是NULL。

函数Bind首先使用结构SOCKADDR_IN构造地址信息。该结构的域sin_family表示地址格式（TCP/IP同协议族），赋值为AF_INET（Internet地址格式）；域sin_port表示端口，如果参数1为0，则WinSock分配一个端口给它，范围在1024和5000之间；域sin_addr是表示地址信息，它是一个联合体，其中s_addr表示如下形式的字符串，“28.56.22.8”。如果参数没有指定地址，则WinSock自动地得到本地IP地址（如果有几个网卡，则使用其中一个的地址）。

（6）总结Create的过程

首先，调用socket函数创建一个socket；然后把创建的socket对象映射到CAsyncSocket对象（捆绑在一起），指定本socket要通知的网络事件，并创建一个“socket窗口”来接收网络事件消息，最后，指定socket的本地信息。

下一步，是使用成员函数Connect连接远地主机，配置socket的远地信息。函数Connect类似于Bind，把指定的远地地址转换成SOCKADDR_IN对象表示的地址信息（包括网络字节序的转换），然后调用WinSock函数Connect连接远地主机，配置socket的远地端口和远地IP地址。

异步网络事件的处理

当网络事件发生时，“socket窗口”接收WM_SOCKET_NOTIFY消息，消息处理函数OnSocketNotify被调用。“socket窗口”的定义和消息处理是MFC实现的，这里不作详细的讨论。

OnSocketNotify回调CAsyncSocket的成员函数DoCallBack，DoCallBack调用事件处理函数，如OnRead、OnWrite等。摘录DoCallBack的一段代码如下：

switch (WSAGETSELECTEVENT(lParam))

{

case FD_READ:

{

DWORD nBytes;

//得到可以一次读取的字节数

pSocket->IOCtl(FIONREAD, &nBytes);

if (nBytes != 0)

pSocket->OnReceive(nErrorCode);

}

break;

case FD_WRITE:

pSocket->OnSend(nErrorCode);

break;

case FD_OOB:

pSocket->OnOutOfBandData(nErrorCode);

break;

case FD_ACCEPT:

pSocket->OnAccept(nErrorCode);

break;

case FD_CONNECT:

pSocket->OnConnect(nErrorCode);

break;

case FD_CLOSE:

pSocket->OnClose(nErrorCode);

break;

lParam是WM_SOCKET_NOFITY的消息参数，OnSocketNotify传递给函数DoCallBack，表示通知事件。

函数IOCtl是CAsyncSocket的成员函数，用来对socket的I/O进行控制。这里的使用表示本次调用Receive函数至多可以读nBytes个字节。

从上面的讨论可以看出，从创建socket到网络I/O，CAsyncSocket直接封装了低层的WinSock API，简化了WinSock编程，实现了一个异步操作的界面。如果希望某个操作是阻塞操作，则在调用Create时不要指定该操作对应的网络事件。例如，希望Connect和Send是阻塞操作，在任务完成之后才返回，则可以使用如下的语句：

pSocket->Create(0, SOCK_STREAM,

FR_WRITE|FR_OOB|FR_ACCEPT|FR_CLOSE);

这样，在Connect和Send时，如果是用户界面线程的话，可能阻塞线程消息循环。所以，最好在工作者线程中使用阻塞操作。

CSocket

如果希望在用户界面线程中使用阻塞socket，则可以使用CSocket。它在非阻塞socket基础之上实现了阻塞操作，在阻塞期间实现了消息循环。

对于CSocket，处理网络事件通知的函数OnAccept、OnClose、OnReceive仍然可以使用，OnConnect、OnSend在CSocket中永远不会被调用，另外OnOutOfBandData在CSocket中不鼓励使用。

CSocket对象在调用Connect、Send、Accept、Close、Receive等成员函数后，这些函数在完成任务之后（连接被建立、数据被发送、连接请求被接收、socket被关闭、数据被读取）之后才会返回。因此，Connect和Send不会导致OnConnect和OnSend被调用。如果覆盖虚拟函数OnReceive、OnAccept、OnClose，不主动调用Receive、Accept、Close，则在网络事件到达之后导致对应的虚拟函数被调用，虚拟函数的实现应该调用Receive、Accept、Close来完成操作。下面，就一个函数Receive来考察CSocket如何实现阻塞操作和消息循环的。

int CSocket::Receive(void* lpBuf, int nBufLen, int nFlags)

{

//m_pbBlocking是CSocket的成员变量，用来标识当前是否正在进行

//阻塞操作。但不能同时进行两个阻塞操作。

if (m_pbBlocking != NULL)

{

WSASetLastError(WSAEINPROGRESS);

return FALSE;

}

//完成数据读取

int nResult;

while ((nResult = CAsyncSocket::Receive(lpBuf, nBufLen, nFlags))

== SOCKET_ERROR)

{

if (GetLastError() == WSAEWOULDBLOCK)

{

//进入消息循环，等待网络事件FD_READ

if (!PumpMessages(FD_READ))

return SOCKET_ERROR;

}

else

return SOCKET_ERROR;

}

return nResult;

}

其中：

参数1指定一个缓冲区保存读取的数据；参数2指定缓冲区的大小；参数3取值MSG_PEEK（数据拷贝到缓冲区，但不从输入队列移走），或者MSG_OOB（处理带外数据），或者MSG_PEEK|MSG_OOB。

Receive函数首先判断当前CSocket对象是否正在处理一个阻塞操作，如果是，则返回错误WSAEINPROGRESS；否则，开始数据读取的处理。

读取数据时，如果基类CAsyncSocket的Receive读取到了数据，则返回；否则，如果返回一个错误，而且错误号是WSAEWOULDBLOCK，则表示操作阻塞，于是调用PumpMessage进入消息循环等待数据到达（网络事件FD_READ发生）。数据到达之后退出消息循环，再次调用CAsyncSocket的Receive读取数据，直到没有数据可读为止。

PumpMessages是CSocket的成员函数，它完成以下工作：

（1）设置m_pbBlocking，表示进入阻塞操作。

（2）进行消息循环，如果有以下事件发生则退出消息循环：收到指定定时器的定时事件消息WM_TIMER，退出循环，返回TRUE；收到发送给本socket的消息WM_SOCKET_NOTIFY，网络事件FD_CLOSE或者等待的网络事件发生，退出循环，返回TRUE；发送错误或者收到WM_QUIT消息，退出循环，返回FALSE；

（3）在消息循环中，把WM_SOCKET_DEAD消息和发送给其他socket的通知消息WM_SOCKET_NOFITY放进模块线程状态的通知消息列表m_listSocketNotifications，在阻塞操作完成之后处理；对其他消息，则把它们送给目的窗口的窗口过程处理。

CSocketFile

MFC还提供了一个网络编程模式，可以充分利用CSocket的特性。该模式的基础是CSocketFile类。使用方法如下：

首先，构造一个CSocket对象；调用Create函数创建一个socket对象（SOCK_STREAM类型）。

接着，如果是客户程序，调用Connect连接到远地主机；如果是服务器程序，先调用Listen监听socket端口，收到连接请求后调用Accept接收请求。

然后，创建一个和CSocket对象关联的CSocketFile对象，创建一个和CSocketFile对象关联的CArchive对象，指定CArchive对象是用于读或者写。如果既要读又要写，则创建两个CArchive对象。

创建工作完成之后，使用CArchive对象在客户和服务器之间传送数据

使用完毕，销毁CArchive对象、CSocketFile对象、CSocket对象。

从前面的章节可以知道，CArchive可以以一个CFile对象为基础，通过<<和>>操作符完成对文件的二进制流的操作。所以可以从CFile派生一个类，实现CFile的操作界面（Read和Write）。由于CSocket提供了阻塞操作，所以完全可以像读写文件一样读写socket数据。

下面，分析CSocketFile的设计和实现。

CSocketFile的构造函数和析构函数的实现

构造函数的实现

CSocketFile::CSocketFile(CSocket* pSocket, BOOL bArchiveCompatible)

{

m_pSocket = pSocket;

m_bArchiveCompatible = bArchiveCompatible;

#ifdef _DEBUG

ASSERT(m_pSocket != NULL);

ASSERT(m_pSocket->m_hSocket != INVALID_SOCKET);

int nType = 0;

int nTypeLen = sizeof(int);

ASSERT(m_pSocket->GetSockOpt(SO_TYPE,&nType,&nTypeLen));

ASSERT(nType == SOCK_STREAM);

#endif // _DEBUG

}

其中：

构造函数的参数1指向关联的CSocket对象，被保存在成员变量m_pSocket中；

参数2指定该对象是否和一个CArchive对象关联（不关联则独立使用），被保存在成员变量bArchiveCompatible中。

Degug部分用于检测m_pSocket是否是SOCK_STREAM类型。

析构函数的实现

CSocketFile::~CSocketFile()

{

}

（2）CSocketFile的读写的实现

分析CSocketFile如何用文件的读写实现网络I/O。

文件读的实现

UINT CSocketFile::Read(void* lpBuf, UINT nCount)

{

ASSERT(m_pSocket != NULL);

int nRead;

//CSocketFile对象独立使用

if (!m_bArchiveCompatible)

{

int nLeft = nCount;

PBYTE pBuf = (PBYTE)lpBuf;

//读完nCount个字节的数据

while(nLeft > 0)

{

//CSocket的Receive，阻塞操作，读取到数据才继续

nRead = m_pSocket->Receive(pBuf, nLeft);

if (nRead == SOCKET_ERROR)

{

int nError = m_pSocket->GetLastError();

AfxThrowFileException(CFileException::generic, nError);

ASSERT(FALSE);

}

else if (nRead == 0)

{

return nCount – nLeft;

}

nLeft -= nRead;

pBuf += nRead;

}

return nCount – nLeft;

}

//和一个CArchive对象关联使用

//读取数据，能读多少是多少

nRead = m_pSocket->Receive(lpBuf, nCount, 0);

if (nRead == SOCKET_ERROR)

{

int nError = m_pSocket->GetLastError();

AfxThrowFileException(CFileException::generic, nError);

ASSERT(FALSE);

}

return nRead;

}

文件写的实现

void CSocketFile::Write(const void* lpBuf, UINT nCount)

{

ASSERT (m_pSocket!=NULL);

//CSocket的函数Send，阻塞操作，发送完毕才继续

int nWritten = m_pSocket->Send(lpBuf, nCount);

if (nWritten == SOCKET_ERROR)

{

int nError = m_pSocket->GetLastError();

AfxThrowFileException(CFileException::generic, nError);

}

从CSockefFile的读写实现可以看出，CSocketFile如果独立使用，在Read操作时可能出现无限等待，因为数据是分多个消息多次送达的，没有读取到指定长度的数据并不表示数据读取完毕。但是和CArchive配合使用，则仅仅读取到数据就返回。至于数据是否读取完毕，可以使用CArchive的IsBufferEmpty函数来判断。

其他CFile界面，CSocketFile没有实现。

从CScocketFile的设计和实现来看，CSocketFile是使用CSocket的一个很好的例子，也是使用CFile的一个例子。

今天的文章MFC 教程分享到此就结束了，感谢您的阅读，如果确实帮到您，您可以动动手指转发给其他人。

版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请发送邮件至举报，一经查实，本站将立刻删除。
如需转载请保留出处：https://bianchenghao.cn/55186.html

创建者	被创建的对象
应用程序对象	文档模板
文档模板	文档
文档模板	边框窗口
边框窗口	视

相关推荐

发表回复