第四章，简单绘图之MFC中消息分类

MFC中的消息分类

消息分类从不同的角度，有如下几种分类方式。

一、从消息的发送途径上看，可以分为队列消息和非队列消息。

队列消息和非队列消息Windows为当前运行的每个Windows程序维护一个“消息队列”。当通过鼠标或者键盘发生输入事件后，Windows将事件转换为一个“消息”，并将消息放入程序的消息队列中。而队列消息是指由Windows放入程序的消息队列中的消息，在程序消息循环中，队列消息被重新传回并分配给窗口过程。非队列消息是指在Windows调用窗口时直接传送给窗口过程的消息。也就是说，队列消息被“发送”给消息队列，而非队列消息则“发送”给窗口过程。由此可以发现，窗口过程是窗口消息的处理场所。
（1）队列消息队列消息大都是用户输入的结果，如击键（WM_KEYDOWN和WM_KEYUP消息）、字符（WM_CHAR）消息、移动鼠标（WM_MOUSEMOVE消息）以及单击鼠标（WM_ LBUTTONDOWN和WM_LBUTTONUP等消息）等。队列消息还包括时钟消息（WM_ TIMER）、重画消息（WM_PAINT）和退出消息（WM_QUIT）等。
（2）非队列消息大部分消息都是非队列消息。此类消息大部分来自特定的Windows函数，如当调用UpdateWindow时，Windows将给调用此函数窗口的窗口过程发送WM_PAINT；当调用DestroyWindow时，Windows将给调用此函数窗口的窗口过程发送WM_DESTROY等。

二、从消息的来源来看，可以分为系统消息和自定义消息。

Windows消息是预定义的一些UINT常量值，它对系统本身用到的消息进行了定义，为了实现额外的消息，系统为开发人员预留了消息定义的接口，这样，当需要使用系统以外的消息时，可以使用该接口进行定义自己的消息。
系统消息ID的范围是从0～WM_USER-1，或0X80000～0XBFFFF；应用程序消息从WM_USER（0X0400）～0X7FFF，或0XC000～0XFFFF；WM_USER～0X7FFF范围的消息由应用程序自己使用；0XC000～0XFFFF范围的消息用来和其他应用程序通信，为了保证ID的唯一性，使用::RegisterWindowMessage来获取该范围的消息ID。

三、从对消息的处理上看，可以分为窗口消息、命令消息和控件通知。

（1）标准消息：

除WM_COMMAND之外，所有以WM_开头的消息都是标准消息。从CWnd派生的类都可以接受到这类消息。

（2）命令消息：

来自菜单、加速键或工具栏按钮的消息。这类消息都以WM_COMMAND形式呈现。在MFC中，通过菜单项的标识（ID）来区分不同的命令消息；在SDK中，通过消息的wParam参数识别。从CCmdTarget派生的类，都可以接受到这类消息。

（3）通告消息：（控件消息）

由控件产生的消息，例如按钮的单击、列表框的选择等都会产生这类消息，目的是为了向其父窗口（通常是对话框）通知时间的发生。这类消息也是以WM_COMMAND形式呈现的。从CCmdTarget派生的类，都可以接收到这类消息。

WM_COMMAND和WM_NOTIFY消息都是WINDOWS CONTROL给它的父窗体发的消息，那这两种消息有什么不同呢？

WM_COMMAND消息其实是早期的（WIN3.X时代）子窗体消息，子窗体给父窗体发送消息，父窗体就捕获WM_COMMAND来处理子窗体的消息。但是这个消息只包括了有限的信息，例如wParam包括了子窗口ID和通知码，lParam则包括了子窗口句柄，就这点信息了，如果想知道一些额外的信息的话（例如，鼠标点在了子控件的位置）就要借助于其他的WM_*消息。所以对于新型的WIN32控件，微软就增加了一个新的NOTIFICATION消息，这个消息的参数是这样的：wParam包含了控件ID，而lParam则包含了一个结构体的指针，这个结构体是NMHDR结构或者以NMHDR结构为第一项的一个更大的结构体。这样就可以包含了很多的子控件想给父窗体提供的信息了，甚至可以自己去定义这种的结构体。

对于WM_NOTIFY消息，通常情况下，lParam指向一个比NMHDR更大的结构，因此，在使用过程中，通常需要进行映射。不过当用类向导对WM_NOTIFY消息进行响应时，它会自动设为一个合适的指针。仅有少数的通知，例如通用通知（通知消息以NM_打头）和工具提示控件的TTN_SHOW和TTN_POP通知才是实际使用NMHDR结构。所以，通常也将NMHDR称作通知消息头（Notification Message Header，具体定义参见MSDN）。标准Windows控件如编辑控件、组合框控件、列表框控件、按钮控件、滚动条控件以及静态控件等并不发送WM_NOTIFY消息。

MFC中消息映射机制分析

1引言

微软公司提供的MFC基本类库(MicrosoftFoundationClasses)，是进行可视化编程时使用最为流行的一个类库。MFC封装了大部分WindowsAPI函数和Windows控件，使得程序的开发变得简单，极大的缩短了程序的开发周期。MFC独创的Document/View框架结构，能够将管理数据的代码和显示数据的程序代码分开，并且设计了一套方便的消息映射和命令传递机制，方便程序员的开发使用。其中消息映射机制本身比较庞大和复杂，对它的分析和了解无疑有助于我们写出更为合理的高效的程序。这里我们分析一下MFC的消息映射机制，以了解MFC是如何对Windows的消息加以封装，方便用户的开发。

2．SDK下的消息机制实现

首先，简单回顾一下SDK下我们是如何进行Windows的程序开发的。Windows程序的运行是依靠外部发生的事件来驱动的，事件由操作系统捕捉，以消息的形式进入消息队列，然后通过消息循环从队列中不断取出消息，送到对应的窗口过程里处理。相对于DOS程序，Windows是以WinMain作为程序的入口点，以下就是一个简化的Win32程序的主体，通过while语句实现消息循环:

WinMain(…)

{

  MSGmsg;

  RegisterClass(…);          //注册窗口类

  CreateWindow(…);           //创建窗口

  ShowWindow(…);             //显示窗口

  UpdateWindow(…);

  While(GetMessage(&msg,…)){  //消息循环

  TranslateMessage(…);

  DispatchMessage(…);

  }

  returnmsg.wParam;

}

其中，msg代表消息，程序是通过GetMessage函数从和某个线程相对应的消息队列里面把消息取出来并放到消息变量msg里面。然后TranslateMessage函数用来把键盘消息转化并放到响应的消息队列里面，最后DispatchMessage函数把消息分发到相关的窗口过程去处理。窗口过程根据消息的类型对不同的消息进行相关的处理。在SDK编程过程中，用户需要在窗口过程中分析消息的类型及其参数的含义，然后做不同的处理，相对比较麻烦；而MFC把消息调用的过程给封装起来，使用户能够通过ClassWizard方便的使用和处理Windows的各种消息。

3．MFC中的消息映射机制

在MFC的框架结构下，“消息映射”是通过巧妙的宏定义，形成一张消息映射表格来进行的。这样一旦消息发生，Framework就可以根据消息映射表格来进行消息映射和命令传递。首先在需要进行消息处理的类的头文件（.H）里，都会含有DECLARE_MESSAGE_MAP()宏,声明该类拥有消息映射表格：

classCscribbleDoc:publicCdocument

{

   …

DECLARE_MESSAGE_MAP()

};

然后在类应用程序文件（.CPP）实现这一表格

BEGIN_MESSAGE_MAP(CInheritClass,CBaseClass)

    //{{AFX_MSG_MAP(CInheritClass)

        ON_COMMAND(ID_EDIT_COPY,OnEditCopy)

        ………

    //}}AFX_MSG_MAP

END_MESSAGE_MAP()

----这里主要进行消息映射的实现，把它和消息处理函数联系在一起。其中出现三个宏，

第一个宏是BEGIN_MESSAGE_MAP有两个参数，分别是拥有消息表格的类，及其父类。第二个宏是ON_COMMAND，指定命令消息的处理函数名称。第三个宏是END_MESSAGE_MAP()作为结尾符号。中间的奇怪符号//}}和//{{，是ClassWizard产生的，对程序无影响。

观察DECLARE_MESSAGE_MAP的定义：

#defineDECLARE_MESSAGE_MAP()

private:

staticconstAFX_MESSAGE_ENTRY_messageEntries[];

protected:

staticAFX_DATAconstAFX_MSGMAPmessageMap;

virtualconstAFX_MSGMAP*GetMessageMap()const;

里面又包含了MFC新定义的两个数据结构，如下：

AFX_MSGMAP_ENTRY

structAFX_MSGMAP_ENTRY

{

    UINTnMessage;  //windowsmessage

    UINTnCode;     //controlcodeorWM_NOTIFYcode

    UINTnID;       //controlID(or0forwindowsmessages)

    UINTnLastID;  //usedforentriesspecifyingarangeofcontrolid's

    UINTnSig;     //signaturetype(action)orpointertomessage#

    AFX_PMSGpfn;   //routinetocall(orspecialvalue)

};

和AFX_MSGMAP

structAFX_MSGMAP

{

    constAFX_MSGMAP*pBaseMap;

    constAFX_MSGMAP_ENTRY*lpEntries;

};

其中AFX_MSGMAP_ENTRY结构包含了一个消息的所有相关信息,而AFX_MSGMAP主要作用有两个，一是用来得到基类的消息映射入口地址。二是得到本身的消息映射入口地址。实际上，MFC把所有的消息一条条填入到AFX_MSGMAP_ENTRY结构中去，形成一个数组，该数组存放了所有的消息和与它们相关的参数。同时通过AFX_MSGMAP能得到该数组的首地址，同时得到基类的消息映射入口地址。当本身对该消息不响应的时候，就可以上溯到基类的消息映射表寻找对应的消息响应。

现在我们来分析MFC是如何让窗口过程来处理消息的，实际上所有MFC的窗口类都通过钩子函数_AfxCbtFilterHook截获消息，并且在钩子函数_AfxCbtFilterHook中把窗口过程设定为AfxWndProc。原来的窗口过程保存在成员变量m_pfnSuper中。在MFC框架下，一般一个消息的处理过程是这样的。

(1)函数AfxWndProc接收Windows操作系统发送的消息。

(2)函数AfxWndProc调用函数AfxCallWndProc进行消息处理，这里一个进步是把对句柄的操作转换成对CWnd对象的操作。

(3)函数AfxCallWndProc调用CWnd类的方法WindowProc进行消息处理。

(4)WindowProc调用OnWndMsg进行正式的消息处理，即把消息派送到相关的方法中去处理。在CWnd类中都保存了一个AFX_MSGMAP的结构，而在AFX_MSGMAP结构中保存有所有我们用ClassWizard生成的消息的数组的入口，我们把传给OnWndMsg的message和数组中的所有的message进行比较，找到匹配的那一个消息。实际上系统是通过函数AfxFindMessageEntry来实现的。找到了那个message，实际上我们就得到一个AFX_MSGMAP_ENTRY结构，而我们在上面已经提到AFX_MSGMAP_ENTRY保存了和该消息相关的所有信息，其中主要是消息的动作标识和相关的执行函数。然后我们就可以根据消息的动作标识调用相关的执行函数，而这个执行函数实际上就是通过ClassWizard在类实现中定义的一个方法。这样就把消息的处理转化到类中的一个方法的实现上。

(5)如果OnWndMsg方法没有对消息进行处理的话，就调用DefWindowProc对消息进行处理。这是实际上是调用原来的窗口过程进行缺省的消息处理。所以如果正常的消息处理的话，MFC窗口类是完全脱离了原来的窗口过程，用自己的一套体系结构实现消息的映射和处理。即先调用MFC窗口类挂上去的窗口过程，再调用原先的窗口过程。用户面对的消息参数将不再是固定的wParam和lParam,而是和消息类型具体相关的参数。比如和消息WM_LButtonDown相对应的方法OnLButtonDown的两个参数是nFlags和point。nFlags表示在按下鼠标左键的时候是否有其他虚拟键按下，point更简单，就是表示鼠标的位置。

同时MFC窗口类消息传递中还提供了两个函数，分别为WalkPreTranslateTree和PreTranslateMessage。我们知道利用MFC框架生成的程序，都是从CWinApp开始执行的，而CWinapp实际继承了CWinThread类。在CWinThread的运行过程中会调用窗口类中的WalkPreTranslateTree方法。而WalkPreTranslateTree方法实际上就是从当前窗口开始查找愿意进行消息翻译的类，直到找到窗口没有父类为止。在WalkPreTranslateTree方法中调用了PreTranslateMessage方法。实际上PreTranslateMessage最大的好处是我们在消息处理前可以在这个方法里面先做一些事情。举一个简单的例子，比如我们希望在一个CEdit对象里，把所有的输入的字母都以大写的形式出现。我们只需要在PreTranslateMessage方法中判断message是否为WM_CHAR,如果是的话，把wParam(表示键值)由小写字母的值该为大写字母的值就实现了这个功能。

4小结

MFC通过巧妙的宏定义把消息调用的过程给封装起来，使用户能够通过ClassWizard方便的使用和处理Windows的各种消息。通过对MFC消息映射机制的分析，不仅能够使我们更好的使用MFC类库，同时，对于我们自己设计程序框架和类，无疑也有相当大的帮助。

MFC的消息映射机制 

MFC的设计者们在设计MFC时，紧紧把握一个目标，那就是尽可能使得MFC的代码要小，速度尽可能快。为了这个目标，他们使用了许多技巧，其中很多技巧体现在宏的运用上，实现MFC的消息映射的机制就是其中之一。
　　同MFC消息映射机制有关的宏有下面几个：
　　DECLARE_MESSAGE_MAP()宏
　　BEGIN_MESSAGE_MAP(theClass,baseClass)和END_MESSAGE_MAP()宏
　　弄懂MFC消息映射机制的最好办法是将找出一个具体的实例，将这些宏展开，并找出相关的数据结构。
　　DECLARE_MESSAGE_MAP()
　   DECLARE_MESSAGE_MAP()宏的定义如下：
　　#defineDECLARE_MESSAGE_MAP() \
　　private: \
　　static constAFX_MSGMAP_ENTRY _messageEntries[]; \
　　protected: \
　　staticAFX_DATA const AFX_MSGMAP messageMap; \
　　virtualconst AFX_MSGMAP* GetMessageMap() const; \
从上面的定义可以看出，DECLARE_MESSAGE_MAP()作下面三件事：
　　定义一个长度不定的静态数组变量_messageEntries[]；
　　定义一个静态变量messageMap；
　　定义一个虚拟函数GetMessageMap()；
在DECLARE_MESSAGE_MAP()宏中，涉及到MFC中两个对外不公开的数据结构
AFX_MSGMAP_ENTRY和AFX_MSGMAP。为了弄清楚消息映射，有必要考察一下这两个数据结构的定义。
　　（1）AFX_MSGMAP_ENTRY的定义
　　structAFX_MSGMAP_ENTRY
　　{
　　　UINTnMessage; // windows message
　　　UINT nCode;// control code or WM_NOTIFY code
　　　UINT nID;// control ID (or 0 for windows messages)
　　　UINTnLastID; // used for entries specifying a range of control id's
　　　UINT nSig;// signature type (action) or pointer to message #
　　　AFX_PMSGpfn; // routine to call (or special value)
　　};
结构中各项的含义注释已经说明得很清楚了，这里不再多述，从上面的定义你是否看出，AFX_MSGMAP_ENTRY结构实际上定义了消息和处理此消息的动作之间的映射关系。因此静态数组变量_messageEntries[]实际上定义了一张表，表中的每一项指定了相应的对象所要处理的消息和处理此消息的函数的对应关系，因而这张表也称为消息映射表。再看看AFX_MSGMAP的定义。
　　（2）AFX_MSGMAP的定义
　　structAFX_MSGMAP
　　{
　　　constAFX_MSGMAP* pBaseMap;
　　　constAFX_MSGMAP_ENTRY* lpEntries;
　　};
不难看出，AFX_MSGMAP定义了一单向链表，链表中每一项的值是一指向消息映射表的指针（实际上就是_messageEntries的值）。通过这个链表，使得在某个类中调用基类的的消息处理函数很容易，因此，“父类的消息处理函数是子类的缺省消息处理函数”就“顺理成章”了。在后面的“MFC窗口的消息处理”一节中会对此作详细的讲解。

由上述可见，在类的头文件中主要定义了两个数据结构：消息映射表和单向链表。（孙建东总结）
　　BEGIN_MESSAGE_MAP()和END_MESSAGE_MAP()
　　它们的定义如下：
　　#defineBEGIN_MESSAGE_MAP(theClass, baseClass) \
　　constAFX_MSGMAP* theClass::GetMessageMap() const \
　　{ return&theClass::messageMap; } \
　　AFX_COMDATAFX_DATADEF const AFX_MSGMAP theClass::messageMap = \
　　{&baseClass::messageMap, &theClass::_messageEntries[0] }; \
　　AFX_COMDATconst AFX_MSGMAP_ENTRY theClass::_messageEntries[] = \
　　{ \
　　　#defineEND_MESSAGE_MAP() \
　　　{0, 0, 0,0, AfxSig_end, (AFX_PMSG)0 } \
　　}; \
对应BEGIN_MESSAGE_MAP()的定义可能不是一下子就看得明白，不过不要紧，举一例子就很清楚了。对于BEGIN_MESSAGE_MAP(CView,CWnd)，VC预编译器将其展开成下面的形式：
　　constAFX_MSGMAP* CView::GetMessageMap() const
　　{ 
　　　return&CView::messageMap; 
　　}
　　AFX_COMDATAFX_DATADEF const AFX_MSGMAP CView::messageMap =
　　{ 
　　　&CWnd::messageMap, 
　　　&CView::_messageEntries[0] 
　　};
　　AFX_COMDATconst AFX_MSGMAP_ENTRY CView::_messageEntries[] =
　　{
　　至于END_MESSAGE_MAP()则不过定义了一个表示映射表结束的标志项，我想大家对于这种简单的技巧应该是很熟悉的，无需多述。

到此为止，我想大家也已经想到了象ON_COMMAND这样的宏的具体作用了，不错它们只不过定义了一种类型的消息映射项，看看ON_COMMAND的定义：
　　#defineON_COMMAND(id, memberFxn) \
　　{WM_COMMAND, CN_COMMAND, (WORD)id, (WORD)id, AfxSig_vv, (AFX_PMSG)&memberFxn},
　　　根据上面的定义，ON_COMMAND(ID_FILE_NEW,OnFileNew)将被VC预编译器展开
　　　如下：
　　{WM_COMMAND,CN_COMMAND, (WORD)id, (WORD)id, AfxSig_vv, 
　　(AFX_PMSG)&OnFileNew},

到此，MFC的消息映射机制已经清楚了，现在提出并解答两个问题以作为对这一节的小结。
　　为什么不直接使用虚拟函数实现消息处理函数呢？这是一个GOOD QUESTION。前面已经说过，MFC的设计者们在设计MFC时有一个很明确的目标，就是使得“MFC的代码尽可能小，速度尽可能快”，如果采用虚拟函数，那么对于所有的窗口消息，都必须有一个与之对应的虚拟函数，因而对每一个从CWnd派生的类而言，都会有一张很大的虚拟函数表vtbl。但是在实际应用中，一般只对少数的消息进行处理，大部分都交给系统缺省处理，所以表中的大部分项都是无用项，这样做就浪费了很多内存资源，这同MFC设计者们的设计目标是相违背的。当然，MFC所使用的方法只是解决这类问题的方式之一，不排除还有其他的解决方式，但就我个人观点而言，这是一种最好的解决方式，体现了很高的技巧性，值得我们学习。

　　至于这第二个问题，是由上面的问题引申出来的。如果在子类和父类中出现了相同的消息出来函数，VC编译器会怎么处理这个问题呢？VC不会将它们看作错误，而会象对待虚拟函数类似的方式去处理，但对于消息处理函数(带afx_msg前缀)，则不会生成虚拟函数表vtbl。

MFC下一个消息的处理过程是一般是这样的。
1、_AfxCbtFilterHook截获消息（这是一个钩子函数）
2、_AfxCbtFilterHook把窗口过程设定为AfxWndProc。
3、函数AfxWndProc接收Windows操作系统发送的消息。
4、函数AfxWndProc调用函数AfxCallWndProc进行消息处理。
5、函数AfxCallWndProc调用CWnd类的方法WindowProc进行消息处理。

如何添加自己的消息？
我们已经了解了WINDOW的消息机制，如何加入我们自己的消息呢？好我们来看
一个标准的消息处理程序是这个样子的
在 CWnd 类中预定义了标准 Windows 消息 (WM_XXXX  WM是WINDOW MESSAGE的缩写) 的默认处理程序。类库基于消息名命名这些处理程序。例如，WM_PAINT 消息的处理程序在 CWnd 中被声明为：
afx_msg void OnPaint();
afx_msg 关键字通过使这些处理程序区别于其他 CWnd 成员函数来表明 C++virtual 关键字的作用。但是请注意，这些函数实际上并不是虚拟的，而是通过消息映射实现的。我们在本文的一开始便说明了为什么要这样做。
所有能够进行消息处理的类都是基于CCmdTarget类的，也就是说CCmdTarget类是所有可以进行消息处理类的父类。CCmdTarget类是MFC处理命令消息的基础和核心。

若要重写基类中定义的处理程序，只需在派生类中定义一个具有相同原型的函数，并创建此处理程序的消息映射项。我们通过ClassWizard可以建立大多数窗口消息或自定义的消息，通过ClassWizard可以自动建立消息映射，和消息处理函数的框架，我们只需要把我们要做的事情填空,添加你要做的事情到处理函数。这个非常简单，就不细说了。但是也许我们需要添加一些ClassWizard不支持的窗口消息或自定义消息，那么就需要我们亲自动手建立消息映射和消息处理的框架，通常步骤如下：
第一步：定义消息。Microsoft推荐用户自定义消息至少是WM_USER+100，因为很多新控件也要使用WM_USER消息。
#define WM_MYMESSAGE (WM_USER + 100)

第二步：实现消息处理函数。该函数使用WPRAM和LPARAM参数并返回LPESULT。
LPESULT CMainFrame::OnMyMessage(WPARAM wParam, LPARAM lParam)
{
// TODO: 处理用户自定义消息，填空就是要填到这里。
return 0;
}
第三步：在类头文件的AFX_MSG块中说明消息处理函数：
// {{AFX_MSG(CMainFrame)
afx_msg LRESULT OnMyMessage(WPARAM wParam, LPARAM lParam);
//}}AFX_MSG
DECLARE_MESSAGE_MAP()
第四步：在用户类的消息块中，使用ON_MESSAGE宏指令将消息映射到消息处理函数中。
ON_MESSAGE( WM_MYMESSAGE, OnMyMessage )

MFC消息响应机制分析

---- MFC是Windows下程序设计的最流行的一个类库，但是该类库比较庞杂，尤其是它的消息映射机制，更是涉及到很多低层的东西，我们在这里，对它的整个消息映射机制进行了系统的分析，可以帮助程序开发人员对MFC的消息映射机制有一个比较透彻的了解。

1．引言

---- VC++的MFC类库实际上是Windows下C++编程的一套最为流行的类库。MFC的框架结构大大方便了程序员的编程工作，但是为了更加有效、灵活的使用MFC编程，了解MFC的体系结构往往可以使编程工作事半功倍。它合理的封装了WIN32 API函数，并设计了一套方便的消息映射机制。但这套机制本身比较庞大和复杂，对它的分析和了解无疑有助于我们写出更为合理的高效的程序。这里我们简单的分析MFC的消息响应机制，以了解MFC是如何对Windows的消息加以封装，方便用户的开发。

2. SDK下的消息机制实现
---- 这里简单的回顾一下SDK下我们是如何进行Windows的程序开发的。一般来说，Windows的消息都是和线程相对应的。即Windows会把消息发送给和该消息相对应的线程。在SDK的模式下，程序是通过GetMessage函数从和某个线程相对应的消息队列里面把消息取出来并放到一个特殊的结构里面，一个消息的结构是一个如下的STRUCTURE。 
typedef struct tagMSG {
HWND hwnd;
UINT message; 
WPARAM wParam;
LPARAM lParam;
DWORD time;
POINT pt; 
}MSG;
---- 其中hwnd表示和窗口过程相关的窗口的句柄，message表示消息的ID号，wParam和lParam表示和消息相关的参数，time表示消息发送的时间，pt表示消息发送时的鼠标的位置。

---- 然后TranslateMessage函数用来把虚键消息翻译成字符消息并放到响应的消息队列里面，最后DispatchMessage函数把消息分发到相关的窗口过程。然后窗口过程根据消息的类型对不同的消息进行相关的处理。在SDK编程过程中，用户需要在窗口过程中分析消息的类型和跟消息一起的参数的含义，做不同的处理，相对比较麻烦，而MFC把消息调用的过程给封装起来，使用户能够通过ClassWizard方便的使用和处理Windows的各种消息。

3．MFC的消息实现机制
---- 我们可以看到，在MFC的框架结构下，可以进行消息处理的类的头文件里面都会含有DECLARE_MESSAGE_MAP()宏,这里主要进行消息映射和消息处理函数的声明。可以进行消息处理的类的实现文件里一般都含有如下的结构。 
BEGIN_MESSAGE_MAP(CInheritClass, CBaseClass)
//{{AFX_MSG_MAP(CInheritClass)
//}}AFX_MSG_MAP
END_MESSAGE_MAP()

---- 这里主要进行消息映射的实现和消息处理函数的实现。 
---- 所有能够进行消息处理的类都是基于CCmdTarget类的，也就是说CCmdTarget类是所有可以进行消息处理类的父类。CCmdTarget类是MFC处理命令消息的基础和核心。

---- 同时MFC定义了下面的两个主要结构:

AFX_MSGMAP_ENTRY
struct AFX_MSGMAP_ENTRY
{
UINT nMessage; // windows message
UINT nCode; // control code or WM_NOTIFY code
UINT nID; 
// control ID (or 0 for windows messages)
UINT nLastID; 
// used for entries specifying a range of control id's
UINT nSig; 
// signature type (action) or pointer to message #
AFX_PMSG pfn; // routine to call (or special value)
};
和AFX_MSGMAP
struct AFX_MSGMAP
{
#ifdef _AFXDLL
const AFX_MSGMAP* (PASCAL* pfnGetBaseMap)();
#else
const AFX_MSGMAP* pBaseMap;
#endif
const AFX_MSGMAP_ENTRY* lpEntries;
};

其中AFX_MSGMAP_ENTRY结构包含了
一个消息的所有相关信息,其中

nMessage为Windows消息的ID号
nCode为控制消息的通知码
nID为Windows控制消息的ID
nLastID表示如果是一个指定范围的消息被映射的话，
nLastID用来表示它的范围。
nSig表示消息的动作标识
AFX_PMSG pfn 它实际上是一个指向和该消息相应的执行函数的指针。

---- 而AFX_MSGMAP主要作用是两个，一：用来得到基类的消息映射入口地址。二：得到本身的消息映射入口地址。

---- 实际上，MFC把所有的消息一条条填入到AFX_MSGMAP_ENTRY结构中去，形成一个数组，该数组存放了所有的消息和与它们相关的参数。同时通过AFX_MSGMAP能得到该数组的首地址，同时得到基类的消息映射入口地址，这是为了当本身对该消息不响应的时候，就调用其基类的消息响应。

---- 现在我们来分析MFC是如何让窗口过程来处理消息的，实际上所有MFC的窗口类都通过钩子函数_AfxCbtFilterHook截获消息，并且在钩子函数_AfxCbtFilterHook中把窗口过程设定为AfxWndProc。原来的窗口过程保存在成员变量m_pfnSuper中。

---- 所以在MFC框架下，一般一个消息的处理过程是这样的。

函数AfxWndProc接收Windows操作系统发送的消息。

函数AfxWndProc调用函数AfxCallWndProc进行消息处理，这里一个进步是把对句柄的操作转换成对CWnd对象的操作。

函数AfxCallWndProc调用CWnd类的方法WindowProc进行消息处理。注意AfxWndProc和AfxCallWndProc都是AFX的API函数。而WindowProc已经是CWnd的一个方法。所以可以注意到在WindowProc中已经没有关于句柄或者是CWnd的参数了。

方法WindowProc调用方法OnWndMsg进行正式的消息处理，即把消息派送到相关的方法中去处理。消息是如何派送的呢？实际上在CWnd类中都保存了一个AFX_MSGMAP的结构，而在AFX_MSGMAP结构中保存有所有我们用ClassWizard生成的消息的数组的入口，我们把传给OnWndMsg的message和数组中的所有的message进行比较，找到匹配的那一个消息。实际上系统是通过函数AfxFindMessageEntry来实现的。找到了那个message，实际上我们就得到一个AFX_MSGMAP_ENTRY结构，而我们在上面已经提到AFX_MSGMAP_ENTRY保存了和该消息相关的所有信息，其中主要的是消息的动作标识和跟消息相关的执行函数。然后我们就可以根据消息的动作标识调用相关的执行函数，而这个执行函数实际上就是通过ClassWizard在类实现中定义的一个方法。这样就把消息的处理转化到类中的一个方法的实现上。举一个简单的例子，比如在View中对WM_LButtonDown消息的处理就转化成对如下一个方法的操作。 
void CInheritView::OnLButtonDown
(UINT nFlags, CPoint point) 
{
// TODO: Add your message 
handler code here and/or call default 
CView::OnLButtonDown(nFlags, point);
}

注意这里CView::OnLButtonDown(nFlags,point)实际上就是调用CWnd的Default()方法。 而Default()方法所做的工作就是调用DefWindowProc对消息进行处理。这实际上是调用原来的窗口过程进行缺省的消息处理。

如果OnWndMsg方法没有对消息进行处理的话，就调用DefWindowProc对消息进行处理。这是实际上是调用原来的窗口过程进行缺省的消息处理。 
---- 所以如果正常的消息处理的话，MFC窗口类是完全脱离了原来的窗口过程，用自己的一套体系结构实现消息的映射和处理。即先调用MFC窗口类挂上去的窗口过程，再调用原先的窗口过程。并且用户面对和消息相关的参数不再是死板的wParam和lParam,而是和消息类型具体相关的参数。比如和消息WM_LbuttonDown相对应的方法OnLButtonDown的两个参数是nFlags和point。nFlags表示在按下鼠标左键的时候是否有其他虚键按下，point更简单，就是表示鼠标的位置。 
---- 同时MFC窗口类消息传递中还提供了两个函数，分别为WalkPreTranslateTree和PreTranslateMessage。我们知道利用MFC框架生成的程序，都是从CWinApp开始执行的，而CWinapp实际继承了CWinThread类。在CWinThread的运行过程中会调用窗口类中的WalkPreTranslateTree方法。而WalkPreTranslateTree方法实际上就是从当前窗口开始查找愿意进行消息翻译的类，直到找到窗口没有父类为止。在WalkPreTranslateTree方法中调用了PreTranslateMessage方法。实际上PreTranslateMessage最大的好处是我们在消息处理前可以在这个方法里面先做一些事情。举一个简单的例子，比如我们希望在一个CEdit对象里，把所有的输入的字母都以大写的形式出现。我们只需要在PreTranslateMessage方法中判断message是否为WM_CHAR,如果是的话，把wParam(表示键值)由小写字母的值该为大写字母的值就实现了这个功能。

---- 继续上面的例子，根据我们对MFC消息机制的分析，我们很容易得到除了上面的方法，我们至少还可以在另外两个地方进行操作。

---- 一：在消息的处理方法里面即OnChar中，当然最后我们不再调用CEdit::OnChar(nChar,nRepCnt, nFlags)，而是直接调用DefWindowProc(WM_CHAR,nChar,MAKELPARAM(nRepCnt,nFlags))。因为从我们上面的分析可以知道CEdit::OnChar(nChar, nRepCnt, nFlags)实际上也就是对DefWindowProc方法的调用。

---- 二：我们可以直接重载DefWindowProc方法,对message类型等于WM_CHAR的，直接修改nChar的值即可。

4．小结
---- 通过对MFC类库的分析和了解，不仅能够使我们更好的使用MFC类库，同时，对于我们自己设计和实现框架和类，无疑也有相当大的帮助。