深入剖析WTL—WTL框架窗口分析1

WTL的基础是ATL。WTL的框架窗口是ATL窗口类的继承。因此,先介绍一下ATL对Windows窗口的封装。

由第一部分介绍的Windows应用程序可以知道创建窗口和窗口工作的逻辑是:

1 注册一个窗口类

2 创建该类窗口

3 显示和激活该窗口

4 窗口的消息处理逻辑在窗口函数中。该函数在注册窗口类时指定。

从上面的逻辑可以看出,要封装窗口主要需解决怎样封装窗口消息处理机制。

对于窗口消息处理机制的封装存在两个问题。

一是,为了使封装好的类的窗口函数对外是透明的,我们就会想到,要将窗口函数的消息转发到不同的类的实例。那么怎样将窗口函数中的消息转发给封装好的类的实例?因为所有封装好的类窗口的窗口函数只有一个,即一类窗口只有一个窗口函数。而我们希望的是将消息发送给某个类的实例。问题是窗口函数并不知道是哪个实例。它仅仅知道的是HWND,而不是类的实例的句柄。因此,必须有一种办法,能通过该HWND,找到与之相对应的类的实例。

二是,假设已经解决了上面的问题。那么怎样将消息传递给相应的类的实例。通常的办法是采用虚函数。将每个消息对应生成一个虚函数。这样,在窗口处理函数中,对于每个消息,都调用其对应的虚函数即可。

但这样,会有很多虚函数,使得类的虚函数表十分巨大。

为此,封装窗口就是要解决上面两个基本问题。对于第二个问题,ATL是通过只定义一个虚函数。然后,通过使用宏,来生成消息处理函数。对于第一个问题,ATL通过使用动态改变HWND参数方法来实现的。

ATL对窗口的封装



图示是ATL封装的类的继承关系图。从图中可以看到有两个最基本的类。一个是CWindow,另一个是CMessageMap。



CWindows是对Windows的窗口API的一个封装。它把一个Windows句柄封装了起来,并提供了对该句柄所代表的窗口的操作的API的封装。

CWindow的实例是C++语言中的一个对象。它与实际的Windows的窗口通过窗口句柄联系。创建一个CWindow的实例时并没有创建相应的Windows的窗口,必须调用CWindow.Create()来创建Windows窗口。也可以创建一个CWindow的实例,然后将它与已经存在的Windows窗口挂接起来。

CMessageMap仅仅定义了一个抽象虚函数——ProcessWindowMessage()。所有的包含消息处理机制的窗口都必须实现该函数。

通常使用ATL开发程序,都是从CWindowImplT类派生出来的。从类的继承图可以看出,该类具有一般窗口的操作功能和消息处理机制。

开发应用程序的时候,你必须在你的类中定义“消息映射”。

     
     BEGIN_MSG_MAP(CMainFrame)

	MESSAGE_HANDLER(WM_CREATE, OnCreate)

	COMMAND_ID_HANDLER(ID_APP_EXIT, OnFileExit)

	COMMAND_ID_HANDLER(ID_FILE_NEW, OnFileNew)

	COMMAND_ID_HANDLER(ID_VIEW_TOOLBAR, OnViewToolBar)

	COMMAND_ID_HANDLER(ID_VIEW_STATUS_BAR, OnViewStatusBar)

	COMMAND_ID_HANDLER(ID_APP_ABOUT, OnAppAbout)

     CHAIN_MSG_MAP(CUpdateUI<CMainFrame>)

     CHAIN_MSG_MAP(CFrameWindowImpl<CMainFrame>)

END_MSG_MAP()


我们知道一个窗口函数的通常结构就是许多的case语句。ATL通过使用宏,直接形成窗口函数的代码。

消息映射是用宏来实现的。通过定义消息映射和实现消息映射中的消息处理句柄,编译器在编译时,会为你生成你的窗口类的ProcessWindowMessage()。

消息映射宏包含消息处理宏和消息映射控制宏。

BEGIN_MSG_MAP()和END_MSG_MAP()



每个消息映射都由BEGIN_MSG_MAP()宏开始。我们看一下这个宏的定义:

     
     #define BEGIN_MSG_MAP(theClass) /

public: /

	BOOL ProcessWindowMessage(HWND hWnd, UINT uMsg, WPARAM wParam,

	LPARAM lParam, LRESULT& lResult, DWORD dwMsgMapID = 0) /

	{ /

		BOOL bHandled = TRUE; /

		hWnd; /

		uMsg; /

		wParam; /

		lParam; /

		lResult; /

		bHandled; /

		switch(dwMsgMapID) /

		{ /

		case 0:


一目了然,这是函数ProcessWindowMessage()的实现。与MFC的消息映射相比,ATL的是多么的简单。记住越是简单越吸引人。

需要注意的是dwMsgMapID。每个消息映射都有一个ID。后面会介绍为什么要用这个。

于是可以推断,消息处理宏应该是该函数的函数体中的某一部分。也可以断定END_MSG_MAP()应该定义该函数的函数结尾。

我们来验证一下:

     
     #define END_MSG_MAP() /

		break; /

	default: /

		ATLTRACE2(atlTraceWindowing, 0, _T("Invalid message map ID (%i)/n"), 

dwMsgMapID); /

		ATLASSERT(FALSE); /

		break; /

		} /

		return FALSE; /

	}



 

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
WTL 具有两面性,确实是这样的。它没有MFC的界面(GUI)类库那样功能强大,但是能够生成很小的可执行文件。如果你象我一样使用MFC进行界面编程,你会觉得MFC提供的界面控件封装使用起来非常舒服,更不用说MFC内置的消息处理机制。当然,如果你也象我一样不希望自己的程序仅仅因为使用了MFC的框架就增加几百K的大小的话,WTL就是你的选择。当然,我们还要克服一些障碍: ATL样式的模板类初看起来有点怪异 没有类向导的支持,所以要手工处理所有的消息映射。 MSDN没有正式的文档支持,你需要到处去收集有关的文档,甚至是查看WTL的源代码。 买不到参考书籍 没有微软的官方支持 ATL/WTL窗口与MFC的窗口有很大的不同,你所了解的有关MFC的知识并不全部适用与WTL。 从另一方面讲,WTL也有它自身的优势: 不需要学习或掌握复杂的文档/视图框架。 具有MFC的基本的界面特色,比如DDX/DDV和命令状态的自动更新功能(译者加:比如菜单的Check标记和Enable标记)。 增强了一些MFC的特性(比如更加易用的分隔窗口)。 可生成比静态链接的MFC程序更小的可执行文件(译者加:WTL的所有源代码都是静态链接到你的程序中的)。 你可以修正自己使用的WTL中的错误(BUG)而不会影响其他的应用程序(相比之下,如果你修正了有BUG的MFC/CRT动态库就可能会引起其它应用程序的崩溃。 如果你仍然需要使用MFC,MFC的窗口和ATL/WTL窗口可以“和平共处”。(例如我工作中的一个原型就使用了了MFC的 CFrameWnd,并在其内包含了WTL的CSplitterWindow,在CSplitterWindow中又使用了MFC的CDialogs -- 我并不是为了炫耀什么,只是修改了MFC的代码使之能够使用WTL的分割窗口,它比MFC的分割窗口好的多)。 在这一系列文章中,我将首先介绍ATL的窗口类,毕竟WTL是构建与ATL之上的一系列附加类,所以需要很好的了解ATL的窗口类。介绍完ATL之后我将介绍WTL的特性以并展示它是如何使界面编程变得轻而易举。 对第一章的简单介绍
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值