MFC消息路由

1.Command Routing(命令传递):当消息进来时,会有一个泵推动它前进.消息如何进来,以有泵函数如何推动,都是属于windows程序设计的范畴,

消息如果是从子类流向父类(纵向流动),那么事情再简单不过,整个message map消息映射表已规划出十分明确的路线.消息应该有横向流动的机会,MFC对于消息循环的规定是:

如果是一般的windows消息(WM_XXX),则一定是由派生类流向基类,没有旁流的可能.

如果是命令消息(WM_COMMAND),那就有奇特的路线了.

 

2.消息映射--窗口消息 

DefWindowProc-->AfxWndProc-->AfxCallWndProc-->pWnd->WindowProc

 

当消息到达pWnd->WindowProc()时即是调用 CWnd::WindowProc()接着调用 OnWndMsg(message, wParam, lParam, &LResult);

在OnWndMsg()函数里,分别判断当前消息是什么消息,分别是WM_COMMAND或者WM_NOTIFY及标准windows消息

如果是WM_COMMAND消息,又分为命令消息和来自窗口的控件通知消息,如果是命令消息直接调用OnCmdMsg(),此函数为虚函数,首先调用对话框本身的OnCmdMsg,在对话框本身的OnCmdMsg方法中会依次引起基类CDialog,CWnd和CCmdTarget的OnCmdMsg方法的调用,其中CCmdTarget的OnCmdMsg方法中主要搜索消息映射表,如果找到对应的处理函数,则调用_AfxDispatchCmdMsg方法执行消息映射表中的消息处理函数....如果是控件通知消息,则是判断传递进来的hWndCtrl!=NULL,成立则是控件通知消息,优先调用函数ReflectLastMsg(hWndCtrl)将这个消息反射给控件本身.

 

不管是WM_NOTIFY消息还是来自WM_COMMAND的来自控件的通知消息都会优先调用ReflectLastMsg(hWndCtrl)

 

再来看消息反射:在命令消息处理的WM_COMMAND和通知消息处理的WM_NOTIFY方法中优先调用ReflectLastMsg(),调用顺序为:pWnd->SendChildNotifyMsg(pResult)->return OnChildNotify->...._>return ReflectChildNotify()  此函数真正实现了消息反射,发送反射消息WM_COMMAND+WM_REFLECT_BASE或者WM_NOTIFY+WM_REFLECT_BASE最终此消息组全会被发送到OnCmdMsg,正如下面所说,这是一个虚函数,首先调用对话框本身的OnCmdMsg,在对话框本身的OnCmdMsg方法中依次调用引起基类的CDialog,CWnd和CCmdTarget类的OnCmdMsg方法(搜索消息映射表,直接调用消息映射函数);

 added by xiejl

MFC消息路由,布布扣,bubuko.com

时间: 2024-10-10 03:29:41

MFC消息路由的相关文章

MFC 消息映射(一)

---恢复内容开始--- 最近在看<深入浅出MFC>一书.消息映射流程图如下: 在此附加上不实用MFC Wizard 编写的简单MFC窗口程序,纯粹为学习消息映射.下载地址:Hello.06. MFC 程序入口: 1 int AFXAPI AfxWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,_In_ LPTSTR lpCmdLine, int nCmdShow) 2 { 3 4 CWinApp* pApp = AfxGetApp();

MFC消息映射机制

1 消息循环所在的函数 CWinApp::Run 2  消息类别 <1>Windows Messages WM_XX前缀开头,但是除了WM_COMMAND消息外. <2>Control Notifications 包含来自控件或者子窗口发给父窗口的 WM_COMMAND的通知消息. <3>Command Messages 菜单,工具栏按钮,快捷键 3 消息的发送和接受 CWinApp::Run函数接受消息并且将他们分派到合适的窗口,大多数命令消息时被发送到主框架窗口.接

MFC消息映射的原理:笔记

多态的实现机制有两种,一是通过查找绝对位置表,二是查找名称表:两者各有优缺点,那么为什么mfc的消息映射采用了第二种方法,而不是c++使用的第一种呢?因为在mfc的gui类库是一个庞大的继承体系,而里面的每个类有很多成员函数(只说消息反映相关的成员函数啊),而且在派生类中,需要改写的也比较少(我用来做练习的程序就是那么一两个,呵呵).那么用c++的虚函数的实现机制会导致什么问题呢?就是大量虚表的建立使得空间浪费掉很多. 嗯-怎么办呢?于是各大c++名库(比如QT,MFC,VCL-)在消息映射的实

MFC消息响应机制 q

MFC消息响应机制分析 1 引言微软公司提供的MFC基本类库(Microsoft Foundation Classes),是进行可视化编程时使用最为流行的一个类 库.MFC封装了大部分Windows API函数和Windows控件,使得程序的开发变得简单,极大的缩短了程序的开发 周期.MFC独创的Document/View框架结构,能够将管理数据的代码和显示数据的程序代码分开,并且设计了 一套方便的消息映射和命令传递机制,方便程序员的开发使用.其中消息映射机制本身比较庞大和复杂,对 它的分析和了

自制MFC消息响应定位器+原理分析

mfc里面有张消息映射表(MESSAGE_MAP),消息都是通过这张表来分发到相应函数里的. 这个是我自制的定位器,从vc6.0到现在的2013生成的mfc都可以用,全静态扫描并已处理动态基址. 下面来看MESSAGE_MAP结构: struct AFX_MSGMAP_ENTRY{        UINT nMessage;           UINT nCode;                 UINT nID;                     UINT nLastID;    

MFC 消息映射表和虚函数实现消息映射到底谁的效率高

深入浅出MFC对于虚函数实现方式的缺点,它指出:虚函数耗费大量内存,系统最终将被这些额外负担拖垮.    但是现在对于容量巨大的白菜价格的内存来说,这种额外负担是否已经过时了呢~?    书中提到,虚函数表中的每一个项目都是一个函数指针,价值4字节,如果基类的虚函数表有100项 (MFC里面的消息数量是否在这个数量级?),经过十层继承,开支散叶,总共需要耗费多少内存?    我粗略地算了下,不知道这种计算方法是否正确,4Byte*100项=400Byte.如果CCmdTarget中定义100个消

MFC 消息的分类

来源:孙鑫 c++ 第6集 MFC 消息的分类,布布扣,bubuko.com

深入探讨MFC消息循环和消息泵

首先,应该清楚MFC的消息循环(::GetMessage,::PeekMessage),消息泵(CWinThread::PumpMessage)和MFC的消息在窗口之间的路由是两件不同的事情.在MFC的应用程序中(应用程序类基于CWinThread继承),必须要有一个消息循环,他的作用是从应用程序的消息队列中读取消息,并把它派送出去(::DispatchMessage).而消息路由是指消息派送出去之后,系统(USER32.DLL)把消息投递到哪个窗口,以及以后消息在窗口之间的传递是怎样的.  消

c++对MFC消息映射机制和运行时类型识别的理解

对MFC消息映射机制和运行时类型识别的理解 对MFC消息映射机制的理解 MFC中派生于Cobject的每个类都有一个消息映射表,所有MFC窗口都有一个同样的窗口过程AfxWndProc(),AfxWndProc的参数列表中有一个是窗口句柄,在AfxWndProc函数中将句柄(HWND)转换成了窗口指针(CWnd*),通过这个窗口指针就可以获得该窗口的消息映射表.对于WM_COMMAND这类特殊消息,将依据C++的虚函数多态机制来决定调用哪个类的函数. 对MFC运行时类型识别的理解 定义一个CRu