在windows平台,相比MFC,我更喜欢WTL,因其简洁漂亮。所以陆续花了一年的时间学习之,这里总结一下(在学习Wtl/Atl之前,最好是对WinApi编程有一定的了解)。
安装
Wtl主页 http://sourceforge.net/projects/wtl/ ,整个库就是一堆.h文件,官方没有提供Installer,下载后解压到某个目录即可。
如果需要在VS中使用“工作导向”,可以点击Appwiz目录下的对应js文件来安装之。虽然没有直接对VS2010的支持,不过拿VS2008的改改即可,详情Google下。
为了在VS中使用Wtl,可以将include目录添加到全局Include Path。不过如果仅仅希望对单个项目有效,则在添加C++ Include Path的同时,可能还需要添加资源的Include Path。如果不希望以来第三方的库,可以直接将源码放在项目内。
Atl
学习Wtl,不可能跳过Atl,Wtl底层就是使用Atl。关于Atl这里就几个点讲一下:
- ATL-style 模板
- 窗口创建和初始化
- Thunk技术
- 回调和消息绑定
ATL-style 模板
template <class T>
class B1
{
public:
void SayHi()
{
T* pT = static_cast<T*>(this);
pT->PrintClassName();
}
protected:
void PrintClassName() { cout << "This is B1"; }
};
class D1 : public B1<D1>
{
// No overridden functions at all
};
使用这个模板形式有几个好处:
- 不需要使用指向对象的指针。
- 节省内存,因为不需要虚函数表。
- 因为没有虚函数表所以不会发生在运行时调用空指针指向的虚函数。
- 所有的函数调用在编译时确定(译者加:区别于C++的虚函数机制使用的动态编连),有利于编译程序对代码的优化。
http://www.winmsg.com/wtl/Part1.htm
窗口创建和初始化
有个哥们就这个流程分析了一下,地址在这里 http://blog.csdn.net/jznsmail/archive/2004/12/01/200947.aspx 。
在Windows下,任何窗口创建都是通过CreateWindowEx或者CreateWindow函数来实现之,Wtl/Atl也不例外,(不过Wtl和Atl的流程略有不同)。详细的流程见上面链接,这里就几个重点说一下(不仅仅是Atl,也包括Wtl的内容)。
对于Windows窗口,需要派生自CFrameWindowImpl类,创建和初始化窗口就在该类的CreateEx函数实现。通过前面讲到的“ATL-style 模板”,CreateEx会调用Create函数,CFrameWindowImpl提供了默认的Create实现,不过也可以在派生类中定制。在CFrameWindowImpl类成员函数Create中会首先注册窗口,然后才创建之。
在CFrameWindowImpl的Create函数中会通过CFrameWindowImplBase的成员函数Create创建实际的窗口,使用API函数CreateWindowEx。
在CFrameWindowImpl的Create函数中会调用CFrameWndClassInfo类成员函数Register注册窗口,注册用到的信息通过DECLARE_FRAME_WND_CLASS或DECLARE_FRAME_WND_CLASS_EX宏来指定。在这两个宏中会指定静态成员函数StartWindowProc 作为窗口回调。这个静态成员在CWindowImplBaseT类中定义。在这个静态成员中使用了下面提到的Thunk技术动态地修改回调参数,同时将回调重置为该类的另一个静态成员WindowProc(见API函数SetWindowLongPtr和属性GWLP_WNDPROC)。
以上提到的是Wtl流程的一个简单概述,对于普通窗口(控件),我们一般使用Atl的那一套而非Wtl。
对于控件,一般派生自CWindowImpl窗口,窗口工作在该类的成员函数Create中完成。注册窗口的信息使用DECLARE_WND_CLASS或DECLARE_WND_CLASS_EX宏。具体的注册操作在ATL::CWndClassInfo类的成员函数Register中完成,窗口的创建在CWindowImplBaseT类的成员函数Create中完成。
Thunk技术
对于Windows API,从系统的消息回调出来的消息唯一的标识符就是HWND句柄,而当前随便一个UI程序都有相当之多的控件,所以必须要有一种行之有效的方法来通过这个句柄定位控件。比较傻B的方法就是建立一个HWND到控件类实例的映射,然后在消息收到后查询之,不过这种方法有很大的局限性。
Atl用Thunk技术来处理这个问题,这个所谓的“Thunk技术”干的事挺简单,不过要理解代码还真不容易(至少我是花了不少功夫)。有兴趣可以研究下代码:
(Microsoft Visual Studio 9.0VCatlmfcincludeatlstdthunk.h)
#pragma pack(push,1)
struct _stdcallthunk
{
DWORD m_mov; // mov dword ptr [esp+0x4], pThis (esp+0x4 is hWnd)
DWORD m_this; //
BYTE m_jmp; // jmp WndProc
DWORD m_relproc; // relative jmp
BOOL Init(DWORD_PTR proc, void* pThis)
{
m_mov = 0x042444C7; //C7 44 24 0C
m_this = PtrToUlong(pThis);
m_jmp = 0xe9;
m_relproc = DWORD((INT_PTR)proc - ((INT_PTR)this+sizeof(_stdcallthunk)));
// write block from data cache and
// flush from instruction cache
FlushInstructionCache(GetCurrentProcess(), this, sizeof(_stdcallthunk));
return TRUE;
}
//some thunks will dynamically allocate the memory for the code
void* GetCodeAddress()
{
return this;
}
void* operator new(size_t)
{
return __AllocStdCallThunk();
}
void operator delete(void* pThunk)
{
__FreeStdCallThunk(pThunk);
}
};
#pragma pack(pop)
这里我就不说什么原理了,我这水平也说不清:-)。
Thunk技术实际上就是用一段汇编代码将函数的参数动态的替换,具体来说是将回调函数参数HWND动态替换成窗口类实例的指针。关于它推荐阅读 http://www.cngr.cn/article/54/395/2006/2006071928301.shtml 。
这个过程在CWindowImplBaseT类的静态成员StartWindowProc中实现。首先在注册窗口时会指定它为回调,当第一次调用时,通过Thunk技术动态地修改回调参数,同时将回调重置为该类的另一个静态成员WindowProc。具体的实现代码如下:
pThis->m_thunk.Init(pThis->GetWindowProc(), pThis);
WNDPROC pProc = pThis->m_thunk.GetWNDPROC();
WNDPROC pOldProc = (WNDPROC)::SetWindowLongPtr(hWnd, GWLP_WNDPROC, (LONG_PTR)pProc);
那这个类实例在哪获取呢?其实Wtl/Atl实现也并不美观,通过CAtlWinModule类存储这些指针,很显然整个程序只应该包含一个CAtlWinModule类实例,这也是为什么我们经常看到这个实例前带一个extern关键字。
在新的回调WindowProc中,Atl将参数HWND转型为CWindowImplBaseT类指针,然后调用该类的成员函数ProcessWindowMessage来进一步派发消息。这个函数怎么定义看下一节内容。
回调和消息绑定
前面提到一个ProcessWindowMessage函数,它最初在CMessageMap类中以纯虚函数的形式定义。在Atl中不管什么类,只要派生自CMessageMap就可以处理消息,这就提供了很大的灵活性。
ATL定义了一堆预处理宏来实现这个函数和分发逻辑,典型的如下:
BEGIN_MSG_MAP(CMyWindow)
MESSAGE_HANDLER(WM_CLOSE, OnClose)
MESSAGE_HANDLER(WM_DESTROY, OnDestroy)
COMMAND_ID_HANDLER(IDC_ABOUT, OnAbout)
END_MSG_MAP()
前后两个宏用于定义ProcessWindowMessage函数,中间则通过一个Switch结构来定义分发逻辑和回调绑定。
ATL这一套结构有几个好处:
- 避免过多的纯虚函数导致额外的开销
- 容易将消息处理重定向,例如将消息处理重定向到一个非窗口类,实现UI和逻辑分离。也可以让同一个消息处理类同时处理多个窗口的消息。具体见ATL定义的那堆宏。
Wtl在Atl基础上针对特定消息定义了很多更加精确的宏,不过个人不是很喜欢,因为懒得去记。
Wtl入门
最基本的Wtl程序可以通过Appwiz来生成,很有必要理解下Wtl程序的流程。简单地讲,控件使用CButton等封装类(atlctrls.h),窗口使用CFrameWindowImpl派生。如果希望自定义控件,可以派生自CWindowImpl(自绘还需要继承其他自绘支持类,见后面说明),例如
class CBeepButton: public CWindowImpl< CBeepButton,CButton >
{
public:
DECLARE_WND_CLASS( _T("CBeepButton"))
BEGIN_MSG_MAP( CBeepButton )
END_MSG_MAP()
};
不过上面的类封装除了装逼没有任何用处!
发现几个比较恶心的地方提一下。
如果在自定义控件有绘制字体时,绘出来的字很奇怪,和默认的字体相差较大,后来发现可以手动设置字体将其设置为UI默认字体。
m_widget_->SetFont(AtlGetStockFont(DEFAULT_GUI_FONT));
对于动态创建的Edit或者RichEdit,边框都很奇怪,为了设置默认的边框,需要
m_widget_->ModifyStyleEx(0, WS_EX_CLIENTEDGE, SWP_DRAWFRAME);
超类化
超类化(superclass )是一种生成新的窗口类的方法。它的中心思想是依靠现有的窗口类,克隆出另一个窗口类。被克隆的类可以是Windows预定义的窗口类,这些预定义的窗口类有按钮或下拉框控制等等。也可以是一般的类。克隆的窗口类使用被克隆的类(基类)的窗口消息处理函数。
克隆类可以有自己的窗口消息处理函数,也可以使用基类的窗口处理函数。
(http://www.builder.com.cn/2007/1116/637833.shtml )
超类化是以类型为单位来设置,也就是被超类的类必须是已经存在的窗口(很显然,如果想“超”自定义窗口类,必须保证该类至少被用过一次或者手动注册过,如果没注册则超类会初始化失败)。在消息处理时,Wtl首先会使用超类的处理函数,如果没处理,则会调用“被超类”的消息处理函数来处理。
那这个“被超类”的消息处理函数在哪里呢?毕竟每次只能注册一个回调函数。实际上在CWindowImplBaseT类中包含一个成员m_pfnSuperWindowProc用于在超类化时存储“被超类”的原始回调。这个成员在CFrameWndClassInfo类或_ATL_WNDCLASSINFOW结构的成员函数Register调用时作为参数传入实现初始化。
通过宏DECLARE_FRAME_WND_SUPERCLASS或DECLARE_WND_SUPERCLASS来声明一个超类,两者原理都是一致的,即定义一个OrigWndClassName。在注册窗口类是首先获得OrigWndClassName类的注册信息,然后替换回调,并且将原来的回调保存在参数中,这个参数即前面提到的m_pfnSuperWindowProc。
关于这两回调的配合,可以参考CWindowImplBaseT类静态成员函数WindowProc(这个函数即通过Thunk技术重置后的回调函数,见前面说明)。Wtl首先会调用当前的回调,如果返回FALSE,则继续调用原来的回调。
为了测试超类化自定义窗口类,我写了如下代码:
class CBeepButton1: public CWindowImpl< CBeepButton1,CButton >
{
public:
DECLARE_WND_CLASS( _T("CBeepButton1"))
BEGIN_MSG_MAP( CBeepButton1 )
MESSAGE_HANDLER( WM_LBUTTONDOWN, OnLButtonDown )
MESSAGE_HANDLER( WM_LBUTTONUP, OnLButtonUp )
END_MSG_MAP()
LRESULT OnLButtonDown( UINT, WPARAM, LPARAM, BOOL& bHandled )
{
this->SetWindowText("Press");
bHandled = FALSE; // alternatively: DefWindowProc()
return 0;
}
LRESULT OnLButtonUp( UINT, WPARAM, LPARAM, BOOL& bHandled )
{
this->SetWindowText("Release");
bHandled = FALSE; // alternatively: DefWindowProc()
return 0;
}
};
class CBeepButton: public CWindowImpl< CBeepButton >
{
public:
DECLARE_WND_SUPERCLASS( _T("BeepButton"), _T("CBeepButton1") )
BEGIN_MSG_MAP( CBeepButton )
MESSAGE_HANDLER( WM_LBUTTONDOWN, OnLButtonDown )
END_MSG_MAP()
LRESULT OnLButtonDown( UINT, WPARAM, LPARAM, BOOL& bHandled )
{
bHandled = FALSE; // alternatively: DefWindowProc()
return 0;
}
};
经测试发现几个问题,为了使用 CBeepButton,必须先实现一个 CBeepButton1(目的是为了注册窗口类,主要是手动注册不方便)。否则 CBeepButton1会注册失败。即便如此 CbeepButton还是无法运行,究其原因是因为Thunk技术未能重置回调。
前面说过,Atl在初始化一个窗口类时,会使用Thunk技术动态重置回调。这个两个回调分别是CWindowImplBaseT类静态成员函数StartWindowProc和WindowPro,Thunk技术在前者中被使用,是一个临时的回调,具体的消息分发在后者进行。
当超类化一个自定义窗口类时,首先会获得原窗口的回调,而这个回调很显然是StartWindowProc,而新的窗口类并非处理了所有消息,所以总是有部分消息会发送到原窗口类的回调,即StartWindowProc。杯具就在这里,StartWindowProc是一个临时的回调。实际中当消息派发到这里时会碰到断点,因为无法从CAtlWinModule中获得类实例的指针(这都不是该窗口类初始化过程,当然找不到了)。这不得不说是Wtl的一个Bug,不过就目前这种框架,要改好还真不容易。
子类化
子类化(subclass)是普遍采用的一种扩展窗口功能的方法。它的大致原理如下。
在一个窗口创建完了之后,将该窗口的窗口函数替换成新的窗口消息处理函数。这个新的窗口函数可以对某些需要处理的特定的消息进行处理,然后再将处理传给原来的窗口函数。
注意它与superclass的区别。
Superclass是以一个类为原版,进行克隆。既在注册新的窗口类时,使用的是基类窗口的窗口函数。
而subclass是在某一个窗口注册并创建后,通过修改该窗口的窗口消息函数的地址而实现的。它是针对窗口实例。
(http://www.builder.com.cn/2007/1116/637833.shtml )
子类化的核心就是前面提到的Thunk技术,这里就不废话了。
自绘
说的自绘,我真想吐血,很不明白微软为什么要为了自绘搞出那么一套鸟毛东西,虽然所有的自绘都可以通过Paint来完成,不过既然微软推出那么一套鸟毛,总是会要犹豫一下,”我用Paint来做会不会有什么不妥“。
并不是所有的内置控件都支持那一套鸟毛的自绘,Wtl通过COwnerDraw类和CCustomDraw 类来简化这一套东西的开发,其实就是定义一堆宏来处理回调,提供一个相对简单的接口给程序员。为了能够让控件收到这些自定义消息,需要在父窗口加入反射宏DEFAULT_REFLECTION_HANDLER()。
不过个人很少用这东西,即便要自绘Button,我也是通过WM_PAINT来做的(这种做法有什么不妥忘各位指出,不过我没发现效率有多低,至少结构一致和美观,我想谁都不想去理解那么多规则,简单就是美)。
浏览器控件
如今越来越多的UI程序选择浏览器控件来显示网页内容,这有很多好处,至少简化了开发并且可以实现很复杂的样式,更重要的是无需升级可保持最新。
Wtl官方并没有内置浏览器控件,不过可以参考这里http://devel.openocr.org/svn/openocr/trunk/cuneiform/interface/icrashreport/wtl/samples/tabbrowser/browserview.h ,
----------------------------------------------WTL 方式对话框数据交换(DDX)
MFC程序员的WTL指南: Part IV - 对话框与控件(二)
http://www.cnblogs.com/procoder/archive/2009/06/11/1501044.html
---wtl 界面开发 http://blog.163.com/l1_jun/blog/static/14386388201052922725417/