常用MFC消息映射宏说明
1、DECLARE_MESSAGE_MAP:在头文件中声明源文件中所含有的消息映射
2, BEGIN_MESSAGE_MAP:标记源文件消息映射的开始
3,END_MESSAGE_MA:标记源文件消息映射的结束
4,ON_COMMAND:将特定命令的处理委派给类的一个成员函数
5,ON_CONTROL:映射一个函数到一个定制控制通知消息,该定制消息是
从一个控制发送父窗口的消息
6,ON_CONTROL_REFLECT:映射一个父窗口反射回控制的通知消息
7,ON_CONTROL_RANGE:将一个控制ID的范围映射到一个消息处理函数
8,ON_MESSAGE:将一个用户自定义消息映射到一消息处理函数
9,ON_NOTIFY:映射一个控制消息到一个函数
10,ON_NOTIFY_RANGE:映射一个控制ID范围内的控制消息到一个函数
11,ON_NOTIFY_EX:映射一个控制消息到一个函数,该成员函数返回FALSE或TRUE来表明通知是否应被传送到一下对象以进行其他反应
12,ON_NOTIFY_EX_RANGE:映射一个控制ID范围内的消息到一个函数,该成员函数返回FALSE或TRUE来表明通知是否应被传送到一下对象以进行其他反应
13,ON_NOTIFY_REFLECT:映射一个控制消息到一个函数,该消息将会被控制的父窗口反射回来
14,ON_REGISTERED_MESSAGE:映射一个惟一的消息到一个将处理该注册消息的函数上.该消息是由RegisterWindowMessage()函数注册的
15,ON_UPDATE_COMMAND_UI:映射一个函数来处理用户接口更新命令消息
16,ON_UPDATE_COMMAND_UI_RANGE:映射一个命令ID的范围到一个更新消息处理函数
--------------------------------------------------------------------------------------------------------------------------
消息反射的基础知识
1、消息反射解释:
父窗口将控制子窗口发给它的通知消息,首先反射回子窗口进行处理(即给控制子窗口一个机会,让控制子窗口处理此消息),这样通知消息就有机会能被子窗口自身进行处理。
2、MFC中引入消息反射的原因:
在Windows的消息处理中,控制子窗口的发给其父窗口的通知消息只能由其父窗口进行处理,这使得控制子窗口的自身能动性大大降低(你想,它连改变自己的背景色,处理一个自身滚动问题都要其父窗口来完成),为了解决这个问题,在MFC中引入了反射消息“Reflect Message”的概念,进行消息反射,可以使得控制子窗口能够自行处理与自身相关的一些消息,增强了封装性,从而提高了控制子窗口的可重用性。
消息反射的处理流程(不考虑OLE控制)
一、消息反射处理流程图:
1、父窗口收到控制子窗口发来的通知消息后,调用它的虚函数CWnd::OnNotify.
CWnd::OnNotify()主体部分:
{
if (ReflectLastMsg(hWndCtrl, pResult)) //此时,hWndCtrl,为发送窗口,即子窗口的窗口句柄
return TRUE; // 子窗口已处理了此消息
AFX_NOTIFY notify;
notify.pResult = pResult;
notify.pNMHDR = pNMHDR;
return OnCmdMsg(nID, MAKELONG(nCode, WM_NOTIFY), ?ify, NULL);
}
分析:首先,调用ReflectLastMsg(hCtrlChildWnd,...)给子窗口一个自身处理的机会,将消息反射给子窗口处理,函数返回TRUE,表明子窗口处理了此消息。反之,表示子窗口未处理此消息,此时,调用OnCmdMsg(...)由父窗口进行通常的处理。
2、ReflectLastMsg中:
主要是调用发送窗口的SendChildNotifyLastMsg(...)。
3、SendChildNotifyLastMsg 中:
调用发送窗口的虚函数OnChildNotify函数,进行处理。 如果没有处理,则调用ReflectChildNotify(...)函数进行标准的反射消息的消息映射处理。
我曾写过一篇文章对通知消息WM_NOTIFY进行分析,消息反射是MFC中对通知消息的处理方式,两者之间关系十分紧密,因此,我写了这篇文章,希望能够描绘出通知消息的完整印象。
消息反射的基础知识
1、消息反射解释:
父窗口将控制子窗口发给它的通知消息,首先反射回子窗口进行处理(即给控制子窗口一个机会,让控制子窗口处理此消息),这样通知消息就有机会能被子窗口自身进行处理。
2、MFC中引入消息反射的原因:
在Windows的消息处理中,控制子窗口的发给其父窗口的通知消息只能由其父窗口进行处理,这使得控制子窗口的自身能动性大大降低(你想,它连改变自己的背景色,处理一个自身滚动问题都要其父窗口来完成),为了解决这个问题,在MFC中引入了反射消息“Reflect Message”的概念,进行消息反射,可以使得控制子窗口能够自行处理与自身相关的一些消息,增强了封装性,从而提高了控制子窗口的可重用性。
消息反射的处理流程(不考虑OLE控制)
一、消息反射处理流程图:
1、父窗口收到控制子窗口发来的通知消息后,调用它的虚函数CWnd::OnNotify.
CWnd::OnNotify()主体部分:
{
if (ReflectLastMsg(hWndCtrl, pResult)) //此时,hWndCtrl,为发送窗口,即子窗口的窗口句柄
return TRUE; // 子窗口已处理了此消息
AFX_NOTIFY notify;
notify.pResult = pResult;
notify.pNMHDR = pNMHDR;
return OnCmdMsg(nID, MAKELONG(nCode, WM_NOTIFY), ¬ify, NULL);
}
分析:首先,调用ReflectLastMsg(hCtrlChildWnd,...)给子窗口一个自身处理的机会,将消息反射给子窗口处理,函数返回TRUE,表明子窗口处理了此消息。反之,表示子窗口未处理此消息,此时,调用OnCmdMsg(...)由父窗口进行通常的处理。
2、ReflectLastMsg中:
主要是调用发送窗口的SendChildNotifyLastMsg(...)。
3、SendChildNotifyLastMsg 中:
调用发送窗口的虚函数OnChildNotify函数,进行处理。 如果没有处理,则调用ReflectChildNotify(...)函数进行标准的反射消息的消息映射处理。
二、消息处理
方式1:
由上述处理流程可以看出来,子窗口要想自身处理此消息,重载子控件窗口的OnChildNotify虚拟函数应该是很容易想到的方式。
注意:MFC中对各个子控件窗口一般都已经重载了OnChildNotify函数,它对应调用类的虚函数进行处理,所以,你重载对应的虚函数即可,如下例:
BOOL CStatusBarCtrl::OnChildNotify(UINT message, WPARAM wParam, LPARAM lParam,LRESULT* pResult)
{
if (message != WM_DRAWITEM) //对应不同的控制,会有不同的有特殊处理要求的消息。
return CWnd::OnChildNotify(message, wParam, lParam, pResult);
...
...
DrawItem((LPDRAWITEMSTRUCT)lParam);
return TRUE;
}
virtual void DrawItem( LPDRAWITEMSTRUCT lpDrawItemStruct );
void CStatusBarCtrl::DrawItem(LPDRAWITEMSTRUCT)
{
ASSERT(FALSE); // must override for self draw status bars
}
你重载CSTatusBarCtrl类的DrawItem虚拟函数,即可实现对反射消息WM_DRAWITEM的处理。
方式2:
从方式1可以看出,如果你不在被重载的OnChildNotify中对消息进行处理,函数会调用CWnd::OnChildNotify,它调用ReflectChildNotify函数进行标准的处理。
1、增加反射消息的映射入口。
2、增加对应的消息处理函数。
注意:可以使用MFC的ClassWizard作上述动作,在ClassWizard中,可处理的反射消息以一个"="号以示区别。返回值为TRUE,表示控件窗口已处理此反射消息,为FALSE,表示控件子窗口未处理此反射消息。
结语:
消息反射不是很难的概念。它仅出现在MFC中;它的用意是方便控制子窗口的重用;对某些通知消息你可以重载对应的虚函数(WM_DRAWITEM...)进行处理;对其它你可以使用标准的消息反射映射进行处理。限于篇幅,一些细节问题,请阅读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",运行,看到了什么?呵呵。