MFC 教程

原文作者:李久进

名称
1_MFC概述
2_MFC和Win32
3_CObject类
4_消息映射的实现
5_MFC对象的创建
6_应用程序的退出
7_MFC的DLL
8_MFC的进程和线程
9_MFC的状态
10_内存分配方式和调试机制
11_MFC下的文件类
12_对话框和对话框类CDialog
13_MFC工具条和状态栏
14_SOCKET类的设计和实现

 


 

 

  1. MFC概述

     

    1. MFC是一个编程框架

       

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

      1. 封装

         

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

        (1)对Win32应用程序编程接口的封装

        用一个C++ Object来包装一个Windows Object。例如:class CWnd是一个C++ window object,它把Windows window(HWND)和Windows window有关的API函数封装在C++ window object的成员函数内,后者的成员变量m_hWnd就是前者的窗口句柄。

        (2)对应用程序概念的封装

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

        (3)对COM/OLE特性的封装

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

        (4)对ODBC功能的封装

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

      2. 继承

         

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

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

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

      3. 虚拟函数和动态约束

         

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

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

      4. MFC的宏观框架体系

         

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

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

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

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

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

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

    2. MDI应用程序的构成

       

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

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

      1. 构成应用程序的对象

         

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

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

        (1)应用程序

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

        (2)边框窗口

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

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

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

        (3)文档边框窗口

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

        (4)文档

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

        (5)视

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

        (6)文档模板

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

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

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

         

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

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

      3. 构成应用程序的文件

         

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

 

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

头文件

用途

stdafx.h

标准AFX头文件

resource.h

定义了各种资源ID

t.h

#include "resource.h"

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

childfrm.h

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

mainfrm.h

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

tdoc.h

定义了从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__是一个宏,在编译器编译过程中给它赋值为当前正在编译的文件名称。

 


 

 

  1. MFC和Win32

     

    1. MFC Object和Windows Object的关系

       

MFC中最重要的封装是对Win32 API的封装,因此,理解Windows Object和MFC Object (C++对象,一个C++类的实例)之间的关系是理解MFC的关键之一。所谓Windows Object(Windows对象)是Win32下用句柄表示的Windows操作系统对象;所谓MFC Object (MFC对象)是C++对象,是一个C++类的实例,这里(本书范围内)MFC Object是有特定含义的,指封装Windows Object的C++ Object,并非指任意的C++ Object。

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

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

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

  1. 从数据结构上比较

     

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

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

    MFC给这些类定义了一个成员变量来保存MFC Object对应的Windows Object的句柄。对于设备描述表CDC类,将保存两个HDC句柄。

  2. 从层次上讲比较

     

    MFC Object是高层的,Windows Object是低层的;

    MFC Object封装了Windows Object的大部分或全部功能,MFC Object的使用者不需要直接应用Windows Object的HANDLE(句柄)使用Win32 API,代替它的是引用相应的MFC Object的成员函数。

  3. 从创建上比较

     

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

    MFC中,使用这些MFC Object,一般分两步:

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

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

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

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

  4. 从转换上比较

     

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

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

  5. 从使用范围上比较

     

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

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

  6. 从销毁上比较

     

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

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

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

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

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

描述

Windows句柄

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类和文件句柄描述。

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

    1. Windows Object

       

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

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

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

      1. Windows的注册

         

一个应用程序在创建某个类型的窗口前,必须首先注册该“窗口类”(Windows Class)。注意,这里不是C++类的类。Register Window把窗口过程、窗口类型以及其他类型信息和要登记的窗口类关联起来。

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

     

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

    typedef struct _WNDCLASSEX {

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

    UINT style; //窗口类的风格

    WNDPROC lpfnWndProc; //窗口过程

    int cbClsExtra;

    int cbWndExtra;

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

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

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

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

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

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

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

    } WNDCLASSEX;

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

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

  2. 调用AfxRegisterClass注册

     

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

    BOOL AFXAPI AfxRegisterClass(WNDCLASS *lpWndClass);

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

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

    接着,调用::RegisterClass(lpWndClass)注册窗口类;

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

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

  3. 调用AfxRegisterWndClass注册

     

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

    LPCTSTR AFXAPI AfxRegisterWndClass(UINT nClassStyle,

    HCURSOR hCursor, HBRUSH hbrBackground, HICON hIcon)

    参数1指定窗口类风格;

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

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

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

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

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

    否则,由六部分组成:

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

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

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

     

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

    用于子窗口的“AfxWnd”;

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

    用于MDI主窗口的“AfxMDIFrame”;

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

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

    MFC内部使用了函数

    BOOL AFXAPI AfxEndDeferRegisterClass(short fClass)

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

    AfxDeferRegisterClass(short fClass)

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

    注册这些窗口类的例子:

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

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

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

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

  5. 调用::RegisterWndClass。

     

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

  6. 子类化

     

子类化(Subclass)一个“窗口类”,可自动地得到它的“窗口类”属性。

      1. MFC窗口类CWnd

         

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

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

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

(1)窗口创建函数

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

BOOL CWnd::Create(LPCTSTR lpszClassName,

LPCTSTR lpszWindowName, DWORD dwStyle,

const RECT& rect,

CWnd* pParentWnd, UINT nID,

CCreateContext* pContext)

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

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

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

LPCTSTR lpszWindowName, DWORD dwStyle,

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

HWND hWndParent, HMENU nIDorHMenu, LPVOID lpParam)

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

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

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

(2)窗口销毁函数

例如:

DestroyWindow函数 销毁窗口

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

(3)用于设定、获取、改变窗口属性的函数,例如:

SetWindowText(CString tiltle) 设置窗口标题

GetWindowText() 得到窗口标题

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

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

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

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

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

GetMenu();得到窗口菜单

(4)用于完成窗口动作的函数

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

  • 有关消息发送的函数:

     

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

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

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

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

  • 有关改变窗口状态的函数

     

MoveWindow( LPCRECT lpRect, BOOL bRepaint = TRUE );

移动窗口到指定位置

ShowWindow(BOOL );显示窗口,使之可见或不可见

….

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

     

virtual LRESULT WindowProc( UINT message, WPARAM wParam, LPARAM lParam ); 窗口过程,虚拟函数

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

  • 消息处理函数:

     

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

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

  • 其他功能的函数

     

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

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

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

         

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

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

     

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

     

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

CToolBar m_wndToolBar;

CStatusBar m_wndStatusBar;

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

CMainFrame还有一个成员函数

OnCreate(LPCREATESTRUCT lpCreateStruct),

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

int CMainFrame::OnCreate(LPCREATESTRUCT lpCreateStruct)

{

if (!m_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开发文档。

      1. MFC窗口的使用

         

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

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

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

        框架类CFrameWnd,CMdiFrameWnd;

        文档框架CMdiChildWnd;

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

        对话框CDialog。

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

        工具条CToolBar

        状态条CStatusBar

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

        通常,直接使用这些类。

      2. 在MFC下窗口的销毁

         

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

(1)对CFrameWnd和CView的派生类

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

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

(2)对Windows Control窗口

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

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

(3)对于程序员直接从CWnd派生的窗口

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

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

    1. 设备描述表

       

      1. 设备描述表概述

         

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

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

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

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

属性

缺省值

Background 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)

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改变映射模式。

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

         

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

  1. CDC类

     

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

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

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

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

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

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

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

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

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

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

    至于调色板,使用SelectPalette(CPalette *pPalette,BOOL bForceBackground )选入调色板到设备描述表,使用RealizePalletter()实现逻辑调色板到物理调色板的映射。

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

     

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

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

  • CCientDC

     

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

  • CPaintDC

     

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

  • CMetaFileDC

     

用于生成元文件。

  • CWindowDC

     

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

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

         

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

     

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

    例如,MFC中CView对WM_PAINT消息的实现方法如下:

    void CView::OnPaint()

    {

    // standard paint routine

    CPaintDC dc(this);

    OnPrepareDC(&dc);

    OnDraw(&dc);

    }

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

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

    CPaintDC *pDC;

    pDC = new CPaintDC(this)

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

    delete pDC;

  2. 直接使用CDC

     

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

CDC::CDC()

{

m_hDC = NULL;

m_hAttribDC = NULL;

m_bPrinting = FALSE;

}

其析构函数如下:

CDC::~CDC()

{

if (m_hDC != NULL)

::DeleteDC(Detach());

}

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

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

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

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

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

…//作一些绘制操作

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

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

    1. GDI对象

       

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

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

Create or get a GDI OBJECT hNewGdi;

hOldGdi = ::SelectObject(hdc, hNewGdi)

……

::SelectObject(hdc, hOldGdi)

::DeleteObject(hNewGdi)

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

需要指出的是,如果hNewGdi是一个Stock GDI对象,可以不删除(删除也可以)。通过

HGDIOBJ GetStockObject(

int fnObject // type of stock object

);

来获取Stock GDI对象。

  1. MFC GDI对象

     

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

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

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

  2. 使用MFC GDI类的使用

     

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

void CMyView::OnDraw(CDC *pDC)

{

CPen penBlack; //构造MFC CPen对象

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

 

 


 

 

  1. CObject类

     

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

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

    1. CObject的结构

       

      以下是CObject类的定义:

      class CObject

      {

      public:

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

      virtual CRuntimeClass* GetRuntimeClass() const;

      析构函数

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

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

      void* PASCAL operator new(size_t nSize);

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

      void PASCAL operator delete(void* p);

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

      void* PASCAL operator new(size_t nSize, LPCSTR lpszFileName, int nLine);

      #endif

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

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

      protected:

      //缺省构造函数

      CObject();

      private:

      //复制构造函数,私有

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

      //赋值构造函数,私有

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

      // Attributes

      public:

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

      BOOL IsSerializable() const;

      BOOL IsKindOf(const CRuntimeClass* pClass) const;

      // Overridables

      virtual void Serialize(CArchive& ar);

      // 诊断函数

      virtual void AssertValid() const;

      virtual void Dump(CDumpContext& dc) const;

      // Implementation

      public:

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

      static const AFX_DATA CRuntimeClass classCObject;

      #ifdef _AFXDLL

      static CRuntimeClass* PASCAL _GetBaseClass();

      #endif

      };

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

      CRuntimeClass classCObject

      还定义了几组函数:

      构造函数析构函数类,

      诊断函数,

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

      与串行化相关的函数。

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

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

    2. CObject类的特性

       

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

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

     

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

从CObject派生的类要具有这样的特性,需要:

  • 定义该类时,在类说明中使用DECLARE_DYNAMIC(CLASSNMAE)宏;

     

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

     

  1. 对动态创建的支持

     

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

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

  • 定义该类时,在类说明中使用DECLARE_DYNCREATE(CLASSNMAE)宏;

     

  • 定义一个不带参数的构造函数(默认构造函数);

     

  • 在类的实现文件中使用IMPLEMENT_DYNCREATE(CLASSNAME,BASECLASS)宏;

     

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

     

例如:

CRuntimeClass* pRuntimeClass = RUNTIME_CLASS(CNname)

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

CObject* pObject = pRuntimeClass->CreateObject();

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

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

  1. 对序列化的支持

     

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

  • 定义该类时,在类说明中使用DECLARE_SERIAL(CLASSNMAE)宏;

     

  • 定义一个不带参数的构造函数(默认构造函数);

     

  • 在类的实现文件中使用IMPLEMENT_SERIAL(CLASSNAME,BASECLASS)宏;

     

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

     

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

  1. 综合示例:

     

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

class CPerson : public CObject

{

public:

DECLARE_SERIAL( CPerson )

// 缺省构造函数

CPerson(){}{};

CString m_name;

WORD m_number;

void Serialize( CArchive& archive );

// rest of class declaration

};

实现该类的成员函数Serialize,覆盖CObject的该函数:

void CPerson::Serialize( CArchive& archive )

{

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

CObject::Serialize( archive );

// now do the stuff for our specific class

if( 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));

    1. 实现CObject特性的机制

       

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

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

      1. DECLARE_DYNAMIC等宏的定义

         

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

MFC对这些宏的定义如下:

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

#define DECLARE_DYNAMIC(class_name) \

protected: \

static CRuntimeClass* PASCAL _GetBaseClass(); \

public: \

static const AFX_DATA CRuntimeClass class##class_name; \

virtual CRuntimeClass* GetRuntimeClass() const; \

#define _DECLARE_DYNAMIC(class_name) \

protected: \

static CRuntimeClass* PASCAL _GetBaseClass(); \

public: \

static AFX_DATA CRuntimeClass class##class_name; \

virtual CRuntimeClass* GetRuntimeClass() const; \

#else

#define DECLARE_DYNAMIC(class_name) \

public: \

static const AFX_DATA CRuntimeClass class##class_name; \

virtual CRuntimeClass* GetRuntimeClass() const; \

#define _DECLARE_DYNAMIC(class_name) \

public: \

static AFX_DATA CRuntimeClass class##class_name; \

virtual CRuntimeClass* GetRuntimeClass() const; \

#endif

// not serializable, but dynamically constructable

#define DECLARE_DYNCREATE(class_name) \

DECLARE_DYNAMIC(class_name) \

static CObject* PASCAL CreateObject();

#define DECLARE_SERIAL(class_name) \

_DECLARE_DYNCREATE(class_name) \

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

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

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

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

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

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

其次,它实现了DECLARE宏声明的成员函数:

  • _GetBaseClass()

     

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

  • GetRuntimeClass()

     

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

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

  • 操作符的重载

     

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

static const AFX_CLASSINIT _init_##class_name(RUNTIME_CLASS(class_name));

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

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

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

{

pOb = (class_name*) ar.ReadObject(

RUNTIME_CLASS(class_name));

return ar;

}

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

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

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

      1. CruntimeClass类的结构与功能

         

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

  1. CRuntimeClass的结构

     

    CruntimeClass的结构如下:

    Struct CRuntimeClass

    {

    LPCSTR m_lpszClassName;//类的名字

    int m_nObjectSize;//类的大小

    UINT m_wSchema;

    CObject* (PASCAL* m_pfnCreateObject)();

    //pointer to function, equal to 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成员函数的实现。

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

     

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

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

    CRuntimeClass成员变量

    动态类信息

    动态创建

    序列化

    m_lpszClassName

    类名字符串

    类名字符串

    类名字符串

    m_nObjectSize

    类的大小(字节数)

    类的大小(字节数)

    类的大小(字节数)

    m_wShema

    0xFFFF

    0xFFFF

    1、2等,非0

    m_pfnCreateObject

    NULL

    类的成员函数

    CreateObject

    类的成员函数

    CreateObject

    m_pBaseClass

    基类的CRuntimeClass变量

    基类的CRuntimeClass变量

    基类的CRuntimeClass变量

    m_pfnGetBaseClass

    类的成员函数

    _GetBaseClass

    类的成员函数

    _GetBaseClass

    类的成员函数

    _GetBaseClass

    m_pNextClass

    NULL

    NULL

    NULL

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

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

    { "CObject", sizeof(CObject), 0xffff, NULL, &CObject::_GetBaseClass, NULL };

    对初始化内容解释如下:

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

  3. 成员函数CreateObject

     

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

    CObject* CRuntimeClass::CreateObject()

    {

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

    {

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

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

    m_lpszClassName);

    return NULL;

    }

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

    CObject* pObject = NULL;

    TRY

    {

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

    }

    END_TRY

    return pObject;

    }

  4. 成员函数IsDerivedFrom

     

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

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

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

    程序如下所示:

    BOOL CRuntimeClass::IsDerivedFrom(

    const CRuntimeClass* pBaseClass) const

    {

    ASSERT(this != NULL);

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

    ASSERT(pBaseClass != NULL);

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

    // simple SI case

    const CRuntimeClass* pClassThis = this;

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

    {

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

    return TRUE;

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

    #ifdef _AFXDLL

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

    #else

    pClassThis = pClassThis->m_pBaseClass;

    #endif

    }

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

    }

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

  5. RUNTIME_CLASS宏

     

RUNTIME_CLASS宏定义如下:

#define RUNTIME_CLASS(class_name) (&class_name::class##class_name)

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

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

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

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

         

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

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

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

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

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

     

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

     

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

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

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

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

      1. 序列化的机制

         

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

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

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

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

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

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

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

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

在解释实现序列化的方法时,曾经提到如果程序员直接调用Serilize函数完成序列化,而不借助CArchive的>>和<<操作,则可以不需要动态类信息和动态创建。从上文的论述可以看出,没有CArchive的>>和<<操作,的确不需要动态类信息和动态创建特性。

 

 


 

 

  1. 消息映射的实现

     

    1. Windows消息概述

       

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

      1. 消息的分类

         

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

     

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

    这里,对消息队列阐述如下:

    Windows维护一个系统消息队列(System message queue),每个GUI线程有一个线程消息队列(Thread message queue)。

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

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

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

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

     

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

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

      1. 消息结构和消息处理

         

  1. 消息的结构

     

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

    MSG结构的定义如下:

    typedef struct tagMSG { // msg

    HWND hwnd;

    UINT message;

    WPARAM wParam;

    LPARAM lParam;

    DWORD time;

    POINT pt;

    } MSG;

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

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

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

     

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

    LRESULT CALLBACK MainWndProc (

    HWND hwnd,// 窗口句柄

    UINT msg,// 消息标识

    WPARAM wParam,//消息参数1

    LPARAM lParam//消息参数2

    )

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

    a window handle(窗口句柄);

    a message identifier(消息标识);

    two 32-bit values called message parameters(两个32位的消息参数);

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

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

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

     

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

    消息循环的结构如下:

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

    if (hwndDlgModeless == (HWND) NULL ||

    !IsDialogMessage(hwndDlgModeless, &msg) &&

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

    TranslateMessage(&msg);

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

    }

    }

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

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

  4. MFC消息处理

     

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

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

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

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

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

       

      1. MFC处理的三类消息

         

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

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

     

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

     

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

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

     

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

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

         

        MFC使用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。

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

      2. 在声明与实现的内部

         

  1. 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的情形。

  2. 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相对简单,就只有一种定义。

  3. ON_COMMAND宏

     

最后,看ON_COMMAND宏的内容:

#define ON_COMMAND(id, memberFxn) \

{\

WM_COMMAND,\

CN_COMMAND,\

(WORD)id,\

(WORD)id,\

AfxSig_vv,\

(AFX_PMSG)memberFxn\

};

        1. 消息映射声明的解释

           

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

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

  1. 成员变量

     

有两个成员变量被添加,第一个是_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时,是基类消息映射数组的地址)。

  1. 成员函数

     

  • _GetBaseMessageMap()

     

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

  • GetMessageMap()

     

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

        1. 消息映射实现的解释

           

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

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

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

     

    如前所述,消息映射数组的元素是消息映射条目,条目的格式符合结构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的内容,它标识消息处理类的消息映射条目的终止。

  2. 对messageMap的初始化

     

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

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

  3. 对函数的实现

     

_GetBaseMessageMap()

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

GetMessageMap():

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

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

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

      1. 消息映射宏的种类

         

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

  1. 用于Windows消息的宏,前缀为“ON_WM_”。

     

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

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

  2. 用于命令消息的宏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节先对其作一个大略的介绍。

    1. CcmdTarget类

       

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

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

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

  1. 静态成员函数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章节命令消息的处理中作更详细的描述。

  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节将作进一步的讨论。

    1. 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将在讨论对话框等的实现时具体分析。

        1. 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,只有相等才调用对应的消息处理函数。

        2. 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来处理。

        3. 消息映射机制完成虚拟函数功能的原理

           

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

  • 所有处理消息的类从CCmdTarget派生。

     

  • 使用静态成员变量_messageEntries数组存放消息映射条目,使用静态成员变量messageMap来唯一地区别和得到类的消息映射。

     

  • 通过GetMessage虚拟函数来获取当前对象的类的messageMap变量,进而得到消息映射入口。

     

  • 按照先底层,后基层的顺序在类的消息映射数组中搜索消息处理函数。基于这样的机制,一般在覆盖基类的消息处理函数时,应该调用基类的同名函数。

     

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

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

      1. 对命令消息的接收和处理

         

        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的标准命令发送路径:

  1. 送给活动(Active)视处理,调用活动视的OnCmdMsg。由于当前对象是MFC视对象,所以,OnCmdMsg将搜索CTview及其基类的消息映射数组,试图得到相应的处理函数。

     

  2. 如果视对象自己不处理,则视得到和它关联的文档,调用关联文档的OnCmdMsg。由于当前对象是MFC视对象,所以,OnCmdMsg将搜索CTdoc及其基类的消息映射数组,试图得到相应的处理函数。

     

  3. 如果文档对象不处理,则它得到管理文档的文档模板对象,调用文档模板的OnCmdMsg。由于当前对象是MFC文档模板对象,所以,OnCmdMsg将搜索文档模板类及其基类的消息映射数组,试图得到相应的处理函数。

     

  4. 如果文档模板不处理,则把没有处理的信息逐级返回:文档模板告诉文档对象,文档对象告诉视对象,视对象告诉边框窗口对象。最后,边框窗口得知,视、文档、文档模板都没有处理消息。

     

  5. CFrameWnd的OnCmdMsg继续调用CWnd::OnCmdMsg(斜体表示有类属限制)来处理消息。由于CWnd没有覆盖OnCmdMsg,故实际上调用了函数CCmdTarget::OnCmdMsg。由于当前对象是MFC边框窗口对象,所以OnCmdMsg函数将搜索CMainFrame类及其所有基类的消息映射数组,试图得到相应的处理函数。CWnd没有实现OnCmdMsg却指定要执行其OnCmdMsg函数,可能是为了以后MFC给CWnd实现了OnCmdMsg之后其他代码不用改变。

     

    这一步是边框窗口自己尝试处理消息。

  6. 如果边框窗口对象不处理,则送给应用程序对象处理。调用CTApp的OnCmdMsg,由于实际上CTApp及其基类CWinApp没有覆盖OnCmdMsg,故实际上调用了函数CCmdTarget::OnCmdMsg。由于当前对象是MFC应用程序对象,所以OnCmdMsg函数将搜索CTApp类及其所有基类的的消息映射入口数组,试图得到相应的处理函数

     

  7. 如果应用程序对象不处理,则返回FALSE,表明没有命令目标处理当前的命令消息。这样,函数逐级别返回,OnCmdMsg告诉OnCommand消息没有被处理,OnCommand告诉OnWndMsg消息没有被处理,OnWndMsg告诉WindowProc消息没有被处理,于是WindowProc调用DefWindowProc进行缺省处理。

     

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

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

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

           

  1. 命令消息的派发

     

    如前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消息的处理是一样的。

  2. 消息的多次处理

     

如果消息处理函数不返回值,则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节。

        1. 一些消息处理类的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)

  1. 调用CWnd::OnCmdMsg,让对话框或其基类处理消息。

     

  2. 如果还没有处理,而且是控制消息或系统命令或非命令按钮,则返回FALSE,不作进一步处理。否则,调用父窗口的OnCmdmsg(GetParent()->OnCmdmsg)把消息送给父窗口处理。

     

  3. 如果仍然没有处理,则调用当前线程的OnCmdMsg(GetThread()->OnCmdMsg)把消息送给线程对象处理。

     

  4. 如果最后没有处理,返回FALSE。

     

  • CMDIFrameWnd的OnCmdMsg

     

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

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

AFX_CMDHANDLERINFO* pHandlerInfo)

  1. 如果有激活的文档边框窗口,则调用它的OnCmdMsg(MDIGetActive()->OnCmdMsg)把消息交给它进行处理。MFC的文档边框窗口类并没有覆盖OnCmdMsg函数,所以基类CFrameWnd的函数被调用,导致文档边框窗口的活动视、文档边框窗口本身、应用程序对象依次来进行消息处理。

     

  2. 如果文档边框窗口没有处理,调用CFrameWnd::OnCmdMsg把消息按标准路径发送,重复第一次的步骤,不过对于MDI边框窗口来说不存在活动视,所以省却了让视处理消息的必要;接着让MDI边框窗口本身来处理消息,如果它还没有处理,则让应用程序对象进行消息处理──虽然这是一个无用的重复。

     

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

        1. 一些消息处理类的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函数。

  1. 对于MDI消息,如果主边框窗口还不处理的话,交给CMDIFrameWnd的DefWindowProc作缺省处理。

     

  2. 消息没有处理,返回FALSE。

     

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

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

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

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

         

        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让父窗口对象来处理通知消息。

     

        1. 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消息的处理过程如下:

  1. 反射消息给控制子窗口处理。

     

  2. 如果子窗口不处理反射消息,则交给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. 消息反射

           

(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控制。

      1. 对更新命令的接收和处理

         

        用户接口对象如菜单、工具条有多种状态,例如:禁止,可用,选中,未选中,等等。这些状态随着运行条件的变化,由程序来进行更新。虽然程序员可以自己来完成更新,但是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派生,没有基类。

  1. 成员变量

     

    m_nID 用户接口对象的ID

    m_nIndex 用户接口对象的index

    m_pMenu 指向CCmdUI对象表示的菜单

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

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

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

  2. 成员函数

     

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

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

           

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

  1. 更新菜单状态

     

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

    在应用程序开始运行时,边框也会收到WM_INITMENUPOPUP消息。

  2. 更新工具条等状态

     

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

    在窗口初始化时,工具条也会收到WM_IDLEUPDATECMDUI消息。

  3. 菜单状态更新的实现

     

    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. 工具条等状态更新的实现

     

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

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

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

 

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

    1. 消息的预处理

       

      到现在为止,详细的讨论了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函数,直到消息被处理或者到最顶层窗口为止。

    2. MFC消息映射的回顾

       

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

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

  1. 消息映射入口表的实现:采用了C++静态成员和虚拟函数的方法来表示和得到一个消息映射类(CCmdTarget或派生类)的映射表。

     

  2. 消息查找的实现:从低层到高层搜索消息映射入口表,直至根类CCmdTarget。

     

  3. 消息发送的实现:主要以几个虚拟函数为基础来实现标准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提供了那些接口来支持其编程模式?

  1. MFC对象的关系

     

    1. 创建关系

       

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

       

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

      创建者

      被创建的对象

      应用程序对象

      文档模板

      文档模板

      文档

      文档模板

      边框窗口

      边框窗口

       

    2. 交互作用关系

       

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

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

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

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

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

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

    本对象

    要得到的对象

    使用的成员函数

    CDocument对象

    视列表

    GetFirstViewPosition

    GetNextView

    文档模板

    GetDocTemplate

    CView对象

    文档对象

    GetDocument

    边框窗口

    GetParentFrame

    CMDIChildWnd或

    CFrameWnd对象

    活动视

    GetActiveView

    活动视的文档

    GetActiveDocument

    CMDIFrameWnd对象

    活动文档边框窗口

    MDIGetActive

     

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

    本对象

    要通知的对象/动作

    使用的成员函数

    CView对象

    通知文档更新所有视

    CDocument::UpdateAllViews

    CDocument对象

    更新一个视

    CView::OnUpdate

    CFrameWnd或

    CMDIFrameWnd对象

    通知一个视为活动视

    CView::OnActivateView

    设置一个视为活动视

    SetActivateView

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

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

  2. MFC提供的接口

     

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

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

    1. 虚拟函数接口

       

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

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

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

      虚拟函数

      覆盖的目的和功能

      CCmdTarget

      OnCmdMsg

      发送、派发命令消息

      OnFinalRelease

      OLE用途,引用为0时作清理工作

      CWinThread

      ExitInstance

      在线程退出时作清理工作

      InitInstance

      在线程开始时作初始化

      OnIdle

      执行thread-specific idle-time处理

      PreTranslateMessage

      在消息送给Windows函数TranslateMessage and DispatchMessage.之前进行消息过滤

      IsIdleMessage

      检查是否是某个特别的消息

      ProcessWndProcException

      截获线程消息/命令处理中的例外

      ProcessMessageFilter

      线程消息过滤

      Run

      实现线程特定的消息循环

      CWinApp

      HideApplication

      关闭所有的窗口之前隐藏应用程序

      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

      在框架窗口关闭之前调用

       

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

       

    窗口对象可以响应以“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

     

  3. MFC对象的创建过程

     

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

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

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

       

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

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

      1. 应用程序类的成员变量

         

        应用程序对象的数据成员表由两部分组成,第一部分是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初始化设置时使用

      2. 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创建

      3. 文档模板的属性

         

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

    2. 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处理的一个应用是更新用户接口对象的状态。更新用户接口状态的内容见消息映射的章节。

    1. 空闲处理由函数OnIdle完成,其原型为BOOL OnIdle(int)。参数的含义是当前空闲处理周期已经完成了多少次OnIdle调用,每个空闲处理周期的第一次调用,该参数设为0,每调用一次加1;返回值表示当前空闲处理周期是否继续调用OnIdle。

       

    2. MFC的缺省实现里,CWinThread::OnIdle完成了工具栏等的状态更新。如果覆盖OnIdle,需要调用基类的实现。

       

    3. 在处理完一个消息或进入消息循环时,如果消息队列中没有消息要处理,则MFC开始一个新的空闲处理周期;

       

    4. 当OnIdle返回FASLE,或者消息队列中有消息要处理时,当前的空闲处理周期结束。

       

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

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

        1. 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对象的动态创建过程是在创建或者打开文件中发生的。但是为什么没有看到文件操作相关的语句呢?

    1. 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。

    2. 处理命令行命令

       

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

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

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

    3. OnFileNew

       

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

      图5-5的说明:

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

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

    4. OnFileOpen

       

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

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

    5. 应用程序对象的OpenDocumentFile

       

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

       

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

    6. 文档模板的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对象的关系。

    7. 打开文件过程中所涉及的消息处理函数和虚拟函数

       

    图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开始,这些将在下一节论述。

          1. SDI边框窗口的创建

             

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

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

    1. 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将创建视对象和视窗口。

    2. 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的边框窗口已经被创建。下一节将描述视的创建。

          1. 视的创建

             

            第四步,创建视。

            如前一节所述,若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所示。

          2. 窗口初始化

             

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

            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轴上的顶层。

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

          3. 视的初始化

             

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

            如图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章。

          4. 激活边框窗口(处理WM_ACTIVE)

             

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

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

    1. 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消息。

    2. WM_ACTIVATETOPLEVEL消息的处理

       

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

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

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

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

    3. 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)。

          1. SDI流程的回顾

             

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

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

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

        1. 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可以去掉这部分代码,因为它的主窗口的创建、显示等由第二、四部分的语句来处理。

       

          1. 有别于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子窗口的创建。

          2. 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结构的指针。

    1. 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来进行初始化。

          1. 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窗口

     

     


     

     

    1. 应用程序的退出

       

      一个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. 窗口的销毁过程

         

        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。

    1. CWnd::OnDestroy()

       

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

    2. CFrameWnd::OnDestroy()

       

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

    3. CMDIFrameWnd::OnDestroy()

       

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

    4. CView::OnDestroy()

       

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

        1. 处理WM_NCDESTROY消息

           

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

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

    1. CWnd::OnNcDestroy()

       

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

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

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

      最后,调用虚拟函数PostNcDestoy。

    2. PostNcDestoy

       

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

    • CWnd::PostNcDestroy()

       

    MFC缺省实现空

    • void CFrameWnd::PostNcDestroy()

       

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

    • void CView::PostNcDestroy()

       

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

    1. 析构函数

       

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

    • CFrameWnd::~CFrameWnd()

       

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

    必要的话,删除m_phWndDisable数组。

    • CView::~CView()

       

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

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

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

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

         

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

    1. SDI窗口的关闭

       

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

    2. MDI主窗口的关闭

       

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

    3. MDI子窗口(文档边框窗口)的关闭

       

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


     

     

    1. MFC的DLL

       

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

      1. DLL的背景知识

         

    1. 静态链接和动态链接

       

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

    • 静态链接

       

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

    • 动态链接

       

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

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

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

    1. 动态链接的方法

       

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

    • 加载时动态链接(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模块从当前进程的虚拟空间移走。

    1. 输入库(.lib):

       

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

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

    2. 输出文件(.exp)

       

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

    3. 映像文件(.map)

       

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

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

    4. lib.exe工具

       

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

      更详细的信息可以参见MFC使用手册和文档。

    5. 链接规范(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++环境下可以使用。

    6. 修饰名(Decoration name)

       

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

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

      1. 调用约定

         

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

    1. _cdecl

       

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

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

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

    2. _stdcall

       

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

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

    3. _fastcall

       

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

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

    4. thiscall

       

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

    5. naked call

       

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

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

      __declspec( naked ) int func( formal_parameters )

      {

      // Function body

      }

    6. 过时的调用约定

       

    原来的一些调用约定可以不再使用。它们被定义成调用约定_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

     

        1. MFC的DLL应用程序的类型

           

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

       

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

      extern "C" EXPORT YourExportedFunction( );

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

      DLL应用程序从CWinApp派生,但没有消息循环。

    2. 动态链接到MFC的规则DLL应用程序

       

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

      AFX_MANAGE_STATE(AfxGetStaticModuleState( ))

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

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

    3. 扩展DLL应用程序

       

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

    1. 它没有一个从CWinApp派生的对象;

       

    2. 它必须有一个DllMain函数;

       

    3. DllMain调用AfxInitExtensionModule函数,必须检查该函数的返回值,如果返回0,DllMmain也返回0;

       

    4. 如果它希望输出CRuntimeClass类型的对象或者资源(Resources),则需要提供一个初始化函数来创建一个CDynLinkLibrary对象。并且,有必要把初始化函数输出。

       

    5. 使用扩展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的上述特点。

      1. DLL的几点说明

         

    1. 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。

    2. _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应用程序的。在讲述状态管理时解释其原因。

    3. DLL的函数和数据

       

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

      虽然DLL可以输出数据,但一般的DLL程序的数据仅供内部使用。

    4. DLL程序和调用其输出函数的程序的关系

       

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

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

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

    DLL使用调用进程的栈。

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

      1. 输出函数的方法

         

    1. 传统的方法

       

      在模块定义文件的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模块定义文件。

    2. 在命令行输出

       

      对链接程序LINK指定/EXPORT命令行参数,输出有关函数。

    3. 使用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”代码里调用。


     

     

    1. MFC的进程和线程

       

      1. Win32的进程和线程概念

         

    进程是一个可执行的程序,由私有虚拟地址空间、代码、数据和其他操作系统资源(如进程创建的文件、管道、同步对象等)组成。一个应用程序可以有一个或多个进程,一个进程可以有一个或多个线程,其中一个是主线程。

    线程是操作系统分时调度分配CPU时间的基本实体。一个线程可以执行程序的任意部分的代码,即使这部分代码被另一个线程并发地执行;一个进程的所有线程共享它的虚拟地址空间、全局变量和操作系统资源。

    之所以有线程这个概念,是因为以线程而不是进程为调度对象效率更高:

    • 由于创建新进程必须加载代码,而线程要执行的代码已经被映射到进程的地址空间,所以创建、执行线程的速度比进程更快。

       

    • 一个进程的所有线程共享进程的地址空间和全局变量,所以简化了线程之间的通讯。

       

      1. 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。

       

      1. 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级以外的任意线程抢占。

        1. 线程的终止

           

    以下情况终止一个线程:

    • 调用了ExitThread函数;

       

    • 线程函数返回:主线程返回导致ExitProcess被调用,其他线程返回导致ExitThread被调用;

       

    • 调用ExitProcess导致进程的所有线程终止;

       

    • 调用TerminateThread终止一个线程;

       

    • 调用TerminateProcess终止一个进程时,导致其所有线程的终止。

       

    当用TerminateProcess或者TerminateThread终止进程或线程时,DLL的入口函数DllMain不会被执行(如果有DLL的话)。

        1. 线程局部存储

           

    如果希望每个线程都可以有线程局部(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释放索引。

      1. 线程同步

         

        同步可以保证在一个时间内只有一个线程对某个资源(如操作系统资源等共享资源)有控制权。共享资源包括全局变量、公共数据成员或者句柄等。同步还可以使得有关联交互作用的代码按一定的顺序执行。

        Win32提供了一组对象用来实现多线程的同步。

        这些对象有两种状态:获得信号(Signaled)或者没有或则信号(Not signaled)。线程通过Win32 API提供的同步等待函数(Wait functions)来使用同步对象。一个同步对象在同步等待函数调用时被指定,调用同步函数地线程被阻塞(blocked),直到同步对象获得信号。被阻塞的线程不占用CPU时间。

        1. 同步对象

           

    同步对象有:Critical_section(关键段),Event(事件),Mutex(互斥对象),Semaphores(信号量)。

    下面,解释怎么使用这些同步对象。

    1. 关键段对象:

       

      首先,定义一个关键段对象cs:

      CRITICAL_SECTION cs;

      然后,初始化该对象。初始化时把对象设置为NOT_SINGALED,表示允许线程使用资源:

      InitializeCriticalSection(&cs);

      如果一段程序代码需要对某个资源进行同步保护,则这是一段关键段代码。在进入该关键段代码前调用EnterCriticalSection函数,这样,其他线程都不能执行该段代码,若它们试图执行就会被阻塞。

      完成关键段的执行之后,调用LeaveCriticalSection函数,其他的线程就可以继续执行该段代码。如果该函数不被调用,则其他线程将无限期的等待。

    2. 事件对象

       

      首先,调用CreateEvent函数创建一个事件对象,该函数返回一个事件句柄。然后,可以设置(SetEvent)或者复位(ResetEvent)一个事件对象,也可以发一个事件脉冲(PlusEvent),即设置一个事件对象,然后复位它。复位有两种形式:自动复位和人工复位。在创建事件对象时指定复位形式。。

      自动复位:当对象获得信号后,就释放下一个可用线程(优先级别最高的线程;如果优先级别相同,则等待队列中的第一个线程被释放)。

      人工复位:当对象获得信号后,就释放所有可利用线程。

      最后,使用CloseHandle销毁创建的事件对象。

    3. 互斥对象

       

      首先,调用CreateMutex创建互斥对象;然后,调用等待函数,可以的话利用关键资源;最后,调用RealseMutex释放互斥对象。

      互斥对象可以在进程间使用,但关键段对象只能用于同一进程的线程之间。

    4. 信号量对象

       

      在Win32中,信号量的数值变为0时给以信号。在有多个资源需要管理时可以使用信号量对象。

      首先,调用CreateSemaphore创建一个信号量;然后,调用等待函数,如果允许的话,则利用关键资源;最后,调用RealeaseSemaphore释放信号量对象。

    5. 此外,还有其他句柄可以用来同步线程:

       

    文件句柄(FILE HANDLES)

    命名管道句柄(NAMED PIPE HANDELS)

    控制台输入缓冲区句柄(CONSOLE INPUT BUFFER HANDLES)

    通讯设备句柄(COMMUNICTION DEVICE HANDLES)

    进程句柄(PROCESS HANDLES)

    线程句柄(THREAD HANDLES)

    例如,当一个进程或线程结束时,进程或线程句柄获得信号,等待该进程或者线程结束的线程被释放。

        1. 等待函数

           

    Win32提供了一组等待函数用来让一个线程阻塞自己的执行。等待函数分三类:

    1. 等待单个对象的(FOR SINGLE OBJECT):

       

      这类函数包括:

      SignalObjectAndWait

      WaitForSingleObject

      WaitForSingleObjectEx

      函数参数包括同步对象的句柄和等待时间等。

      在以下情况下等待函数返回:

      同步对象获得信号时返回;

      等待时间达到了返回:如果等待时间不限制(Infinite),则只有同步对象获得信号才返回;如果等待时间为0,则在测试了同步对象的状态之后马上返回。

    2. 等待多个对象的(FOR MULTIPLE OBJECTS)

       

      这类函数包括:

      WaitForMultipleObjects

      WaitForMultipleObjectsEx

      MsgWaitForMultipleObjects

      MsgWaitForMultipleObjectsEx

      函数参数包括同步对象的句柄,等待时间,是等待一个还是多个同步对象等等。

      在以下情况下等待函数返回:

      一个或全部同步对象获得信号时返回(在参数中指定是等待一个或多个同步对象);

      等待时间达到了返回:如果等待时间不限制(Infinite),则只有同步对象获得信号才返回;如果等待时间为0,则在测试了同步对象的状态之后马上返回。

    3. 可以发出提示的函数(ALTERABLE)

       

    这类函数包括:

    MsgWaitForMultipleObjectsEx

    SignalObjectAndWait

    WaitForMultipleObjectsEx

    WaitForSingleObjectEx

    这些函数主要用于重叠(Overlapped)的I/O(异步I/O)。

      1. 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开始执行线程。

       

        1. 创建工作者线程

           

          程序员不必从CWinThread派生新的线程类,只需要提供一个控制函数,由线程启动后执行该函数。

          然后,使用AfxBeginThread创建MFC线程对象和Win32线程对象。如果创建线程时没有指定CREATE_SUSPENDED(创建后挂起),则创建的新线程开始执行。

          如果创建线程是指定了CREATE_SUSPENDED,则在适当的地方调用函数ResumeThread开始执行线程。

          虽然程序员没有从CWinThread派生类,但是MFC给工作者线程提供了缺省的CWinThread对象。

        2. AfxBeginThread

           

    用户界面线程和工作者线程都是由AfxBeginThread创建的。现在,考察该函数:MFC提供了两个重载版的AfxBeginThread,一个用于用户界面线程,另一个用于工作者线程,分别有如下的原型和过程:

    1. 用户界面线程的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下有用。

    2. 工作者线程的AfxBeginThread

       

      工作者线程的AfxBeginThread的原型如下:

      CWinThread* AFXAPI AfxBeginThread(

      AFX_THREADPROC pfnThreadProc,

      LPVOID pParam,

      int nPriority,

      UINT nStackSize,

      DWORD dwCreateFlags,

      LPSECURITY_ATTRIBUTES lpSecurityAttrs)

      其中:

      参数1指定控制函数的地址;

      参数2指定传递给控制函数的参数;

      参数3、4、5分别指定线程的优先级、堆栈大小、创建标识、安全属性,含义同用户界面线程。

    3. AfxBeginThread创建线程的流程

       

    不论哪个AfxBeginThread,首先都是创建MFC线程对象,然后创建Win32线程对象。在创建MFC线程对象时,用户界面线程和工作者线程的创建分别调用了不同的构造函数。用户界面线程是从CWinThread派生的,所以,要先调用派生类的缺省构造函数,然后调用CWinThread的缺省构造函数。图8-1中两个构造函数所调用的CommonConstruct是MFC内部使用的成员函数。

        1. 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章。

           

           

        2. 线程的结束

           

          从图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线程对象是有用的,当然程序员自己最后要记得销毁该线程对象。

        3. 实现线程的消息循环

           

    在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中占有重要地位,涉及的内容比较多,所以专门在下一章来讲述它。


     

     

    1. 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线程私有数据指针,从该指针得到最终的线程私有数据。

        1. 线程状态_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记录了线程局部变量对象的槽号。

        2. 进程模块状态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模板对象。

        3. 状态对象的创建

           

          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槽中。

          1. 创建过程所涉及的几个重要函数的算法

             

    创建过程所涉及的几个重要函数的算法描述如下:

    1. AllocSlot

       

      AllocSlot用来分配线程的MFC私有存储空间的槽号。由于该函数要修改全局变量_afxThreadData,所以必须使用m_sect关键段对象来同步多个线程对该函数的调用。

      CThreadSlotData::AllocSlot()

      {

      进入关键段代码(EnterCriticalSection(m_sect);)

      搜索m_pSlotData,查找空槽(SLOT)

      如果不存在空槽(第一次进入时,肯定不存在)

      分配或再分配内存以创建新槽,

      指针m_pSlotData指向分配的地址。

      得到新槽(SLOT)

      标志该SLOT为已用

      记录最新可用的SLOT到成员变量m_nRover中。

      离开关键段代码(LeaveCriticalSection(m_sect);)

      返回槽号

      }

    2. GetThreadValue

       

      GetThreadValue用来获取调用线程的第slot个线程局部变量的值。每一个线程局部变量都占用一个且只一个槽位。

      CThreadSlotData::GetThreadValue(int slot)

      {

      //得到一个CThreadData型的指针pData

      //pData指向MFC线程私有存储空间。

      //m_tlsIndex在_afxThreadData创建时由构造函数创建

      pData=(CThreadData*)TlsGetValue(m_tlsIndex),。

      如果指针空或slot>pData->nCount, 则返回空。

      否则,返回pData

      }

    3. 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

    }

      1. 管理状态

         

        在描述了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节。

       

        1. 扩展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模块的输出函数或者输出类。

        2. 核心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的模块状态,见下一节的讨论。

        3. 动态链接的规则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是静态链接的,所以不必考虑状态切换。

      1. 状态信息的作用

         

        在分析了MFC模块状态的实现基础和管理机制之后,现在对状态信息的作用进行专门的讨论。

          1. 模块信息的保存和管理

             

          传统上,线程状态、模块状态等包含的信息是全局变量,但是为了支持Win32s、多线程、DLL等,这些变量必须是限于进程或者线程范围内有效,或者限于某个模块内有效。也就是,不再可能把它们作为全局变量处理。因此,MFC引入模块、线程、模块-线程状态等来保存和管理一些重要的信息。

          例如:一个模块注册了一个“窗口类”之后,应用程序要保存“窗口类”的名字,以便在模块退出时取消注册的“窗口类”。因此,模块状态使用成员变量m_szUnregisterList在注册成功之后保存的“窗口类”名字。窗口注册见2.2.1节。

          又如:Tooltip窗口是线程相关的,每个线程一个,所以线程状态用成员变量m_pToolTip来保存本线程的MFC Tooltip窗口对象。Tooltip窗口见13.2.4.4节。

          还有,MFC对象是线程和模块相关的,所以模块线程中有一组变量用来管理本线程的MFC对象到Windows对象的映射关系。关于MFC对象和Windows对象的映射,见稍后的讨论。

          模块状态、线程状态、模块线程状态的每个成员变量都有自己存在的必要和作用,这里就不一一论述了,在此,只是强调模块状态自动地实现对模块句柄和资源句柄等信息的保存和管理,这对MFC应用程序是非常重要的。

          SDK 下的应用程序或者DLL,通常使用一个全局变量来保存模块/资源句柄。有了模块状态之后,程序员就不必这么作了。规则DLL或者应用程序的模块和资源句柄在调用DllMain或WinMain时被保存到了当前模块的模块状态中。如果是扩展DLL,则其句柄被保存到扩展模块状态中,并通过CDynLinkLibrary对象链接到主模块的模块状态。

          图9-8示意了MFC模块状态对资源、CRuntimeClass对象、OLE工厂等模块信息的管理。

          图9-8的说明:

          左边的主模块状态表示动态链接到MFC DLL的应用程序或者规则DLL的模块状态,其资源句柄和模块句柄用来查找和获取资源,资源句柄一般是应用程序的模块句柄;CRuntimeClass对象列表和COleObjectFactory对象列表分别表示该模块初始化了的CRuntimeClass对象和该模块的OLE工厂对象;CDynLinkLibrary列表包含了它引用的系列扩展DLL的扩展模块状态(包括核心MFC DLL的状态),链表中的每一个CDynLinkLibrary对象对应一个扩展模块状态,代表了创建该对象的扩展DLL的有关资源、信息。

          MFC查找资源、CRuntimeClass类、OLE工厂时,首先查找模块状态,然后,遍历CDynLinkLibrary表搜索相应的对象。下面两节举例说明。

        1. MFC资源、运行类信息的查找

           

    MFC内部使用的资源查找函数是:

    HINSTANCE AfxFindResourceHandle(LPCTSTR lpszName, LPCTSTR lpszType):

    其中:

    参数1是要查找的资源名称,参数2是要查找的资源类型。

    返回包含指定资源的模块的句柄。

    上述函数的查找算法如下:

    1. 如果进程模块状态(主模块)不是系统模块,则使用::FindResource(下同)搜索它,成功则返回;

       

    2. 如果没有找到,则遍历CDynLinkLibrary对象列表,搜索所有的非系统模块,成功则返回;

       

    3. 如果没有找到,则检查主模块的语言资源,成功则返回;

       

    4. 如果没有找到,并且主模块是系统模块,则搜索它,成功则返回;

       

    5. 如果没有找到,则遍历CDynLinkLibrary对象列表,搜索所有的系统模块,成功则返回;

       

    6. 如果没有找到,则使用AfxGetResourceHanlde返回应用程序的资源。

       

    需要指出的是,遍历CDynLinkLibrary对象列表时,必须采取同步措施,防止其他线程改变链表。MFC是通过锁定全局变量CRIT_DYNLINKLIST来实现的,类似的全局变量MFC定义了多个。

    运行时类信息的查找算法类似。

    3.3.4节指出,对象进行“<<”序列化操作时,首先需要搜索到指定类的运行时信息,方法如下:

    CRuntimeClass* PASCAL CRuntimeClass::Load(

    CArchive& ar, UINT* pwSchemaNum)

    1. 遍历主模块的CRuntimeClass对象列表m_classList,搜索主模块是否实现了指定的CRuntimeClass类;

       

    2. 遍历CDynLinkLibrary对象列表m_libraryList;对每一个CDynLinkLibrary对象,遍历它的CRuntimeClass对象列表m_classList。这样,所有的扩展DLL模块的CRuntimeClass对象都会被搜索到。

       

        1. 模块信息的显示

           

          遍历模块状态和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函数的处理,只不过增加了模块名和模块句柄信息。

        2. 模块-线程状态的作用

           

          由模块-线程状态类的定义可知,一个模块-线程状态包含了几类Windows对象—MFC对象的映射。下面讨论它们的作用。

          1. 只能访问本线程MFC对象的原因

             

    MFC规定:

    1. 不能从一个非MFC线程创建和访问MFC对象

       

      如果一个线程被创建时没有用到CWinThread对象,比如,直接使用“C”的_beginthread或者_beginthreadex创建的线程,则该线程不能访问MFC对象;换句话说,只有通过CWinThread创建MFC线程对象和Win32线程,才可能在创建的线程中使用MFC对象。

    2. 一个线程仅仅能访问它所创建的MFC对象

       

    这两个规定的原因是:

    为了防止多个线程并发地访问同一个MFC对象,MFC对象和Windows对象之间有一个一一对应的关系,这种关系以映射的形式保存在创建线程的当前模块的模块-线程状态信息中。当一个线程使用某个MFC对象指针P时,ASSERT_VALID(P)将验证当前线程的当前模块是否有Windows句柄和P对应,即是否创建了P所指的Windows对象,验证失败导致ASSERT断言中断程序的执行。如果一个线程要使用其他线程的Windows对象,则必须传递Windows对象句柄,不能传递MFC对象指针。

    当然一般来说,MFC应用程序仅仅在Debug版本下才检查这种映射关系,所以访问其他线程的MFC对象的程序在Realease版本下表面上不会有问题,但是MFC对象被并发访问的后果是不可预见的。

          1. 实现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对象。

       

    • 映射分两类:永久性的或者临时的。

       

          1. 临时对象的处理

             

    在2.4节就曾经提到了临时对象,现在是深入了解它们的时候了。

    1. 临时对象指MFC对象,是MFC或者程序员使用FromHandle或者SelectObject等从一个Windows对象句柄创建的对应的MFC对象。

       

    2. 在模块-线程状态中,临时MFC对象的映射是和永久映射分开保存的。

       

    3. 临时MFC对象在使用完毕后由MFC框架自动删除,MFC在线程的Idle处理中删除本线程的临时MFC对象,为了防止并发修改,通过线程状态m_nTempMapLock(等于0,可以修改,大于0,等待)来同步。所以,临时MFC对象不能保存备用。

       

      1. 状态对象的删除和销毁

         

    至此,本章讨论了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. 内存分配方式和调试机制

       

      1. M内存分配

         

        1. 内存分配函数

           

    MFCWin32或者C语言的内存分配API,有四种内存分配API可供使用。

    1. Win32的堆分配函数

       

      每一个进程都可以使用堆分配函数创建一个私有的堆──调用进程地址空间的一个或者多个页面。DLL创建的私有堆必定在调用DLL的进程的地址空间内,只能被调用进程访问。

      HeapCreate用来创建堆;HeapAlloc用来从堆中分配一定数量的空间,HeapAlloc分配的内存是不能移动的;HeapSize可以确定从堆中分配的空间的大小;HeapFree用来释放从堆中分配的空间;HeapDestroy销毁创建的堆。

    2. Windows传统的全局或者局部内存分配函数

       

      由于Win32采用平面内存结构模式,Win32下的全局和局部内存函数除了名字不同外,其他完全相同。任一函数都可以用来分配任意大小的内存(仅仅受可用物理内存的限制)。用法可以和Win16下基本一样。

      Win32下保留这类函数保证了和Win16的兼容。

    3. C语言的标准内存分配函数

       

      C语言的标准内存分配函数包括以下函数:

      malloc,calloc,realloc,free,等。

      这些函数最后都映射成堆API函数,所以,malloc分配的内存是不能移动的。这些函数的调式版本为

      malloc_dbg,calloc_dbg,realloc_dbg,free_dbg,等。

    4. 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指定要解锁的内存的长度。

        1. C++的new 和 delete操作符

           

    MFC定义了两种作用范围的new和delete操作符。对于new,不论哪种,参数1类型必须是size_t,且返回void类型指针。

    1. 全局范围内的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)

    2. 类定义的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。

      1. 调试手段

         

        MFC应用程序可以使用C运行库的调试手段,也可以使用MFC提供的调试手段。两种调试手段分别论述如下。

        1. C运行库提供和支持的调试功能

           

    C运行库提供和支持的调试功能如下:

    1. 调试信息报告函数

       

      用来报告应用程序的调试版本运行时的警告和出错信息。包括:

      _CrtDbgReport 用来报告调试信息;

      _CrtSetReportMode 设置是否警告、出错或者断言信息;

      _CrtSetReportFile 设置是否把调试信息写入到一个文件。

    2. 条件验证或者断言宏:

       

      断言宏主要有:

      assert 检验某个条件是否满足,不满足终止程序执行。

      验证函数主要有:

      _CrtIsValidHeapPointer 验证某个指针是否在本地堆中;

      _CrtIsValidPointer 验证指定范围的内存是否可以读写;

      _CrtIsMemoryBlock 验证某个内存块是否在本地堆中。

    3. 内存(堆)调试:

       

    malloc_dbg 分配内存时保存有关内存分配的信息,如在什么文件、哪一行分配的内存等。有一系列用来提供内存诊断的函数:

    _CrtMemCheckpoint 保存内存快照在一个_CrtMemState结构中;

    _CrtMemDifference 比较两个_CrtMemState;

    _CrtMemDumpStatistics 转储输出一_CrtMemState结构的内容;

    _CrtMemDumpAllObjectsSince 输出上次快照或程序开始执行以来在堆中分配的所有对象的信息;

    _CrtDumpMemoryLeaks 检测程序执行以来的内存漏洞,如果有漏洞则输出所有分配的对象。

        1. MFC提供的调试手段

           

    MFC在C运行库提供和支持的调试功能基础上,设计了一些类、函数等来协助调试。

    1. 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。

    2. 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

    3. 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。

        1. 内存诊断

           

    MFC使用DEBUG_NEW来跟踪内存分配时的执行的源码文件和行数。

    把#define new DEBUG_NEW插入到每一个源文件中,这样,调试版本就使用_malloc_dbg来分配内存。MFC Appwizard在创建框架文件时已经作了这样的处理。

    1. AfxDoForAllObjects

       

      MFC提供了函数AfxDoForAllObjects来追踪动态分配的内存对象,函数原型如下:

      void AfxDoForAllObjects( void (*pfn)(CObject* pObject,

      void* pContext), void* pContext );

      其中:

      参数1是一个函数指针,AfxDoForAllObjects对每个对象调用该指针表示的函数。

      参数2将传递给参数1指定的函数。

      AfxDoForAllObjects可以检测到所有使用new分配的CObject对象或者CObject类派生的对象,但全局对象、嵌入对象和栈中分配的对象除外。

    2. 内存漏洞检测

       

    仅仅用于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在应用程序(调试版)结束时,自动进行内存漏洞检测,如果存在漏洞,则输出漏洞的有关信息。

     


     
    1. MFC下的文件类
      1. 文件操作的方法

    使用Visual C++编程,有如下方法进行文件操作:

    1)使用标准C运行库函数,包括fopenfclosefseek等。

    2)使用Win16下的文件和目录操作函数,如lopenlcloselseek等。不过,在Win32下,这些函数主要是为了和Win16向后兼容。

    3)使用Win32下的文件和目录操作函数,如CreateFileCopyFileDeleteFileFindNextFile,等等。

    Win32下,打开和创建文件都由CreateFile完成,成功的话,得到一个Win32下的句柄,这不同于“C”fopen返回的句柄。在Win16下,该句柄和C运行库文件操作函数相容。但在Win32下,“C”的文件操作函数不能使用该句柄,如果需要的话,可以使用函数_open_osfhandleWin32句柄得到一个“C”文件函数可以使用的文件句柄。

    关闭文件使用Win32CloseHandle

    Win32下,CreateFile可以操作的对象除了磁盘文件外,还包括设备文件如通讯端口、管道、控制台输入、邮件槽等等。

    4)使用CFile和其派生类进行文件操作。CFileCObject派生,其派生类包括操作文本文件的CStdioFile,操作内存文件的CmemFile,等等。

    CFile是建立在Win32的文件操作体系的基础上,它封装了部分Win32文件操作函数。

    最好是使用CFile类(或派生类)的对象来操作文件,必要的话,可以从这些类派生自己的文件操作类。统一使用CFile的界面可以得到好的移植性。

      1. MFC的文件类

    MFC用一些类来封装文件访问的Win32 API。以CFile为基础,从CFile派生出几个类,如CStdioFileCMemFileMFC内部使用的CMiororFile,等等。

        1. CFile的结构
          1. CFile定义的枚举类型

    CFile类定义了一些和文件操作相关的枚举类型,主要有四种:OpenFlagsAttributeSeekPositionhFileNull。下面,分别解释这些枚举类型。

    1. OpenFlags

    OpenFlags定义了13种文件访问和共享模式:

    enum OpenFlags {

    //第一(从右,下同)至第二位,打开文件时访问模式,读//读写

    modeRead = 0x0000,

    modeWrite = 0x0001,

    modeReadWrite = 0x0002,

    shareCompat = 0x0000, //32MFC中没用

    //第五到第七位,打开文件时的共享模式

    shareExclusive = 0x0010,//独占方式,禁止其他进程读写

    shareDenyWrite = 0x0020,//禁止其他进程写

    shareDenyRead = 0x0030,//禁止其他进程读

    shareDenyNone = 0x0040,//允许其他进程写

    //第八位,打开文件时的文件继承方式

    modeNoInherit = 0x0080,//不允许子进程继承

    //第十三、十四位,是否创建新文件和创建方式

    modeCreate = 0x1000,//创建新文件,文件长度0

    modeNoTruncate = 0x2000,//创建新文件时如文件已存在则打开

    //第十五、十六位,文件以二进制或者文本方式打开,在派生类CStdioFile中用

    typeText = 0x4000,

    typeBinary = (int)0x8000

    };

    1. Attribute

    Attribute定义了文件属性:正常、只读、隐含、系统文件,文件或者目录等。

    enum Attribute {

    normal = 0x00,

    readOnly = 0x01,

    hidden = 0x02,

    system = 0x04,

    volume = 0x08,

    directory = 0x10,

    archive = 0x20

    }

    1. SeekPosition

    SeekPosition定义了三种文件位置:头、尾、当前:

    enum SeekPosition{

    begin = 0x0,

    current = 0x1,

    end = 0x2

    };

    1. hFileNull

    hFileNull定义了空文件句柄

    enum { hFileNull = -1 };

          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用来保存文件名。

          1. 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

     

        1. CFile的部分实现

    这里主要讨论CFile对象的构造函数和文件的打开/创建的过程。

    1. 构造函数

    CFile有如下几个构造函数:

    • CFile()

    缺省构造函数,仅仅构造一个CFile对象,还必须使用Open成员函数来打开文件。

    • CFile(int hFile)

    已经打开了一个文件hFile,在此基础上构造一个CFile对象来给它打包。HFile将被赋值给CFile的成员变量m_hFile

    • CFile(LPCTSTR lpszFileName, UINT nOpenFlags)

    指定一个文件名和文件打开方式,构造CFile对象,调用Open打开/创建文件,把文件句柄保存到m_hFile

    1. 打开/创建文件

    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必须把自己的两个参数lpszFileNamenOpenFlags映射到CreateFile的七个参数上。

    OpenFlags的定义可以看出,(nOpenFlags & 3)表示了读写标识,映射成变量dwAccess,可以取值为Win32GENERIC_READGENERIC_WRITEGENERIC_READ|GENERIC_WRITE

    nOpenFlags & 0x70)表示了共享模式,映射成变量dwShareMode,可以取值为Win32FILE_SHARE_READFILE_SHARE_WRITEFILE_SHARE_WRITE|FILE_SHARE_READ

    Open定义了一个局部的SECURITY_ATTRIBUTES变量sa(nOpenFlags & 0x80)被赋值给sa.bInheritHandle

    (nOpenFlags & modeCreate)表示了创建方式,映射成变量dwCreateFlag,可以取值为Win32OPEN_ALWAYSCREATE_ALWAYSOPEN_EXISTING

    在生成了上述参数之后,先调用::CreateFile

    HANDLE hFile =::CreateFile(lpszFileName,

    dwAccess, dwShareMode, &sa,

    dwCreateFlag, FILE_ATTRIBUTE_NORMAL, NULL);

    然后,hFile被赋值给成员变量m_hFilem_bCloseOnDelete被设置为TRUE

    由上可以看出,CFile打开(创建)一个文件时大大简化了:: CreateFile函数的复杂性,即只需要指定一个文件名、一个打开文件的参数即可。若该参数指定为0,则表示以只读方式打开一个存在的文件,独占使用,不允许子进程继承。

    CFile对象使用时,如果它是在堆中分配的,则应该销毁它;如果在栈中分配的,则CFile对象将被自动销毁。销毁时析构函数被调用,析构函数是虚拟函数。若m_bCloseOnDelete为真且m_hFile非空,则析构函数调用Close关闭文件。

    至于其他CFile成员函数的实现,这里不作分析了。

        1. CFile的派生类

    这里主要简要地介绍CStdioFileCmemFileCFileFind

    1. CStdioFile

    CStdioFile对文本文件进行操作。

    CStdioFile定义了新的成员变量m_pStream,类型是FILE*。在打开或者创建文件时,使用_open_osfhandlem_hFile(Win32文件句柄)得到一个“C”FILE类型的文件指针,然后,在文件操作中,使用“C”的文件操作函数。例如,读文件使用_fread,而不是::ReadFile,写文件使用了_fwrite,而不是::WriteFile,等等。m_hFileCFile的成员变量。

    另外,CStdioFile不支持CFileDumplicateLockRangeUnlockRange操作,但是实现了两个新的操作ReadStringWriteString

    1. CMemFile

    CMemFile把一块内存当作一个文件来操作,所以,它没有打开文件的操作,而是设计了AttachDetach用来分配或者释放一块内存。相应地,它提供了AllocFree虚拟函数来操作内存文件,它覆盖了ReadWrite来读写内存文件。

    1. CFileFind

    为了方便文件查找,MFC把有关功能归结成为一个类CFileFindCFileFind派生于CObject类。首先,它使用FindFileFineNextFile包装了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

    1. 对话框和对话框类CDialog

    对话框经常被使用,因为对话框可以从模板创建,而对话框模板是可以使用资源编辑器方便地进行编辑的。

      1. 模式和无模式对话框

    对话框分两种类型,模式对话框和无模式对话框。

        1. 模式对话框

    一个模式对话框是一个有系统菜单、标题栏、边线等的弹出式窗口。在创建对话框时指定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将在销毁对话框窗口后返回这个值,一般,程序通过返回值判断对话框窗口是否完成了任务或者被用户取消。

        1. 无模式对话框

    一个无模式对话框是一个有系统菜单、标题栏、边线等的弹出式窗口。在创建对话框模板时指定WS_POPUPWS_CAPTIONWS_BORDERWS_SYSMENU风格。如果没有指定WS_VISIBLE风格,无模式对话框不会自动地显示出来。

    一个无模式对话框既不会禁止所属窗口,也不会给它发送消息。当创建一个模式对话框时,Windows使它成为活动窗口,但用户或者程序可以随时改变和设置活动窗口。如果对话框失去激活,那么即使所属窗口是活动的,在Z轴顺序上,它仍然在所属窗口之上。

    应用程序负责获取和派发输入消息给对话框。大部分应用程序使用主消息循环来处理,但是为了用户可以使用键盘在控制窗口之间移动或者选择控制窗口,应用程序应该调用::IsDialogMessage函数。

    这里,顺便解释::IsDialogMessage函数。虽然该函数是为无模式对话框设计的,但是任何包含了控制子窗口的窗口都可以调用它,用来实现类似于对话框的键盘选择操作。

    ::IsDialogMessage处理一个消息时,它检查键盘消息并把它们转换成相应对话框的选择命令。例如,当Tab 键被压下时,下一个或下一组控制被选中,当Down Arrow键按下后,一组控制中的下一个控制被选择。

    ::IsDialogMessage完成了所有必要的消息转换和消息派发,所以该函数处理的消息一定不要传递给TranslateMessageDispatchMessage处理。

    一个无模式对话框不能像模式对话框那样返回一个值给应用程序。但是对话框过程可以使用::SendMessage给所属窗口传递信息。

    在应用程序结束之前,它必须销毁所有的无模式对话框。使用::DestroyWindow销毁一个无模式对话框,不是使用::EndDiaLog。一般来说,对话框过程响应用户输入,如用户选择了取消按钮,则调用::DestroyWindow;如果用户没有有关动作,则应用程序必须调用::DestroyWindow

      1. 对话框的MFC实现

    MFC中,对话框窗口的功能主要由CWndCDialog两个类实现。

        1. CDialog的设计和实现

    MFC通过CDialog来封装对话框的功能。CDialogCWnd继承了窗口类的功能(包括CWnd实现的有关功能),并添加了新的成员变量和函数来处理对话框。

          1. 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_lpszTemplateNamem_hDialogTemplatem_lpDialogTemplate对应了三种模板资源,但在创建对话框时,只要一个模板资源就可以了,可以使用其中的任意一类。

          1. CDialog的成员函数:
    1. 构造函数:

    CDialog( LPCTSTR lpszTemplateName, CWnd* pParentWnd = NULL );

    CDialog( UINT nIDTemplate, CWnd* pParentWnd = NULL );

    CDialog( );

    CDialog重载了三个构造函数。其中,第三个是缺省构造函数;第一个和第二个构造函数从指定的对话框模板资源创建,pParentWnd指定了父窗口或所属窗口,若空则设置父窗口为应用程序主窗口。

    1. 初始化函数

    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用来根据内存中的模板创建模式对话框。它们都提供了两个重载版本。

    1. 对话框操作函数

    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 );

    1. 虚拟函数

    virtual int DoModal( );

    virtual BOOL OnInitDialog( );

    virtual void OnSetFont( CFont* pFont );

    virtual void OnOK( );

    virtual void OnCancel( );

        1. MFC模式对话框的实现

    从前面的介绍可以知道,Win32 SDK编程下的模式对话框使用了Windows提供给对话框窗口的窗口过程和自己的对话框过程,对话框过程将被窗口过程调用。但在MFC下,所有的窗口类都使用了同一个窗口过程,CDialog也不例外。CDialog对象在创建Windows对话框时,采用了类似于CWnd的创建函数过程,采用子类化的手段将Windows提供给对话框的窗口过程取代为AfxWndProc或者AfxBaseWndProc,同时提供了对话框过程AfxDlgProc。那么,这些过程是如何实现或者协调的呢?下文将予以分析。

          1. 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,给程序员一个机会处理对话框的初始化。

          1. 模式对话框窗口过程

    本小节讨论对话框的窗口过程。

    AfxWndProc是所有的MFC窗口类使用的窗口过程,它取代了模式对话框原来的窗口过程(Windows提供),那么,MFC如何完成Win32下对话框窗口的功能呢?

    考查模式对话框的创建过程。CDialog::DoModal用来创建模式对话框窗口并执行有关任务,和DoModal相关的是MFC内部使用的成员函数CDialog::PreModalCDialog::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

    {

    //链接一个HOOKHOOK链以处理窗口创建,

    //如同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取代了原来的对话框窗口过程,这两个消息如何送给对话框过程呢?处理方法如下节所描述。

          1. 使用原对话框窗口过程作消息的缺省处理

    对话框的消息处理过程和其他窗口并没有什么不同。这里主要分析的是如何把一些消息传递给对话框原窗口过程处理。下面,通过解释MFCWM_INITDIALOG消息的处理来解释MFC窗口过程和原对话框窗口过程的关系及其协调作用。

    MFC提供了WM_INITDIALOG消息的处理函数CDialog::HandleInitDialogWM_INITDIALOG消息按照标准Windows的处理送给HandleInitDialog处理。

    HandleInitDialog调用缺省处理过程Default,导致CWndDefault函数被调用。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的实现中,CWndDefWindowsProc被调用,其实现如下:

    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消息之前和之后都会有一些特别的处理,如尝试把对话框放到屏幕中间。具体实现这里略。

    OnInitDialogMFC缺省实现主要完成三件事情:

    调用ExecInitDialog初始化对话框中的控制;调用UpdateData初始化对话框控制中的数据;确定是否显示帮助按钮。所以,程序员覆盖该函数时,一定要调用基类的实现。

    MFC采用子类化的方法取代了对话框的窗口过程,实现了12.1节描述的模式对话框窗口的一些特性,原来SDK下对话框过程要处理的东西大部分转移给MFC窗口过程处理,如处理控制窗口的控制通知消息等。如果不能处理或者必须借助于原来的窗口过程的,则通过缺省处理函数Default传递给原来的窗口过程处理,如同这里对WM_INITDIALOG的处理一样。

          1. Dialog命令消息和控制通知消息的处理

    通过覆盖CWnd的命令消息发送函数OnCmdMsgCDialog实现了自己的命令消息发送路径。在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不仅适用于模式对话框,也适用于无模式对话框。

          1. 消息预处理和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中被处理,不会进入消息发送的处理。

    PreTranslateInputCWnd的成员函数,它调用::IsDialogMessage函数来处理Dialog消息。

    PreTranslateMessage的实现不仅用于模式对话框,而且用于无模式对话框。

          1. 模式对话框的消息循环

    DoModal的实现可以看出,DoModal调用CreateDlgIndirect创建的是无模式对话框,MFC如何来接管和控制应用程序的消息队列,实现一个模式对话框的功能呢?

    CDialog调用了RunModalLoop来实现模式窗口的消息循环。RunModalLoopCWnd的成员函数,它和相关函数的实现如下:

    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;

    }

    }

    //第二阶段,发送消息

    do

    {

    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也分两个阶段进行处理。不同之处在于,这里不同于RunIdle处理,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);

    }

    上述函数OnOkOnCancleEndDialog都可以用来关闭对话框窗口。其中:

    OnOk首先进行数据交换,获取对话框中各个控制子窗口的数据,然后调用EndDialog结束对话框。

    OnCancle直接EndDialog结束对话框。

    EndDialog首先修改m_nFlag的值,表示结束模式循环,然后调用::EndDialog关闭对话框窗口。

        1. 对话框的数据交换

    对话框数据交换指以下两种动作,或者是把内存数据写入对应的控制窗口,或者是从控制窗口读取数据并保存到内存变量中。MFC为了简化这些操作,以CDataExchange类和一些数据交换函数为基础,提供了一套数据交换和校验的机制。

          1. 数据交换的方法

    首先,定义保存数据的内存变量──给对话框添加成员变量,每个控制窗口可以对应一个成员变量,或者是控制窗口类型,或者是控制窗口表示的数据的类型。例如,对于对话框的一个编辑控制窗口,可以定义一个CEdit类型的成员变量,或者一个CString类型的成员变量。

    其次,覆盖对话框的虚拟函数DoDataExchange,实现数据交换和验证。

    ClassWizard可以协助程序员自动地添加成员变量,修改DoDataExchange。例如,一个对话框有两个控制窗口,其中的一个编辑框表示姓名,IDIDC_NAME,另一个编辑框表示年龄,IDIDC_AGEClassWizard添加如下的成员变量:

    // 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应该在1100之间取值。

          1. 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类似于CArchiveCDataExchange使用成员变量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

          1. 数据交换和验证函数

    在进行数据交换或者验证时,首先使用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文件,在DDXDDV函数入口中加入自己创建的函数。

          1. 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,如果参数为TRUEdx用来写数据,否则dx用来读数据;然后调用DoDataExchange进行数据交换。在数据交换期间,为了防止当前窗口接收和处理命令通知消息,在当前线程的线程状态中记录该窗口的句柄,用来防止给该窗口发送通知消息。

    使用MFC的数据交换和验证机制,大大简化了程序员的工作。通常在OnInitDialog中,MFC调用UpdateData(FALSE)把数据送给控制窗口显示;在OnOk中,调用UpdateData(TRUE)从控制窗口中读取数据。

      1. 无模式对话框

    CFormViewMFC使用无模式对话框的一个典型例子。CFormView是基于对话框模板创建的视,它的直接基类是CSrcollViewCSrcollView的直接基类才是CView。所以,这里先对CScorllView作一个简要的介绍。

        1. CScrollView

    CScrollView继承了CView的特性,并且增加了如下的功能:

    1)管理映射模式、窗口尺寸、视口尺寸(Map modeWindow 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被定义为(00)。

    • 下面几个函数用来实现滚动或者得到滚动条相关的信息

    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_SIZEOnSize

    处理WM_HSCROLLOnHScroll

    处理WM_VSCROLLOnVScroll

    • 覆盖的虚拟函数

    CWndCalcWindowRect

    CViewOnPrepareDCOnScrollOnScrollBy

    • 用于DEBUGDumpAssertValid

    这里,覆盖的消息处理函数和虚拟函数共同完成对滚动条、滚动消息的处理。

    CSrcollView的实现涉及到许多和Windows映射模式、坐标转换等相关的函数的使用。这里,不作具体讨论。

        1. CFormView