全面解读WM_NOTIFY & 消息反射

原文：http://blog.csdn.net/hustli/category/12732.aspx

摘要：控件通知消息有很多种，但是有一种是很常用，但是又不是很容易掌握的，那就是WM_NOTIFY，我试着对此做一下比较全面的论述，有不对的地方，还希望各路大虾批评指正。

控件通知消息
在《深度解析VC中的消息（上）》中，我们提到了消息的分类有3种：窗口消息、命令消息和控件通知消息，我们这里要谈的是最后一种：控件通知消息。
控件通知消息，是指这样一种消息，一个窗口内的子控件发生了一些事情，需要通知父窗口。通知消息只适用于标准的窗口控件如按钮、列表框、组合框、编辑框，以及Windows公共控件如树状视图、列表视图等。例如，单击或双击一个控件、在控件中选择部分文本、操作控件的滚动条都会产生通知消息。 她类似于命令消息，当用户与控件窗口交互时，那么控件通知消息就会从控件窗口发送到它的主窗口。但是这种消息的存在并不是为了处理用户命令，而是为了让主窗口能够改变控件，例如加载、显示数据。例如按下一个按钮，他向父窗口发送的消息也可以看作是一个控件通知消息；单击鼠标所产生的消息可以由主窗口直接处理，然后交给控件窗口处理。
控件通知消息主要由窗口类即直接或间接由CWND类派生类处理。

控件通知格式
控件通知经历了一个演变过程，因而SendMessage( )的变量Message、wParam和lParam有三种格式。
第一控件通知格式
第一控件通知格式只是窗口消息的子集。它的特征格式如下：WM_XXXX。它主要来自下面的3种消息类型：
(1)表示一个控件窗口要么已经被创建或销毁，要么已经被鼠标单击的消息：WM_PARENTNOTIFY；
(2)发送到父窗口，用来绘制自身窗口的消息，例如： WM_CTLCOLOR、WM_DRAWITEM、WM_MEASUREITEM、WM_DELETEITEM、WM_CHARTOITEM、WM_VKTOITEM、WM_COMMAND和WM_COMPAREITEM
(3)有滚动调控件发送，通知父窗口滚动窗口的消息：WM_VSCROLL和WM_HSCROLL
第二控件通知格式
第二控件通知格式与命令消息共享，它的特征格式如下：WM_COMMAND。
在WM_COMMAND中，lParam用来区分是命令消息还是控件通知消息：如果lParam为NULL，则这是个命令消息，否则lParam里面放的必然就是控件的句柄，是一个控件通知消息。对于wParam则是低位放的是控件ID，高位放的是相应的消息事件。
第三控件通知格式
这个才真正涉及到我们要讲的内容，同时他也是最为灵活的一种格式。它的特征格式如下：WM_NOTIFY。
在WM_NOTIFY中，lParam中放的是一个称为NMHDR结构的指针。在wParam中放的则是控件的ID。

NMHDR结构的由来
NMHDR结构是很值得一提的，该结构包括有关制作该通知的控件的任何内容，而不受空间和类型的限制，他的来历也是很有意思的。
在最初的windows3.x中，根本就不存在什么WM_NOTIFY，控件通知它们父窗口，如鼠标点击,控件背景绘制事件，通过发送一个消息到父窗口。简单的通知仅发送一个WM_COMMAND消息，包含一个通知码和一个在wParam中的控件ID及一个在lPraram中的控件句柄。这样一来，wParam和lParam就都被填充了，没有额外的空间来传递一些其它的消息，例如鼠标按下的位置和时间。
为了克服这个困难，windows3.x就提出了一个比较低级的解决策略，那就是给一些消息添加一些附加消息，最为明显的就是控件自画用到的DRAWITEMSTRUCT。不知道大家对这个结构熟悉不，不过，如果你是老手，你应该非常清楚这个结构，这个结构包含了9个内容，几乎你需要控制的信息都给你提供了。为什么说它比较低级呢？因为不同的消息附加的内容不同，结果就是一盘散沙，非常混乱。
在win32中，MS又提出了一个更好的解决方案：引进NMHDR结构。这个结构的引进就是消息统一起来，利用它可以传递复杂的信息。这个结构的布局如下：
NMHDR
{
HWnd hWndFrom ; 相当于原WM_COMMAND传递方式的lParam
UINT idFrom ; 相当于原WM_COMMAND传递方式的wParam（low-order）
UINT code ; 相当于原WM_COMMAND传递方式的Notify Code(wParam"s high-order)
}；
对于这个结构的应用于WM_NOTIFY信息结构，结果WM_NOTIFY就变成了：
A、无附加信息。结构变得很简单，就是一个NMHDR结构。
B、有附加信息。定义一个大的结构，它的第一个元素就是NMHDR结构，它的后面放置附加信息。

WM_NOTIFY结构的好处
除了上面我们所说的好处外，WN_NOTIFY还有自己的独特的好处：
由于在大结构中，第一个成员为NMHDR,这样一来，我们就可以利用指向NMHDR的指针来传递结构地址，根据指针的特性，无论消息有没有附加信息，这个指针都适用，也能够很方便的进行强制转换。

分析ON_NOTIFY
　 类向导可以创建ON_NOTIFY消息映射入口并提供一个处理函数的框架，来处理 WM_NOTIFY类型的消息。ON_NOTIFY消息映射宏有如下语法.
　　　ON_NOTIFY(wNotifyCode,id,memberFxn)
　　其中：wNotifyCode:要处理的通知消息通知码。比如上面我们提到的LVN_KEYDOWN；Id:控件标识ID；MemberFxn:处理此消息的成员函数。
　　此成员函数有如下的原型声明:
　　　afx_msg void memberFxn( NMHDR * pNotifyStruct, LRESULT * result);
　　比如:假设你想成员函数OnKeydownList1处理ClistCtrl(标识ID=IDC_LIST1）的 LVN_KEYDOWN消息,你可以使用类向导添加如下的消息映射:
　　　ON_NOTIFY( LVN_KEYDOWN, IDC_LIST1, OnKeydownList1 )
　　在上面的例子中,类向导提供如下函数:
　　　void CMessageReflectionDlg::OnKeydownList1(NMHDR* pNMHDR, LRESULT* pResult)
　　　　{
　　　　　LV_KEYDOWN* pLVKey= (LV_KEYDOWN*)pNMHDR;
　　　　　*pResult = 0;
　　　　 }
　　这时类向导提供了一个适当类型的指针，你既可以通过pNMHDR，也可以通过 pLVKey来访问这个通知结构。

ON_NOTIFY_RANGE
　　有时我们可能需要为一组控件处理相同的WM_NOTIFY消息。这时需要使用ON_NOTIFY_RANGE而不是ON_NOTIFY。不过，很不幸的是，VC6的ClassWizard并不支持这个消息，所以我们必须手工添加。方法和一般的手工添加的消息一样，不过需要注意的是：
(1)当你使用 ON_NOTIFY_RANGE时,你需要指定控件的ID范围.其消息映射入口及函数原型如下:
　　　 ON_NOTIFY_RANGE( wNotifyCode, id, idLast, memberFxn )
　　　　其中：wNotifyCode:消息通知码.比如:LVN_KEYDOWN。id: 第一控件的标识ID。
　　　　　idLast:最后一个控件的标识ID。（标识值一定要连续）memberFxn: 消息处理函数。
　　(2)成员函数必须有如下原型申明：afx_msg void memberFxn( UINT id, NMHDR * pNotifyStruct, LRESULT * result );

结束语：
WM_NOTIFY是一个很值得思考的结构，另外他和Reflect Message联系非常紧密，我们接下来就要讨论一下反射消息。


摘要：在前面我们分析了控件通知消息WM_NOTIFY，和WM_NOTIFY紧密联系的还有一个MFC新特性：消息反射。本文中，我想就这个问题作一个全面的论述，如果有错误，还望各路大虾批评指正。

什么是消息反射？
在windows里面，子控件经常向父控件发送消息，例如很多子控件要绘制自己的背景，就可能向父窗口发送消息WM_CTLCOLOR。对于从子控件发来的消息，父控件有可能在处理之前，把消息返还给子控件处理，这样消息看起来就想是从父窗口反射回来一样，故此得名：消息反射。

消息反射的由来
在windows和MFC4.0版本一下，父窗口（通常是一个对话框）会对这些消息进行处理，换句话说，自控件的这些消息处理必须在父窗口类体内，每当我们添加子控件的时候，就要在父窗口类中复制这些代码，我们可以想象这是多么的复杂，代码是多么的臃肿！
我们可以想象，如果这些消息都让父窗口类去做，父窗口就成了一个万能的神，一个臃肿不堪的代码机，无论如何消息的处理都集中在父窗口类中，会使父窗口繁重无比，但是子控件却无事可做，并且代码也无法重用，这对于一个程序员来讲是多么痛苦的一件事？！
在老版本的MFC中，设计者也意识到了这个问题，他们对一些消息采用了虚拟机制，例如：WM_DRAWITEM，这样子控件就有机会控制自己的动作，代码的可重用性有了一定的提高，但是这还没有达到大部分人的要求，所以在高版本的MFC中，提出了一种更方便的机制：消息反射。
通过消息反射机制，子控件窗口便能够自行处理与自身相关的一些消息，增强了封装性，同时也提高了子控件窗口类的可重用性。不过需要注意的是：消息反射是MFC实现的，不是windows实现的；要让你的消息反射机制工作，你得类必须从CWnd类派生。

Message-Map中的处理
如果想要处理消息反射，必须了解相应的Message-Map宏和函数原型。一般来讲，Message-Map是有一定的规律的，通常她在消息的前面加上一个ON_ ，然后再消息的最后加上 _REFLECT。例如我们前面提到的WM_CTLCOLOR 经过处理后变成了ON_WM_CTLCOLOR_REFLECT；WM_MEASUREITEM则变成了ON_WM_MEASUREITEM_REFLECT。
凡事总会有例外，这里也是这样，这里面有3个例外：
(1) WM_COMMAND 转换成 ON_CONTROL_REFLECT；
(2) WM_NOTIFY 转换成 ON_NOTIFY_REFLECT；
(3) ON_UPDATE_COMMAND_UI 转换成 ON_UPDATE_COMMAND_UI_REFLECT；
对于函数原型，也必须是以 afx_msg 开头。

利用ClassWizard添加消息反射
(1)在ClassWizard中，打开选择项Message Maps；
(2)在下拉列表Class name中选择你要控制的类；
(3)在Object IDs中，选中相应的类名；
(4)在Messages一栏中找到前面带有=标记的消息，那就是反射消息；
(5)双击鼠标或者单击添加按钮，然后OK!

消息处理的过程
　　(1)子窗口向父窗口发送通知消息，激发父窗口去调用它的虚函数CWnd::OnNotify。大致的结构如下
BOOL CWnd::OnNotify(WPARAM wParam, LPARAM lParam, LRESULT* pResult)
{
if (ReflectLastMsg(hWndCtrl, pResult)) file://hWndCtrl,为发送窗口
return TRUE; file://如果子窗口已处理了此消息，返回
AFX_NOTIFY notify;
notify.pResult = pResult;
notify.pNMHDR = pNMHDR;
return OnCmdMsg(nID, MAKELONG(nCode, WM_NOTIFY)? notify:NULL);
}
　　(2)ReflectLastMsg声明如下：static BOOL PASCAL ReflectLastMsg(HWND hWndChild, LRESULT* pResult = NULL);
　　 它的主要任务就是调用发送窗口的SendChildNotifyLastMsg。
　　(3)SendChildNotifyLastMsg声明如下：BOOL SendChildNotifyLastMsg(LRESULT* pResult = NULL);
　　 调用发送窗口的虚函数OnChildNotify函数，进行处理。 如果发送窗口没有进行重载处理，则调用ReflectChildNotify(...)函数进行标准的反射消息的消息映射处理。

使用的一个例子
这里面我们举一个简单的例子，希望大家能够更清晰的掌握消息反射机制。
(1)创建一个基于对话框的工程。
(2)利用向导创建一个新的类：CMyEdit，基类是CEdit。
(3)在CMyEdit头文件中加入3个成员变量：
COLORREF m_clrText ;
COLORREF m_clrBkgnd ;
CBrush m_brBkgnd;
(4)利用向导在其中加入WM_CTLCOLOR（看到了么，前面是不是有一个=？），并且将它的函数体改为：
HBRUSH CMyEdit::CtlColor(CDC* pDC, UINT nCtlColor)
{
pDC->SetTextColor( m_clrText ); // text
pDC->SetBkColor( m_clrBkgnd ); // text bkgnd
return m_brBkgnd; // ctl bkgnd
}
同时我们在.cpp文件中会看到ON_WM_CTLCOLOR_REFLECT()，这就是我们所说的经过处理的宏，是不是很符合规则？
(5)在对话框中加入一个Edit，增加一个关联的变量，选择Control属性，类别为CMyEdit。
(6)在对话框.cpp文件中加入#include "MyEdit.h"，运行，看到了什么？呵呵。