已经不止一位朋友向我咨询过这个问题——《用SDK玩转ActiveX》的源代码在VS2003、VS2005下无法正常运行，错误原因是GetDlgItem无法取到ActiveX控件的窗口容器句柄，因而也就无法为CAxWindow赋值。于是在此补遗，请诸位周知。 ATL 3.0中的ActiveX控件处理机制是这样的： 调用AtlAxCreateDialog或AtlAxDialogBox之前，检索对话框资源中的所有控件数据。 如果遇到ActiveX控件，则将其窗口类名称替换为"AtlAxWin"（ATL窗口类名），窗口标题替换为该ActiveX控件的CLSID。 由于替换成了名为"AtlAxWin"的窗口类，所以对话框创建控件后会依次创建各个容器，再由各个容器自己创建相应的ActiveX控件。 但是从ATL 7.0开始，处理方式变成了： 调用AtlAxCreateDialog或AtlAxDialogBox之前，检索对话框资源中的所有控件数据。 如果遇到ActiveX控件，则将该控件数据从对话框资源中剔除。 在CAxDialogImpl::DialogProc中截获WM_INITDIALOG并创建所有的ActiveX控件。 所以，对于一个使用ATL 7.0编写的含有ActiveX控件的对话框而言，应该使用CAxDialogImpl，而不再是简单的AtlAxCreateDialog或AtlAxDialogBox了。

第四章 对话框和控件 对于Win32 GUI的程序设计来说，其实大部分的情况下我们都不需要自己进行窗口类的设计，而是可以使用Win32中与用户交互的标准方式——对话框（Dialog Box）。我们可以在VC IDE的资源设计器中设计对话框资源，并在其上放置各种控件资源——的确是非常方便。在本章里，李马将要向诸位介绍如何利用ATL来操作对话框，以及如何操作对话框上的各种控件。 题外话先 ATL，是的，正是由于我所讲的是“ATL的GUI程序设计”，所以我才可能将内容直接经由CWindowImpl过渡到CDialogImpl——而不是过渡到你先前所熟悉的CFrameWnd和Doc/View体系。况且，即使这之后我深入到了CDialogImpl之中，我也不会讲到你所熟悉的DDX/DDV机制。再三考虑之下，我还是决定把这些东西在CDialogImpl前一并当作题外话说出来，先。 再来回顾一下ATL的性质。它是一个被设计用来开发COM组件的Framework，所以对GUI部分的支持——套用一句2006年的流行语来说：那是相~~当~~（加重且延长声音地）少。于是，它没有“框架窗口”这个概念，更不会有Doc/View体系。其实我对MFC的这一设计特点感觉不错，毕竟它可以通过一个简单的CFrameWnd类来实现一个标准的SDI/MDI框架，而且其中带有工具栏、状态栏和一个用来容纳视图的标准的工作区域。我们可以通过控制框架窗口中的View及其相关的Doc类型来完成特定文档类型的读写与显示。——但是，很不幸，这一切都只属于伟大的MFC；在ATL中，我们什么都没有。 另外，在对话框的技术领域中，使用ATL的我们也不会享有数据交换与验证（DDX/DDV）的支持。这一所谓的缺憾我并不想多加评价，一是因为我并不了解MFC中DDX/DDV的内部机制，二是因为我直觉上认为这是影响MFC效率的罪魁之一。在MFC中，我们可以通过向导的支持轻易地为表单的输入域加入输入校验与限制，而且表现在源代码上的仅仅是几个宏而已——我自认天下没有免费的午餐，这几个简单的宏既然能为我们包办一切，那我们势必会相应地失去些东西，要不然忒便宜了也就。 题外话的最后不免落入俗套，我将会向诸位介绍解决以上缺憾的方法。——也许你猜到了，就是从WTL中寻找解决方案。WTL是对ATL的扩展，所以它的很多代码可以直接拿过来用（当然可能需要一些小小的修改）。而且，不知道WTL的设计者是不是为了拉拢MFC的开发人员，总之它里面添加了很多与MFC相似的元素，例如以上所说的框架窗口和DDX/DDV。 CDialogImpl 与ATL窗口类CWindowImpl相对应，ATL的对话框类名为CDialogImpl。它的定义如下： C++代码 template <class T, class TBase = CWindow>    class ATL_NO_VTABLE CDialogImpl : public CDialogImplBaseT< TBase >    {    // …    };   你可以从上面的代码看到，CDialogImpl与CWindowImpl类似，也经历了一系列的继承链。不过，它较之CWindowImpl的模板参数要简单得多——毕竟是标准对话框，有些东西是不用操心的。 CDialogImpl的使用方法大致如下： C++代码 class CYourDlg : public CDialogImpl< CYourDlg >    {    public:        enum { IDD = IDD_YOUR_DLG };    public:        BEGIN_MSG_MAP( CYourDlg )            // 消息映射        END_MSG_MAP()    public:        // 消息响应函数        ///////////////////        // 其余的部分…    };   和CWindowImpl不一样，CDialogImpl不需要使用DECLARE_WND_CLASS来定义窗口类。在原来DECLARE_WND_CLASS的位置，一个枚举代替了原来窗口类定义的部分。这里的枚举列表必须有一个被命名为IDD，并且它的值要被设置为相应的对话框资源ID。呃……写到这里，我仿佛已经感觉到了你的不快，但CDialogImpl的实现即是如此（以CDialogImpl::DoModal为例）： C++代码 // from CDialogImpl::DoModal    …

第三章 ATL的窗口类 CWindowImpl、CWindow、CWinTraits，ATL窗口类的奥秘尽在此三者之中。在本章里，李马将为你详细解说它们的使用方法。另外，本章的内容也可以算是本书的核心部分——如果你要进行ATL的GUI程序设计的话，就必须将ATL的窗口类设计理念了然于心。 窗口的组成 把ATL的窗口类撇开不谈先。我在上一章中提到：窗口类并非任何一种OOP语言中的类——它所包括的并不是通称的属性和方法（在C++中称作成员变量和成员函数），而是属性和响应。现在是解释这句话的时候了。 所谓窗口的属性，无非是窗口的样式（style）、背景画刷（brush）、图标（icon）、光标（cursor）……等元素。你可以从WNDCLASS及WNDCLASSEX中找到它们。需要特别指出的是，窗口的样式事实上包括窗口类的样式和窗口实例的样式，窗口类的样式在注册窗口类之前经由WNDCLASS::style或WNDCLASSEX::style指定，而窗口实例的样式则是在创建窗口（CreateWindow/CreateWindowEx）的时候指定的。 对于窗口的响应，即是指窗口收到某消息后的处理。（在VB、Delphi等RAD环境中，处理窗口的响应亦称作窗口的事件处理。）对于SDK而言，为窗口提供响应也就是为窗口类提供一个回调函数，在回调函数中对我们感兴趣的窗口消息进行特殊处理，譬如上一章中针对WM_DESTROY和WM_PAINT的处理。 另外，我们在进行Win32程序设计的时候，往往还需要对窗口进行操作，譬如ShowWindow和UpdateWindow——姑且让我称之为“方法”。 属性、方法、事件，这回这哥仨算齐了。我们在对窗口进行C++封装时，需要考虑的也正是这三者。自然，依据OO的理念，我们可以很简单地将句柄作为成员变量，将方法作为成员函数，然后将事件经由某种特定的消息分流手段移交给各个成员函数进行响应处理，加之对不同种类的窗口使用继承进行区分——这就是MFC的封装做法。大家如果有兴趣的话，可以打开MFC的afxwin.h看一看CWnd类的代码。 ATL窗口类的活版封装 MFC的CWnd是一个冗长得有些过分的类。究其原因，窗口类的封装理念决定了窗口类的消息分流，而消息分流则决定了类的代码篇幅。如果你已经打开了afxwin.h文件，就可以发现CWnd花了很大的篇幅在“On”开头的事件响应函数上。其实在我们进行Win32程序设计的时候，真正感兴趣的事件没有几个，所以说“万能”势必造就冗长。 另外，考虑MFC的诞生年代，所以对于窗口的封装只是采用了C++的低端特性——例如薄层的封装和单向继承。（题外话：而且MFC中还存在着一些诸如CString、CArray、CList之类的工具，盖因其时STL还未标准化之故。）随着MFC的发展，任凭它做出任何优化，也无法避免当初架构理念带来的效率阴影和偏差。 ATL的诞生年代晚于MFC，使之能够有机会使用C++的高端特性，也就是模板和多重继承。于是，它使用了一种全新的封装理念：将属性、方法、事件分别独立出来，然后利用模板和多重继承的特性将这三者根据需要而组合在一起——打个比方来说，如果MFC的窗口封装是雕版印刷术，那么ATL的窗口封装就是活版印刷术。以上一章的CHelloATLWnd类为例，它的继承层次如下图： 这是一个稍显冗长的继承链，不过我并不打算对它进行详细的解说。在此，我只请你看这个继承层次的最底层和最上层。从最底层来看，CHelloATLWnd继承自CWindowImpl，CWindowImpl有三个模板参数：T、TBase、TWinTraits。再看最上层，CWindowImplRoot继承自TBase和CMessageMap。T参数即是你所继承下来的子类名，通常用于编译期的虚函数机制（后边我会对这一机制进行介绍）；TBase参数为对窗口方法和句柄的封装；TWinTraits是窗口样式的类封装；CMessageMap是对窗口事件响应的封装。 下面，就让李马来逐一将这些组成部分介绍给你吧。 窗口样式的封装 窗口样式通常由CWinTraits类封装，这个类很简单，如下： C++代码 /////////////////////////////////////////////////////////////////////////////    // CWinTraits - Defines various default values for a window       template <DWORD t_dwStyle = 0, DWORD t_dwExStyle = 0>    class CWinTraits    {    public:        static DWORD GetWndStyle(DWORD dwStyle)        {            return dwStyle == 0 ? t_dwStyle : dwStyle;        }        static DWORD GetWndExStyle(DWORD dwExStyle)        {            return dwExStyle == 0 ? t_dwExStyle : dwExStyle;        }    };   这个类有两个模板参数：dwStyle和dwExStyle，也就是CreateWindowEx中要用到的那两个样式参数。在CHelloATLWnd::Create（其实也就是CWindowImpl::Create）调用的时候，窗口的样式就是由CWinTraits::GetWndStyle/CWinTraits::GetWndExStyle决定的。 另外，ATL还为常用的窗口样式提供了几个typedef，如CControlWinTraits、CFrameWinTraits、CMDIChildWinTraits。在你需要它们这些特定样式或者需要对它们进行扩展的时候，可以直接进行使用或者使用CWinTraitsOR类来进行进一步的样式组合，这里我就不多介绍了。 窗口方法的封装 说白了，窗口方法的封装其实就是把窗口句柄和常用的窗口操作API函数（也就是那些第一个参数为HWND类型的API函数）进行一层薄薄的绑定。这样做的好处有二：第一，使代码更有逻辑性，符合OO的设计理念；第二，在对SendMessage进行封装后，可以增加对消息参数的类型检查。 CWindow类的内容我就不列出了，因为它同样十分冗长，大家可以参看atlwin.h的相关内容。在这里我仅对其中的几个地方进行解说： 它只有一个非static的成员变量，也就是窗口的句柄m_hWnd。这样做的好处是使得CWindow类的对象占用最小的资源，同时给程序员提供最大的自由度。与MFC的CWnd类相比，CWindow的优点体现得尤为明显。CWnd之中还存在着一些MFC Framework要用到的东西，比如RTTI信息等等。此外，MFC内部还会为每个窗口句柄维护一个相对应的CWnd对象，形成一个对象链，这样程序员可以通过GetDlgItem获取CWnd类的指针，但是这同时也为系统增加了很多额外的负担。 …

第二章 一个最简单窗口程序的转型 我知道，可能会有很多朋友对上一章的“Hello, World!”ATL版不以为然，因为它并不能算是什么ATL程序——毕竟它只不过是有了个CComModule而已。不过不管怎样我还是要说，它几乎仍然拥有了一个ATL GUI程序的所有组成部分：入口、初始化、程序体、卸载…… “等等！”也许你会突然打断我，“——还有注册窗口类、消息循环呢？” 当然，对于一个完整的GUI程序来讲，这也是必要的。 貌似废话 不清楚你是否已经为本章的内容做好了准备，因为下面我们就要动真格的了。不过考虑到本书的读者群中可能会存在着相当一部分了解MFC却对Win32 GUI的基本原理和流程不甚熟悉的朋友，所以李马特别为你们准备了这一节的内容。SDK的粉丝们可以跳过这一节，如果你们觉得李马讲的有些拖沓冗长的话。 那么，我还是先以一个标准的Win32 SDK程序开始： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 …