山高月小，水落石出。
学VC是一段痛苦的经历。因为是自学，而且除了一点浅薄的C和C++基础，别无所有，开始的时候真是举步维艰。现在回想起来，走了很多的弯路，主要是开始时学习方法不对，不应该一开始就学习具体的技巧，而是应该先从大的框架上掌握MFC，获得大局观，这样才能更好地理解MFC的Framework概念。
MFC是Windows下程序设计的最流行的一个类库，但是该类库比较庞杂，尤其是它的消息映射机制，更是涉及到很多低层的东西，我在这里，对它的整个消息映射机制进行了初步的分析，希望能帮助你对MFC消息机制的理解。MFC消息机制很重要，属于框架范畴，所以理解它，掌握它，可以更好地驾驭MFC，所谓“知其然并知其所以然”也。
一．引言
MFC的框架结构大大方便了程序员的编程工作，但是为了更加有效、灵活的使用MFC编程，了解MFC的体系结构往往可以使编程工作事半功倍。它合理的封装了WIN32 API函数，并设计了一套方便的消息映射机制。但这套机制本身比较庞大和复杂，对它的分析和了解无疑有助于我们写出更为合理的高效的程序。这里我们简单的分析MFC的消息响应机制，以了解MFC是如何对Windows的消息加以封装，方便用户的开发。
二．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编程过程中，用户需要在窗口过程中分析消息的类型和跟消息一起的参数的含义，做不同的处理，也就是通过一个巨大的switch/case结构进行不同的消息处理，相对比较麻烦，而MFC把消息调用的过程给封装起来，使用户能够通过ClassWizard方便地使用和处理Windows的各种消息，甚至在弄清楚MFC的消息机制后，用户完全可以添加自己的消息命令以及消息响应函数。
三．MFC的消息实现机制
我们可以看到，在MFC的框架结构下，可以进行消息处理的类的头文件里面都会含有DECLARE_MESSAGE_MAP()宏,这里主要进行消息映射和消息处理函数的声明。可以进行消息处理的类的实现文件里一般都含有如下的结构。
BEGIN_MESSAGE_MAP(CInheritClass, CBaseClass)
//{{AFX_MSG_MAP(CInheritClass)
//}}AFX_MSG_MAP
END_MESSAGE_MAP()
这里主要进行消息映射的实现和消息处理函数的实现。
其中BEGIN_MESSAGE_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（）定义了两套宏，分别用于静态编译和动态编译。
相应的，END_MESSAGE_MAP()宏定义如下：
#define END_MESSAGE_MAP() \
{0, 0, 0, 0, AfxSig_end, (AFX_PMSG)0 } \
}; \
在这里粘贴宏的具体定义只是为了让你更好的理解，并没有必要将它们熟记。不要被它们的样子吓坏，宏做的工作始终只是替换，你拿两个具体的类名称替换掉BEGIN_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向导生成的MFC AppWizard（exe）应用程序通常会自动生成五个类：CDocument，CView，CApp，CMainFrame和CAbout。这些类除了CApp都是继承自CWnd，也就是说他们都有各自的消息循环队列和消息处理函数，所以按照SDK编程经验，Windows应该把消息发送到特定的类，由那些特定的类的消息处理函数进行处理，但是实际上所有MFC的窗口类都通过钩子函数_AfxCbtFilterHook截获消息，并且在钩子函数_AfxCbtFilterHook中把窗口过程设定为AfxWndProc。原来的窗口过程保存在成员变量m_pfnSuper中。这样做的原因，一是为了提高消息分发效率，而是为了能很好的兼容MFC2.4以及之前的版本。
所谓钩子函数hook，是Windows程序设计中的一种高级技术。通常消息都是停留在消息队列中等待被所隶属的窗口抓取，如果你设立了hook，就可以更早一步抓取消息，并且可以抓取不属于你的消息，送往你设定的一个所谓的“滤网函数（filter）”。
所以在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消息机制的分析，我们很容易得到除了上面的方法，我们至少还可以在另外两个地方进行操作。
1、在消息的处理方法里面即OnChar中，当然最后我们不再调用CEdit::OnChar(nChar, nRepCnt, nFlags)，而是直接调用DefWindowProc(WM_CHAR,nChar,MAKELPARAM (nRepCnt,nFlags))。因为从我们上面的分析可以知道CEdit::OnChar(nChar, nRepCnt, nFlags)实际上也就是对DefWindowProc方法的调用。
2、我们可以直接重载DefWindowProc方法,对message类型等于WM_CHAR的，直接修改nChar的值即可。
四．添加自定义消息
首先弄清楚两点：
（1）谁要发送这个消息（2）谁要接受这个消息。
用一个简单的例子来说明。对象A向B（也可以就是A到A）发送消息。
1、 发送消息
首先在A的头文件中定义这个消息：
#define WM_USERMESSAGE WM_USER+30
所有自定义消息都是以WM_USER消息为基础加上一个任意的自然数来表示的。A是向外发送消息的对象，因此在A的某个方法（函数）里就会调用用来发消息的函数B::SendMessage()/B::PostMessage()，因为是B接受消息，因此是如上的形式。
2、 接受消息
对象接受一个消息，应该有三部分：在头文件中有该消息的处理函数的原型；在实现文件中有接受消息映射的宏；以及该消息的处理函数的具体实现。
2.1、头文件中加上自定义消息的处理函数原型
在DECLARE_MESSAGE_MAP（）语句之前，一对AFX_MSG之间加上如下形式的函数原型：
afx_msg LRESULT OnProcName( WPARAM wParam, LPARAM lParam )； 对Win32来说，wParam, lParam是传递消息最常用的手段。
2.2、在实现文件中加上接受消息映射的宏
在cpp文件里，BEGIN_MESSAGE_MAP语句之后，在一对AFX_MSG_MAP之间，增加 如下形式的代码：
ON_MESSAGE(WM_USERMESSAGE, OnProcName)
上面是不用分号结尾的。
2.3、在实现文件中给出消息处理函数的具体实现。
五．小结
通过对MFC类库的分析和了解，不仅能够使我们更好的使用MFC类库，同时，对于我们自己设计和实现框架和类，无疑也有相当大的帮助。
转自：http://blogold.chinaunix.net/u1/49660/showart_406287.html