系统理解Win32API和MFC.docx
- 文档编号:10618179
- 上传时间:2023-02-21
- 格式:DOCX
- 页数:17
- 大小:333.23KB
系统理解Win32API和MFC.docx
《系统理解Win32API和MFC.docx》由会员分享,可在线阅读,更多相关《系统理解Win32API和MFC.docx(17页珍藏版)》请在冰豆网上搜索。
系统理解Win32API和MFC
系统理解Win32API和MFC(上)
作者:
温昱
作者主页:
Win32API是微软的操作系统Windows提供给开发人员的编程接口,它决定了我们开发的Windows应用程序的能力。
MFC是微软为开发人员提供的类库,在某种意义上是对Win32API的封装。
本文试图从全局角度对Win32API和MFC进行理解──给出二者的概念模型。
本文使用UML描述概念模型。
Win32API本不是面向对象的,我用面向对象的观点去理解它,无非是想表达其全局。
本文参考了MSDN、相关书籍和网上的一些资料,在此一并感谢。
一、Win32API的概念模型
Win32API的object有3种:
userobj,gdiobj,kernelobj。
但是,如果一点不考虑OS本身的支持,就会在有些问题上疑惑,因此,我这里把“operationsystem负责将中断封装成message”加上。
1、userobj、gdiobj、kernelobj、system4者的关系
由于是kernelobj部分负责将另外3者联系起来,因此我们在下图中直接深入到kernelobj部分内部。
从图中看到,在内存中运行的,除了“负责将中断封装成message”的system支持部分,还有另外3类object:
kernelobj、userobj和gdiobj,每个obj都有一个句柄handle与之对应。
其中,gdiobj建立了待开发的Windows应用和外部输出设备的联系,kernelobj中的file建立了内存和永久存储设备的联系。
具体说,内存中的file从可以从硬盘上来,如果这个file是可执行文件,它将生成module,module运行起来就是process,process可以包含多条thread,而thread的运行映象最终还是来自于file。
thread是kernelobj中最重要的一个,因为消息队列就是thread拥有的,只有thread才能够接受message。
对gdiobj、urserobj和file的操作,也是发生在thread中的。
所以书都讲,process至少拥有一个thread。
2、展开“system负责将中断封装成message”部分
下面展开“system负责将中断封装成message”部分,尽早解除对“message到底是怎么形成的”的困惑。
3、展开“gdiobj”部分
开发人员可以通过gdiobj将app的信息反馈给User。
从图中看到,gdiobj有8种,其中7种为:
bmp,brush,pen,region,font,palette,path。
另一种比较特殊的是DC,它可以被理解为一种容器,程序员通过调用SelectPallette()将pallte放入容器,通过调用BeginPath()和EndPath()将path放入容器,其它5种gdiobj,是通过调用SelectObject()放入容器的。
DC又具体分为4种,其中DisplayDC就是最常用的用来支持我们“画Window”的DC。
另外,如果觉得不好理解,请参考composite设计模式。
4、展开userobj部分
4.1第1次迭代
window在Windows应用开发中占有重要地位。
从图中看到,window可分为3种:
desktop,top-levelwindow,childwindow。
所有window被OS组织成tree,有专门的数据结构来管理。
desktop就是树根,desktop的子节点是top-levelwindow,top-levelwindow的子节点是childwindow,childwindow仍然可以有子节点,同样归属于childwindow。
tree数据结构中还记录了4种重要信息,是4种指针:
parent指针、child指针、brother指针、owner指针。
这样,从任何一个window就能很容易地找到其它window了。
好了,暂且得到window=desktop+topLevel+child的结论,看看全局先。
毕竟,一步到位有时候并不好。
从图中看到,window确实占有重要地位。
从逻辑是讲,thread是window的拥有者;但是,所有window一起决定了屏幕看起来是上面样子,何况点击任何一个window都会使window得相互覆盖关系发生变化,对所用window进行统一管理是必须的,所以OS又不得不统一用windowtree来管理window,反映复杂的window关系。
每个window都必须有一个且只能有一个客户区,还可能有一个titlebar。
再来看看CreateWindow()函数的interfacespec透露了哪些信息。
从图中看到,CreateWindow()负责为window建立与窗口类的联系。
每个window都有一个窗口类与之对应,而一个窗口类可以对应多个window。
窗口类中记录了窗口函数和菜单等资源信息,而由file生成的module正是窗口函数和资源的老家。
4.2第2次迭代
考察消息种类。
从图中看到,每个message都是发送给某个window的。
注意,msg可由SYS代码产生,也可以由API函数产生。
进一步考察window,深入topLevel和child。
从图中看到,OVERLAPPED风格的window是top-levelwindow的一种,而另一种POPUP风格的window从本质上(行为上)是特殊的一种OVERLAPPED风格的window,虽然我们从coding的角度常常不这么认为。
还是不好,因为当我们调用CreateWindow()API函数时,明明感觉CHILD、OVERLAPPED、POPUP是“windowstyle”。
我再画一张图。
从图中看到,control必须是CHILD风格的,dialog必须是POPUP风格的,而一般性的window却可以是任意风格的。
4.3第3次迭代
总结userobj:
CreateDialog()函数示意:
从图中看到,CreateDialog()和CreateWindow()最大的区别就是,它有对话框模板支持方便地定制dialog界面。
注意,Dialog是特殊的window,窗口类它一定也是有的。
系统理解Win32API和MFC(下)
作者:
温昱
作者主页:
二、MFC的概念模型
前面我们研究了WIN32API的“领域模型”,对它有较全面的认识。
下面,对MFC概念模型的研究,我们把重点放在对appframework的研究上。
appframework中的message响应/传递机制是最重要的。
而Hook机制和Message响应/传递机制是密切相关的,后者以前者为基础。
1.Hook机制
也许有些程序员只知道hook机制可以编写很“牛”的应用,孰不知MFC本身也是依靠hook机制的。
从图中看到,每个hook拥有一个指针队列,每个指针指向一个称为的HookProc函数,HookProc将在合适的时机被OS调用执行。
hook是分不同种类的,其实正是hook的种类决定了它什么时机被OS调用执行。
提示,可以看一下“订阅-发布”设计模式以助理解。
2MFC中Message响应函数的安装
2.1回忆API中Message响应函数的安装
API中Message响应函数的安装,是由CreateWindow()实现的,它将window与一个windowClass联系起来,而后者中记录了Message响应函数的指针。
至于细节,看一下如何用Win32SDK或Win16SDK写程序就清楚了,其中DefWindowProc()是API函数,负责提供缺省的消息处理,所以,程序员只需要handle需要特殊处理的消息。
intWINAPIWinMain(HINSTANCEhInstance,HINSTANCEhPrevInstance,PSTRszCmdLine,intiCmdShow){NDCLASSwndclass;
2.2MFC中Message响应函数的安装
MFC中Message响应函数的安装显然更复杂,是在CWnd:
:
CreateEx()被调用时完成的,其中还用到了Hook机制。
我们可以先猜一下MFC是怎么做的。
MFC支持massagemap,使得对消息的响应份散到多个messagehandler函数中,而不是API开发是那种集中式的消息处理函数;所以,想必会有专门的代码来负责“检索messagemaptable然后调用messagehandle”。
messagemap是为了支持程序员处理他关心的特殊message的,那么缺省的message处理逻辑在哪里呢?
答案是MFC创建windowobj时是用的“预定义的窗口类”,自然已经有了缺省的message处理函数。
从图中看到,CWnd有成员变量m_pfnSuper、成员变量m_hWnd、成员函数OnWndMsg()和成员函数DefWindowProc()。
Wnd:
:
OnWndMsg()负责“在messagemap中定义的messagehandle”能否处理到来的message,如果处理了要返回true;CWnd:
:
DefWindowProc()负责对message缺省处理。
执行过程是,首先CWnd:
:
CreateEx()被调用,windowobj和windowclass被相应建立,此时windowclass的WindowProc字段存储了预定义的缺省处理函数的地址;由于有hook在监听窗口创建消息,所以注册的hookProc()会被调用执行,它将classWindow数据结构的WindowProc字段备份到CWnd:
:
m_pfnSuper,再用SetWindowLong()改写classWindow数据结构的WindowProc字段为:
:
AfxWndProc()的地址。
当任何一个message到达时,:
:
AfxWndProc()被调用,至于它的逻辑,聪明的你一定猜到了,先调用Wnd:
:
OnWndMsg(),如果返回值为false,还要调用CWnd:
:
DefWindowProc(),CWnd:
:
m_pfnSuper指向的缺省处理逻辑,也会在CWnd:
:
DefWindowProc()中被调用。
提示,上面其实有多态情况发生。
比如你可以在搜一下pWnd->WindowProc(nMsg,wParam,lParam);另外,OnWndMsg和DefWindowProc都是CWnd类的虚拟函数。
要是觉得不太好理解,最好在VC++里创建一个project实际跟踪一下,下面是我跟踪时调用栈映象的截图。
3.SubClass机制
从图中看到,SubClass机制以CWnd自身的m_pfnSuper为基础,和“MFC中Message响应函数的安装”很象。
4.framework中的主要相关类
framework中的主要相关类就是messageroute的候选人,正是它们的OnCmdMsg()共同完成了messageroute,形成了chainofresponsability模式。
5.framework中的chainofresponsability模式
下图是一个对象树,注意消息会在纵向和横向两个方向传播。
消息在纵向方向上的传递,是在“上溯父类的massgemap表”,MFC的messagemap完全是为了代替虚函数而采取的手段,而和messageroute无关。
消息在横向方向上的传递,才是messageroute,才是chainofresponsability模式,由多个相关类的OnCmdMsg()共同完成。
三、总结
从上面的讨论不难发现,MFC中用到了不少设计模式,如上面提到的chainofresponsability模式、composite模式和“订阅-发布”模式。
上面的讨论不仅有助于程序员全面掌握Win32API和MFC,对architect设计architecture也有很大帮助。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 系统 理解 Win32API MFC
![提示](https://static.bdocx.com/images/bang_tan.gif)