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类库，同时，对于我们自己设计和实现框架和类，无疑也有相当大的帮助。
二．MFC的消息映射机制
MFC的设计者们在设计MFC时，紧紧把握一个目标，那就是尽可能使得MFC的代码要小，速度尽可能快。为了这个目标，他们使用了许多技巧，其中很多技巧体现在宏的运用上，实现MFC的消息映射的机制就是其中之一。
同MFC消息映射机制有关的宏有下面几个：
DECLARE_MESSAGE_MAP()宏
BEGIN_MESSAGE_MAP(theClass, baseClass)和END_MESSAGE_MAP()宏
弄懂MFC消息映射机制的最好办法是将找出一个具体的实例，将这些宏展开，并找出相关的数据结构。
DECLARE_MESSAGE_MAP()
DECLARE_MESSAGE_MAP()宏的定义如下：
#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; \
从上面的定义可以看出，DECLARE_MESSAGE_MAP()作下面三件事：
定义一个长度不定的静态数组变量_messageEntries[]；
定义一个静态变量messageMap；
定义一个虚拟函数GetMessageMap()；
在DECLARE_MESSAGE_MAP()宏中，涉及到MFC中两个对外不公开的数据结构
AFX_MSGMAP_ENTRY和AFX_MSGMAP。为了弄清楚消息映射，有必要考察一下这两个数据结构的定义。
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_ENTRY结构实际上定义了消息和处理此消息的动作之间的映射关系。因此静态数组变量_messageEntries[]实际上定义了一张表，表中的每一项指定了相应的对象所要处理的消息和处理此消息的函数的对应关系，因而这张表也称为消息映射表。再看看AFX_MSGMAP的定义。
（2）AFX_MSGMAP的定义
struct AFX_MSGMAP
{
const AFX_MSGMAP* pBaseMap;
const AFX_MSGMAP_ENTRY* lpEntries;
};
不难看出，AFX_MSGMAP定义了一单向链表，链表中每一项的值是一指向消息映射表的指针（实际上就是_messageEntries的值）。通过这个链表，使得在某个类中调用基类的的消息处理函数很容易，因此，“父类的消息处理函数是子类的缺省消息处理函数”就“顺理成章”了。在后面的“MFC窗口的消息处理”一节中会对此作详细的讲解。
由上述可见，在类的头文件中主要定义了两个数据结构：消息映射表和单向链表。（孙建东总结）
BEGIN_MESSAGE_MAP()和END_MESSAGE_MAP()
它们的定义如下：
#define BEGIN_MESSAGE_MAP(theClass, baseClass) \
const AFX_MSGMAP* theClass::GetMessageMap() const \
{ return &theClass::messageMap; } \
AFX_COMDAT AFX_DATADEF const AFX_MSGMAP theClass::messageMap = \
{ &baseClass::messageMap, &theClass::_messageEntries[0] }; \
AFX_COMDAT const AFX_MSGMAP_ENTRY theClass::_messageEntries[] = \
{ \
#define END_MESSAGE_MAP() \
{0, 0, 0, 0, AfxSig_end, (AFX_PMSG)0 } \
}; \
对应BEGIN_MESSAGE_MAP()的定义可能不是一下子就看得明白，不过不要紧，举一例子就很清楚了。对于BEGIN_MESSAGE_MAP(CView, CWnd)，VC预编译器将其展开成下面的形式：
const AFX_MSGMAP* CView::GetMessageMap() const
{
return &CView::messageMap;
}
AFX_COMDAT AFX_DATADEF const AFX_MSGMAP CView::messageMap =
{
&CWnd::messageMap,
&CView::_messageEntries[0]
};
AFX_COMDAT const AFX_MSGMAP_ENTRY CView::_messageEntries[] =
{
至于END_MESSAGE_MAP()则不过定义了一个表示映射表结束的标志项，我想大家对于这种简单的技巧应该是很熟悉的，无需多述。
到此为止，我想大家也已经想到了象ON_COMMAND这样的宏的具体作用了，不错它们只不过定义了一种类型的消息映射项，看看ON_COMMAND的定义：
#define ON_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。
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 )
1.MFC中的消息分为三种
2.为什么要消息路由？什么叫消息路由？
如果像SDK那样，我们的程序只有一个窗口，一个窗口函数，那哪还有消息路由呢？所有的消息都有一个窗口函数来处理了。至所以要消息路由，是因为MFC程序中有CMyView,CMyDoc,CMyFrameWnd,CMyApp等，MFC框架要做的工作是给用户提供一个机会，让用户可以选择这些类当中的任意一个来处理我们的命令消息。
注意，消息路由主要是针对上述的第二类消息（命令消息）。对于第一类窗口消息，其消息的接收者是确定的，不需要路由。比如：对于WM_CREATE消息，处理这个消息的类就是产生这个消息的窗口，你不可能让CMyDoc,CMyFrame，CMyApp去处理CView的WM_CREATE消息,那根本不符合逻辑，MFC框架当然也不会让你那么做。而对于来自菜单，工具栏的命令消息，用户是有选择权的，用户可以选择其接收者为View,Doc,App,Frame等当中的任意一个。下面就详细说一下命令消息的路由过程，主要通过分析MFC源代码。
3.首先说一下函数的调用顺序.所有的三类消息初始都被送入一个全局函数AfxWndProc,
之后是pWnd->WindowProc,pWnd->OnWndMsg,在OnWndMsg()中这三类消息分道扬镳了，其中第一类消息由OnWndMsg自己处理，第二类交给了OnCommand（），第三类交给了OnNotify(),下面主要说第二类的处理过程：
AfxWndProc()
注意：WindowProc和OnWndMsg这两个函数实际只有CWnd类中才有，在其它类中并没有重写这两个虚函数，所以我们调用的是CWnd::WindowProc()和CWnd::OnWndMsg()，但要注意：它们的this指针是指向我们的程序中的具体类对象（这是下面运用多态的前提）。
下面以多文档为例，解析其对第二类消息的处理过程:
AfxWndProc-->CWnd::WindProc()-->CWnd::OnWndMsg()（此处三类消息分道扬镳）－->CMyFrameWnd::OnCommand(不存在)-->CMDIFrameWnd::OnCommand(),
下面是CMDIFrameWnd::OnCommand()的源代码：
父框架窗口是先认子框架窗口来处理，如果其不处理，再自己处理。
那子框架窗口又是如何处理的呢？由于子框架窗口没有重写上面的WindowProc,OnWndMsg,OnCommand,所以最终调用的是其父类CFrameWnd::OnCommand（）.注意：这里虽然调用了两次CFrameWnd::OnCommand,
但其this指针却不同，一个this指针指向的是CMyChildWnd,一个指向的是CFrameWnd.下面是CFrameWnd::OnCommand（）源代码:
子框架窗口是先让CMyView处理，如果其不处理，再自己处理（CWnd::OnCmdMsg),否则，再App处理.
那CMyView又是如何处理的呢，下面是其CView::OnCmdMsg()源代码
{
}
CMyView是先让自己处理，如果其不处理，再让其对应的Document处理，而Document是先自己处理，如果自己不处理，现让CDocTemplate处理（此处这一代码就不在写出，因为通常不会让文档模板处理）
所谓自己处理，就是调用CCmdTarget::OnCmdMsg(),CWnd并没有重写这个函数，调用CWnd::OnCmdMsg就是调用CCmdTarget::OnCmdMsg(),这个函数的主要干的事情就是：调用GetMessageMap()这个虚函数，获得我们的子类的消息映射表，然后把该消息和此消息映射表对照，看其是否有对应的消息响应函数。如果没有，再看其父类是否有,父类也没有，就返回false,让其它的类来处理了。
注意：这里App先于MainFrame,在有些书上说成是App最后（特纠正）
对于单文档，那就比这简单了，
CMyView-->CMyDoc-->CSingleDocTemplate-->CMyFrame-->CMyApp
注意：在单文档中CMyApp是最后，因为这里的主框架实际占据的是MDI中子框架的位置。
436
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
