ChMFC六大关键技术仿真.pptVIP

Message Map(消息映射) 消息映射表-关联消息及其处理程序 消息直线上溯 消息横流 Message Map的宏实现 为了尽量降低对正常(一般)类声明和定义的影响,我们希望,最好能够像RTTI和Dynamic Creation一样,用一两个宏就完成这巨大蜘蛛网的建构. 首先定义一个数据结构 Message Map的宏实现(2) 然后我们定义一个宏: DECLAE_MESSAGE_MAP就相当于声明了这样一个数据结构: 这个数据结构的内容的填塞工作由三个宏完成: 其中AFXSig_end定义为: 例 请同学们写出上述宏展开后的代码 我们还可以定义各种类似ON_COMMAND这样的宏,把各式各样的消息与特定的处理程序关联起来.MFC里头就由名为ON_WM_PAINT,ON_WM_CREATE,ON_WM_SIZE…等等的宏 Frame6仿真程序(1) Frame6范例程序为每一CCmdTarget的每一派生类都产生类似前述的消息映射表.并且把各消息映射表的关联性架设起来,给予初值(每一映射表都只有ON_COMMAND一个项目).同时也设定了消息的终极镖靶CCmdTarget的映射表内容: 于是整个消息传递网就隐然形成了: Frame6仿真程序(2) 为了验证整个消息映射表,我必须在映射表中做点记号,等全部构建完成后,再一一追踪把记号显示出来.我将为每个类的消息映射表加上ON_COMMAND(Classid,0),这样就可把Classid嵌到映射表中作记号。 然后分别取其消息映射表，一路追踪下去，把每个消息映射表中类的记号打印出来： 在main函数中，我先产生四个对象（CMyWinApp,CMyFrameWnd,CMyDoc,CMyView）: Frame6仿真程序(3) 下面这个函数追踪并打印消息映射表中的classid记号： Frame6的执行结果： Command Routing(命令传递) 消息如果是从子类流向父类(纵向流动)，那么事情再简单不过，整个Message Map消息映射表已规划出十分明确的路线。但是，正如前面所述，消息不仅仅是纵向流动，消息还可以有横流的机会。MFC对消息循环的规定是： 如果是一般的Windows消息(WM_xxx),则一定是由派生类流向基类，没有旁流的可能。 如果是命令消息WM_COMMAND,那就有奇特的路线了： 命令消息接受者类型 处理次序 Command Routing仿真 不管前面规则是怎么定下来的，现在我要设计一个推动引擎，把它仿真出来。以下这些函数名称以及函数内容，完全仿真MFC内部.有些函数似乎赘余,那是因为我删掉了许多主题以外的操作.不把看似赘余的函数拿掉或合并,是为了留下MFC的足迹.此外,为了追踪调用过程,我在各函数的第一行输出一串识别文字. 全局函数AfxWndProc就是我所谓的推动引擎的起始点.它本来应该是在CWinThread::Run中被调用,但为了仿真目的,我在main中调用它,每调用一次便推送一个消息.这个函数在MFC中有四个参数,为了方便,我加上了第五个,用以表示谁是获得消息(成为循环的起点).例如: AfxWndProc(0,WM_CREATE,0,0,pMyFrame); 表示pMyFrame获得了一个WM_CREATE,而: AfxWndProc(0,WM_COMMAND,0,0,pMyView); 表示pMyView获得了一个WM_COMMAND 下面是消息的传递过程: pWnd-WindowProc究竟是调用哪一个函数? Command Routing仿真(2) 如果pWnd指向CMyFrameWnd对象,那么调用的是CFrameWnd::WindowProc,而因为CFrameWnd并没有改写WindowProc,所以调用的其实是CWnd::WindowProc. 如果pWnd指向CView对象,那么调用的是CView::WindowProc,而因为CView并没有改写WindowProc,所以调用的其实是CWnd::WindowProc. 虽然殊途同归,但意义上是不相同的. CWnd::WindowProc首先判断消息是否为WM_COMMAND.如果不是,事情最单纯,就把消息往父类推送,父类再往祖父类推送(直线上溯).每到一个类的消息映射表,原本应该比较AFX_MSGMAP_ENTY的每一个元素,比较成功就调用对用的处理程序.不过在这里我不作比较,只是把AFX_MSGMAP_ENTY中的类别识别码印出来,以表示“到此一游”: 小结 本章通过几个C++ Console程序,