WTL学习总结
八 29
在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.0\VC\atlmfc\include\atlstdthunk.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 ，
最近评论