In Windows 3.x ---> WM_COMMAND, wparam->控件ID,lparam->控件句柄
但这种消息携带的消息太少,后来就创建另外一些消息:
WM_CTLCOLOR, WM_VSCROLL, WM_HSCROLL,WM_DRAWITEM,WM_MEASUREITEM,WM_COMPAREITEM,WM_DELETEITEM,WM_CHARTOITEM,WM_VKEYTOITEM, and so on.
再后来,直接用WM_NOITFY消息了,wparam->控件ID,lparam->一个NMHDR结构体或包含NMHDR的结构体的指针,可以携带任意量的额外数据
消息反射:
最初MFC使控件发送消息到父窗口,使父窗口来绘制子控件,比如WM_CTLCOLOR,但这样的话每个使用子控件的地方都要重复相同的代码,后来就产生了消息反射,
使子控件能够自己处理消息,这时,早起的处理方式和现在的消息反射方式都是可以的,甚至可以在使用的时候在这两个地方都处理,这样,子控件就可以不依赖父窗口处理消息了,但是这种机制的实现靠的是MFC,所以父窗口必须从CWd继承。
早起的老版本通过消息的虚函数也提供了一些类似的方法来实现这些功能,比如WM_DRAWITEM消息的处理。
如果在处理了消息,将会覆盖掉子控件中的消息反射,比如,如果处理了WM_CTLCOLOR消息,任何反射消息都会被覆盖。
如果子类实现了ON_NOTIFY_REFLECT(). 如果返回TRUE,父窗口将不会处理相应消息,如果返回FALSE,父窗口将能够处理消息,
注意:反射消息总是比通知消息先处理
When a WM_NOTIFY message is sent, the control is offered the first chance to handle it. If any other reflected message is sent, the parent window has the first chance to handle it and the control will receive the reflected message.
WM_LBUTTONDOWN和WM_LBUTTONUP属于标准的窗口消息,这类消息的路由是从派生类向父类传递
也就是说你鼠标单击产生的消息WM_LBUTTONDOWN和WM_LBUTTONUP实际是流向了CListCtrl了
你如果想你的列表响应WM_LBUTTONDOWN和WM_LBUTTONUP你就得给你的列表框派生一个子类
并为你的列表关联一个派生类类型的对象变量即可
NM_CLICK属于通告消息,它的传播路径是先传给父窗口,父窗口首先不会处理此消息,它会将此消息反射给发出此消息的子控件,如果子控件没有处理则交由父窗口处理
To convert from the message name to the reflected macro name, prepend ON_ and append _REFLECT. For example, WM_CTLCOLOR becomesON_WM_CTLCOLOR_REFLECT. (To see which messages can be reflected, do the opposite conversion on the macro entries in the table below.)
The three exceptions to the rule above are as follows:
Scroll Bar Issues
When handling scroll-message (WM_HSCROLL/OnHScroll and/orWM_VSCROLL/OnVScroll), you should try to write the handler code so it does not rely on where the scroll bar message came from. This is not only a general Windows issue, since scroll messages can come from true scroll bar controls or fromWS_HSCROLL/WS_VSCROLL scroll bars which are not scroll bar controls.