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

最新推荐文章于 2019-06-29 19:09:25 发布

阅读量2.3k

点赞数 1

分类专栏： WTL 文章标签：框架 windows command class null callback

WTL 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

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

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; /
 }

ATL的消息处理宏

消息映射的目的是实现ProcessWindowMessage()。ProcessWindowMessage()函数是窗口函数的关键逻辑。

一共有三种消息处理宏，分别对应三类窗口消息——普通窗口消息（如WM_CREATE），命令消息（WM_COMMANS）和通知消息（WM_NOTIFY）。

消息处理宏的目的是将消息和相应的处理函数（该窗口的成员函数）联系起来。

· 普通消息处理宏

有两个这样的宏：MESSAGE_HANDLER和MESSAGE_RANGE_HANDLER。

第一个宏将一个消息和一个消息处理函数连在一起。第二个宏将一定范围内的消息和一个消息处理函数连在一起。

消息处理函数通常是下面这样的：

LRESULT MessageHandler(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled);

注意最后一个参数bHandled。它的作用是该处理函数是否处理该消息。如果它为FALSE，消息MAP的其它处理函数会来处理这个消息。

我们看一下MESSAGE_HANDLE的定义：

#define MESSAGE_HANDLER(msg, func) /
 if(uMsg == msg) /
 { /
  bHandled = TRUE; /
  lResult = func(uMsg, wParam, lParam, bHandled); /
  if(bHandled) /
   return TRUE; /
 }

在上面的代码中，首先判断是否是想要处理的消息。如果是的，那么调用第二个参数表示的消息处理函数来处理该消息。

注意bHandled，如果在消息处理函数中设置为TRUE，那么，在完成该消息处理后，会进入return TRUE语句，从ProcessWindowMessage()函数中返回。

如果bHandled在调用消息处理函数时，设置为FALSE，则不会从ProcessWindowMessage中返回，而是继续执行下去。

· 命令消息处理宏和通知消息处理宏

命令消息处理宏有五个——COMMAND_HANDLER，COMMAND_ID_HANDLER，COMMAND_CODE_HANDLER，COMMAND_RANGE_HANDLER和COMMAND_RANGE_CODE_HANDLER。

通知消息处理宏有五个--NOTIFY_HANDLER，NOTIFY_ID_HANDLER，NOTIFY_CODE_HANDLER，NOTIFY_RANGE_HANDLER和NOTIFY_RANGE_CODE_HANDLER

我们不再详细分析。

通过上面的分析，我们知道了ATL是怎样实现窗口函数逻辑的。那么ATL是怎样封装窗口函数的呢？为了能理解ATL的封装方法，还必须了解ATL中的窗口subclass等技术。我们将在分析完这些技术之后，再分析ATL对窗口消息处理函数的封装。

扩展窗口类的功能

我们知道Windows窗口的功能由它的窗口函数指定。通常在创建Windows应用程序时，我们要开发一个窗口函数。通过定义对某些消息的相应来实现窗口的功能。

在每个窗口处理函数的最后，我们一般用下面的语句：

　　　　　default:
　　　　　　return DefWindowProc(hWnd, message, wParam, lParam);

它的意思是，对于没有处理的消息，我们将它传递给Windows的确省窗口函数。

Windows除了提供这个缺省的窗口函数，还为某些标准的控制提供了一些预定义的窗口函数。

我们在注册窗口类的时候，指定了该窗口类的窗口处理函数。

扩展窗口类的功能，就是要改变窗口函数中对某些消息的处理逻辑。

下面我们来看几种扩展窗口功能的技术，以及看看ATL是怎样实现的。

派生和CHAIN_MSG_MAP()

很自然，我们会在一个窗口类的基础上派生另一个。然后通过定义不同的消息处理函数。

下面是一个简单的实例（该例子摘自MSDN）。

class CBase: public CWindowImpl< CBase >
// simple base window class: shuts down app when closed
{
   BEGIN_MSG_MAP( CBase )
      MESSAGE_HANDLER( WM_DESTROY, OnDestroy )
   END_MSG_MAP()

   LRESULT OnDestroy( UINT, WPARAM, LPARAM, BOOL& )
   {
      PostQuitMessage( 0 );
      return 0;
   }
};
class CDerived: public CBase
// derived from CBase; handles mouse button events
{
   BEGIN_MSG_MAP( CDerived )
      MESSAGE_HANDLER( WM_LBUTTONDOWN, OnButtonDown )
      CHAIN_MSG_MAP( CBase ) // chain to base class
   END_MSG_MAP()

   LRESULT OnButtonDown( UINT, WPARAM, LPARAM, BOOL& )
   {
      ATLTRACE( "button down/n" );
      return 0;
   }
};

在上面的例子中，CDerived从CBase中派生出来。CDerived类通过定义一个WM_LBUTTONDOWN消息处理函数来改变CBase类代表的窗口的功能。

这样，CBase类的消息映射定义了一个ProcessWindowMessage()函数，而CDerived类的消息映射也定义了一个ProcessWindowMessage()函数。

那么，我们在窗口处理函数逻辑中怎样把这两个类的ProcessWindowMessage()连起来呢？（想想为什么要连起来？）

在CDerived的消息映射中，有一个宏CHAIN_MSG_MAP()。它的作用就是把两个类对消息的处理连起来。

看一下这个宏的定义：

#define CHAIN_MSG_MAP(theChainClass) /
 { /
if(theChainClass::ProcessWindowMessage(hWnd, uMsg, wParam, lParam, lResult)) /
   return TRUE; /
 }

很简单，它仅仅调用了基类的ProcessWindowMessage()函数。

也就是说，CDerived类的ProcessWindowMessage()包含两部分，一部分是调用处理WM_LBUTTONDOWN的消息处理函数，该函数是该类的成员函数。第二部分是调用CBase类的ProcessWindowMessage()函数，该函数用于处理WM_DESTROY消息。

在后面对窗口函数的封装中，我们会知道，对于其他消息处理，CDerived会传递给缺省窗口函数。

派生和ALT_MSG_MAP()

如果我们希望在CBase类上再派生一个新的窗口类。该类除了要对WM_RBUTTONDOWN做不同的处理外，还希望CBase对WM_DESTROY消息的响应与前一个例子不同。比如希望能提示关闭窗口信息。

那怎么处理呢？ATL提供了一种机制，它由ALT_MSG_MAP()实现。它使得一个类的消息映射能处理多个Windows窗口类。

下面是具体的示例：

// in class CBase:
   BEGIN_MSG_MAP( CBase )
      MESSAGE_HANDLER( WM_DESTROY, OnDestroy1 )
      ALT_MSG_MAP( 100 )
      MESSAGE_HANDLER( WM_DESTROY, OnDestroy2 )
   END_MSG_MAP()

ALT_MSG_MAP()将消息映射分成两个部分。每个部分的消息映射都有一个ID。上面的消息映射的ID分别为0和100。

分析一下ALT_MSG_MAP()：

#define ALT_MSG_MAP(msgMapID) /
  break; /
  case msgMapID:

很简单，它结束了前面的msgMapID的处理，开始进入另一个msgMapID的处理。

那么，在CDerived类的消息映射中，是怎样将两个类的ProcessWindowMessage()函数的逻辑连在一起的呢？

// in class CDerived:
   BEGIN_MSG_MAP( CDerived )
      CHAIN_MSG_MAP_ALT( CBase, 100 )
   END_MSG_MAP()

这里使用CHAIN_MSG_MAP_ALT()宏。它的具体定义如下：

#define CHAIN_MSG_MAP_ALT(theChainClass, msgMapID) /
{ /
if(theChainClass::ProcessWindowMessage(hWnd, uMsg, wParam, lParam, lResult, 
msgMapID)) /
 return TRUE; /
 }

不再分析其原理。请参考前面对CHAIN_MSG_MAP（）宏的分析。

superclass是一种生成新的窗口类的方法。它的中心思想是依靠现有的窗口类，克隆出另一个窗口类。被克隆的类可以是Windows预定义的窗口类，这些预定义的窗口类有按钮或下拉框控制等等。也可以是一般的类。克隆的窗口类使用被克隆的类（基类）的窗口消息处理函数。

克隆类可以有自己的窗口消息处理函数，也可以使用基类的窗口处理函数。

需要注意的是，superclass是在注册窗口类时就改变了窗口的行为。即通过指定基类的窗口函数或是自己定义的窗口函数。这与后面讲到的subclass是不同的。后者是在窗口创建完毕后，通过修改窗口函数的地址等改变一个窗口的行为的。

请看示例（摘自MSDN）：

class CBeepButton: public CWindowImpl< CBeepButton >
{
public:
   DECLARE_WND_SUPERCLASS( _T("BeepButton"), _T("Button") )
   BEGIN_MSG_MAP( CBeepButton )
      MESSAGE_HANDLER( WM_LBUTTONDOWN, OnLButtonDown )
   END_MSG_MAP()
   LRESULT OnLButtonDown( UINT, WPARAM, LPARAM, BOOL& bHandled )
   {
      MessageBeep( MB_ICONASTERISK );
      bHandled = FALSE; // alternatively: DefWindowProc()
      return 0;
   }
}; // CBeepButton

该类实现一个按钮，在点击它时，会有响声。

该类的消息映射处理WM_LBUTTONDOWN消息。其它的消息由Windows缺省窗口函数处理。

在消息映射前面，有一个宏--DECLARE_WND_SUPERCLASS()。它的作用就是申明BeepButton是Button的一个superclass。

分析一下这个宏：

#define DECLARE_WND_SUPERCLASS(WndClassName, OrigWndClassName) /
static CWndClassInfo& GetWndClassInfo() /
{ /
 static CWndClassInfo wc = /
 { /
  { sizeof(WNDCLASSEX), 0, StartWindowProc, /
    0, 0, NULL, NULL, NULL, NULL, NULL, WndClassName, NULL }, /
  OrigWndClassName, NULL, NULL, TRUE, 0, _T("") /
 }; /
 return wc; /
}

这个宏定义了一个静态函数GetWndClassInfo()。这个函数返回了一个窗口类注册时用到的数据结构CWndClassInfo。该结构的详细定义如下：

struct _ATL_WNDCLASSINFOA
{
 WNDCLASSEXA m_wc;
 LPCSTR m_lpszOrigName;
 WNDPROC pWndProc;
 LPCSTR m_lpszCursorID;
 BOOL m_bSystemCursor;
 ATOM m_atom;
 CHAR m_szAutoName[13];
 ATOM Register(WNDPROC* p)
 {
  return AtlModuleRegisterWndClassInfoA(&_Module, this, p);
 }
};
struct _ATL_WNDCLASSINFOW
{
 … …
 {
  return AtlModuleRegisterWndClassInfoW(&_Module, this, p);
 }
};
typedef _ATL_WNDCLASSINFOA CWndClassInfoA;
typedef _ATL_WNDCLASSINFOW CWndClassInfoW;
#ifdef UNICODE
#define CWndClassInfo CWndClassInfoW
#else
#define CWndClassInfo CWndClassInfoA
#endif

这个结构调用了一个静态函数AtlModuleRegisterWndClassInfoA(&_Module, this, p);。这个函数的用处就是注册窗口类。

它指定了WndClassName是OrigWdClassName的superclass。

subclass

subclass是普遍采用的一种扩展窗口功能的方法。它的大致原理如下。

在一个窗口创建完了之后，将该窗口的窗口函数替换成新的窗口消息处理函数。这个新的窗口函数可以对某些需要处理的特定的消息进行处理，然后再将处理传给原来的窗口函数。

注意它与superclass的区别。

Superclass是以一个类为原版，进行克隆。既在注册新的窗口类时，使用的是基类窗口的窗口函数。

而subclass是在某一个窗口注册并创建后，通过修改该窗口的窗口消息函数的地址而实现的。它是针对窗口实例。

看一个从MSDN来的例子：

class CNoNumEdit: public CWindowImpl< CNoNumEdit >
{
   BEGIN_MSG_MAP( CNoNumEdit )
      MESSAGE_HANDLER( WM_CHAR, OnChar )
   END_MSG_MAP()
   LRESULT OnChar( UINT, WPARAM wParam, LPARAM, BOOL& bHandled )
   {
      TCHAR ch = wParam;
      if( _T('0') <= ch && ch <= _T('9') )
         MessageBeep( 0 );
      else
         bHandled = FALSE;
      return 0;
   }
};

这里定义了一个只接收数字的编辑控件。即通过消息映射，定义了一个特殊的消息处理逻辑。

然后，我们使用CWindowImplT. SubclassWindow()来subclass一个编辑控件。

class CMyDialog: public CDialogImpl<CMyDialog>
{
public:
   enum { IDD = IDD_DIALOG1 };
   BEGIN_MSG_MAP( CMyDialog )
      MESSAGE_HANDLER( WM_INITDIALOG, OnInitDialog )
   END_MSG_MAP()
   LRESULT OnInitDialog( UINT, WPARAM, LPARAM, BOOL& )
   {
      ed.SubclassWindow( GetDlgItem( IDC_EDIT1 ) ); 
      return 0;
   }

   CNoNumEdit ed;
};

上述代码中，ed.SubclassWindow( GetDlgItem( IDC_EDIT1 ) )语句是对IDC_EDIT1这个编辑控件进行subclass。该语句实际上是替换了编辑控件的窗口函数。

由于SubClassWindows()实现的机制和ATL封装窗口函数的机制一样，我们会在后面介绍ATL是怎么实现它的。

ATL对窗口消息处理函数的封装

在本节开始部分谈到的封装窗口的两个难题，其中第一个问题是怎样解决将窗口函数的消息转发到HWND相对应的类的实例中的相应函数。

下面我们来看一下，ATL采用的是什么办法来实现的。

我们知道每个Windows的窗口类都有一个窗口函数。

LRESULT WndProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam);

在类CWindowImplBaseT中，定义了两个类的静态成员函数。

template <class TBase = CWindow, class TWinTraits = CControlWinTraits>
class ATL_NO_VTABLE CWindowImplBaseT : public CWindowImplRoot< TBase >
{
public:
  … …
static LRESULT CALLBACK StartWindowProc(HWND hWnd, UINT uMsg, WPARAM wParam, 
LPARAM lParam);
static LRESULT CALLBACK WindowProc(HWND hWnd, UINT uMsg, WPARAM wParam,
LPARAM lParam);
 … …
}

它们都是窗口函数。之所以定义为静态成员函数，是因为每个类必须只有一个窗口函数，而且，窗口函数的申明必须是这样的。

在前面介绍的消息处理逻辑过程中，我们知道怎样通过宏生成虚函数ProcessWindowsMessage(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam, LRESULT& lResult, DWORD dwMsgMapID)。

现在的任务是怎样在窗口函数中把消息传递给某个实例（窗口）的ProcessWindowsMessage()。这是一个难题。窗口函数是类的静态成员函数，因此，它不象类的其它成员函数，参数中没有隐含this指针。

注意，之所以存在这个问题是因为ProcessWindowsMessage()是一个虚函数。而之所以用虚函数是考虑到类的派生及多态性。如果不需要实现窗口类的派生及多态性，是不存在这个问题的。

通常想到的解决办法是根据窗口函数的HWND参数，寻找与其对应的类的实例的指针。然后，通过该指针，调用该实例的消息逻辑处理函数ProcessWindowsMessage()。

这样就要求存储一个全局数组，将HWND和该类的实例的指针一一对应地存放在该数组中。

ATL解决这个问题的方法很巧妙。该方法并不存储这些对应关系，而是使窗口函数接收C++类指针作为参数来替代HWND作为参数。

具体步骤如下：

· 在注册窗口类时，指定一个起始窗口函数。

· 创建窗口类时，将this指针暂时保存在某处。

· Windows在创建该类的窗口时会调用起始窗口函数。它的作用是创建一系列二进制代码（thunk）。这些代码用this指针的物理地址来取代窗口函数的HWND参数，然后跳转到实际的窗口函数中。这是通过改变栈来实现的。

· 然后，用这些代码作为该窗口的窗口函数。这样，每次调用窗口函数时都对参数进行转换。

· 在实际的窗口函数中，只需要将该参数cast为窗口类指针类型。

详细看看ATL的封装代码。

1. 注册窗口类时，指定一个起始窗口函数。

在superclass中，我们分析到窗口注册时，指定的窗口函数是StartWindowProc()。

2. 创建窗口类时，将this指针暂时保存在某处。

template <class TBase, class TWinTraits>
HWND CWindowImplBaseT< TBase, TWinTraits >::Create(HWND hWndParent, RECT& rcPos, 
LPCTSTR szWindowName,
DWORD dwStyle, DWORD dwExStyle, UINT nID, ATOM atom, LPVOID lpCreateParam)
{
ATLASSERT(m_hWnd == NULL);
if(atom == 0)
return NULL;
_Module.AddCreateWndData(&m_thunk.cd, this);
if(nID == 0 && (dwStyle & WS_CHILD))
nID = (UINT)this;
HWND hWnd = ::CreateWindowEx(dwExStyle, (LPCTSTR)MAKELONG(atom, 0), szWindowName,
dwStyle, rcPos.left, rcPos.top, rcPos.right - rcPos.left,
rcPos.bottom - rcPos.top, hWndParent, (HMENU)nID,
_Module.GetModuleInstance(), lpCreateParam);
ATLASSERT(m_hWnd == hWnd);
return hWnd;
}

该函数用于创建一个窗口。它做了两件事。第一件就是通过_Module.AddCreateWndData(&m_thunk.cd, this);语句把this指针保存在_Module的某个地方。

第二件事就是创建一个Windows窗口。

3. 一段奇妙的二进制代码

下面我们来看一下一段关键的二进制代码。它的作用是将传递给实际窗口函数的HWND参数用类的实例指针来代替。

ATL定义了一个结构来代表这段代码：

#pragma pack(push,1)
struct _WndProcThunk
{
 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
};

#pragma pack(pop)

#pragma pack(push,1)的意思是告诉编译器，该结构在内存中每个字段都紧紧挨着。因为它存放的是机器指令。

这段代码包含两条机器指令：

mov dword ptr [esp+4], pThis
jmp WndProc

MOV指令将堆栈中的HWND参数（esp+0x4）变成类的实例指针pThis。JMP指令完成一个相对跳转到实际的窗口函数WndProc的任务。注意，此时堆栈中的HWND参数已经变成了pThis，也就是说，WinProc得到的HWND参数实际上是pThis。

上面最关键的问题是计算出jmp WndProc的相对偏移量。

我们看一下ATL是怎样初始化这个结构的。

class CWndProcThunk
{
public:
 union
 {
  _AtlCreateWndData cd;
  _WndProcThunk thunk;
 };
 void Init(WNDPROC proc, void* pThis)
 {
  thunk.m_mov = 0x042444C7;  //C7 44 24 0C
  thunk.m_this = (DWORD)pThis;
  thunk.m_jmp = 0xe9;
  thunk.m_relproc = (int)proc - ((int)this+sizeof(_WndProcThunk));
  // write block from data cache and
  //  flush from instruction cache
  FlushInstructionCache(GetCurrentProcess(), &thunk, sizeof(thunk));
 }
};

ATL包装了一个类并定义了一个Init()成员函数来设置初始值的。在语句thunk.m_relproc = (int)proc - ((int)this+sizeof(_WndProcThunk)); 用于把跳转指令的相对地址设置为(int)proc - ((int)this+sizeof(_WndProcThunk))。

上图是该窗口类的实例（对象）内存映象图，图中描述了各个指针及它们的关系。很容易计算出相对地址是(int)proc - ((int)this+sizeof(_WndProcThunk))。

4. StartWindowProc()的作用

template <class TBase, class TWinTraits>
LRESULT CALLBACK CWindowImplBaseT< TBase, TWinTraits >::StartWindowProc(HWND hWnd, 
UINT uMsg, WPARAM wParam, LPARAM lParam)
{
CWindowImplBaseT< TBase, TWinTraits >* pThis = (CWindowImplBaseT< TBase, 
TWinTraits >*)_Module.ExtractCreateWndData();
 ATLASSERT(pThis != NULL);
 pThis->m_hWnd = hWnd;
 pThis->m_thunk.Init(pThis->GetWindowProc(), pThis);
 WNDPROC pProc = (WNDPROC)&(pThis->m_thunk.thunk);
 WNDPROC pOldProc = (WNDPROC)::SetWindowLong(hWnd, GWL_WNDPROC, (LONG)pProc);
#ifdef _DEBUG
 // check if somebody has subclassed us already since we discard it
 if(pOldProc != StartWindowProc)
  ATLTRACE2(atlTraceWindowing, 0, _T("Subclassing through a hook 
discarded./n"));
#else
 pOldProc; // avoid unused warning
#endif
 return pProc(hWnd, uMsg, wParam, lParam);
}

该函数做了四件事：

一是调用_Module.ExtractCreateWndData()语句，从保存this指针的地方得到该this指针。

二是调用m_thunk.Init(pThis->GetWindowProc(), pThis)语句初始化thunk代码。

三是将thunk代码设置为该窗口类的窗口函数。

WNDPROC pProc = (WNDPROC)&(pThis->m_thunk.thunk);
 WNDPROC pOldProc = (WNDPROC)::SetWindowLong(hWnd, GWL_WNDPROC, (LONG)pProc);

这样，以后的消息处理首先调用的是thunk代码。它将HWND参数改为pThis指针，然后跳转到实际的窗口函数WindowProc()。

四是在完成上述工作后，调用上面的窗口函数。

由于StartWindowProc()在创建窗口时被Windows调用。在完成上述任务后它应该继续完成Windows要求完成的任务。因此在这里，就简单地调用实际的窗口函数来处理。

5. WindowProc()窗口函数

下面是该函数的定义：

template <class TBase, class TWinTraits>
LRESULT CALLBACK CWindowImplBaseT< TBase, TWinTraits >::WindowProc(HWND hWnd, 
UINT uMsg, WPARAM wParam, LPARAM lParam)
{
CWindowImplBaseT< TBase, TWinTraits >* pThis = (CWindowImplBaseT< TBase,
TWinTraits >*)hWnd;
// set a ptr to this message and save the old value
MSG msg = { pThis->m_hWnd, uMsg, wParam, lParam, 0, { 0, 0 } };
const MSG* pOldMsg = pThis->m_pCurrentMsg;
pThis->m_pCurrentMsg = &msg;
// pass to the message map to process
LRESULT lRes;
BOOL bRet = pThis->ProcessWindowMessage(pThis->m_hWnd, uMsg, wParam, lParam, lRes, 
0);
// restore saved value for the current message
ATLASSERT(pThis->m_pCurrentMsg == &msg);
pThis->m_pCurrentMsg = pOldMsg;
// do the default processing if message was not handled
if(!bRet)
{
 if(uMsg != WM_NCDESTROY)
  lRes = pThis->DefWindowProc(uMsg, wParam, lParam);
  else
  {
   // unsubclass, if needed
   LONG pfnWndProc = ::GetWindowLong(pThis->m_hWnd, 
GWL_WNDPROC);
   lRes = pThis->DefWindowProc(uMsg, wParam, lParam);
   if(pThis->m_pfnSuperWindowProc != ::DefWindowProc && 
::GetWindowLong(pThis->m_hWnd, GWL_WNDPROC) == pfnWndProc)
    ::SetWindowLong(pThis->m_hWnd, GWL_WNDPROC, 
(LONG)pThis->m_pfnSuperWindowProc);
   // clear out window handle
   HWND hWnd = pThis->m_hWnd;
   pThis->m_hWnd = NULL;
   // clean up after window is destroyed
   pThis->OnFinalMessage(hWnd);
  }
 }
 return lRes;
}

首先，该函数把hWnd参数cast到一个类的实例指针pThis。

然后调用pThis->ProcessWindowMessage(pThis->m_hWnd, uMsg, wParam, lParam, lRes, 0);语句，也就是调用消息逻辑处理，将具体的消息处理事务交给ProcessWindowMessage()。

接下来，如果ProcessWindowMessage()没有对任何消息进行处理，就调用缺省的消息处理。

注意这里处理WM_NCDESTROY的方法。这和subclass有关，最后恢复没有subclass以前的窗口函数。

WTL对subclass的封装

前面讲到过subclass的原理，这里看一下是怎么封装的。

template <class TBase, class TWinTraits>
BOOL CWindowImplBaseT< TBase, TWinTraits >::SubclassWindow(HWND hWnd)
{
 ATLASSERT(m_hWnd == NULL);
 ATLASSERT(::IsWindow(hWnd));
 m_thunk.Init(GetWindowProc(), this);
 WNDPROC pProc = (WNDPROC)&(m_thunk.thunk);
 WNDPROC pfnWndProc = (WNDPROC)::SetWindowLong(hWnd, GWL_WNDPROC, 
(LONG)pProc);
 if(pfnWndProc == NULL)
  return FALSE;
 m_pfnSuperWindowProc = pfnWndProc;
 m_hWnd = hWnd;
 return TRUE;
}

没什么好说的，它的工作就是初始化一段thunk代码，然后替换原先的窗口函数。

WTL对框架窗口的封装

ATL仅仅是封装了窗口函数和提供了消息映射。实际应用中，需要各种种类的窗口，比如，每个界面线程所对应的框架窗口。WTL正是在ATL基础上，为我们提供了框架窗口和其他各种窗口。

所有的应用程序类型中，每个界面线程都有一个框架窗口(Frame)和一个视(View)。它们的概念和MFC中的一样。

图示是WTL的窗口类的继承图。

WTL框架窗口为我们提供了：

一个应用程序的标题，窗口框架，菜单，工具栏。

视的管理，包括视的大小的改变，以便与框架窗口同步。

提供对菜单，工具栏等的处理代码。

在状态栏显示帮助信息等等。

WTL视通常就是应用程序的客户区。它通常用于呈现内容给客户。

WTL提供的方法是在界面线程的逻辑中创建框架窗口，而视的创建由框架窗口负责。后面会介绍，框架窗口在处理WM_CREATE消息时创建视。

如果要创建一个框架窗口，需要：

从CFrameWindowImpl类派生你的框架窗口。

加入DECLARE_FRAME_WND_CLASS，指定菜单和工具栏的资源ID。

加入消息映射，同时把它与基类的消息映射联系起来。同时，加入消息处理函数。

下面是使用ATL/WTL App Wizard创建一个SDI应用程序的主框架窗口的申明。

class CMainFrame : public CFrameWindowImpl<CMainFrame>, 
public CUpdateUI<CMainFrame>,
               public CMessageFilter, public CIdleHandler
{
public:
 DECLARE_FRAME_WND_CLASS(NULL, IDR_MAINFRAME)
     // 该框架窗口的视的实例
 CView m_view;
     // 该框架窗口的命令工具行
 CCommandBarCtrl m_CmdBar;
 virtual BOOL PreTranslateMessage(MSG* pMsg);
 virtual BOOL OnIdle();
 BEGIN_UPDATE_UI_MAP(CMainFrame)
  UPDATE_ELEMENT(ID_VIEW_TOOLBAR, UPDUI_MENUPOPUP)
  UPDATE_ELEMENT(ID_VIEW_STATUS_BAR, UPDUI_MENUPOPUP)
 END_UPDATE_UI_MAP()
 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()
// Handler prototypes (uncomment arguments if needed):
// LRESULT MessageHandler(UINT /*uMsg*/, WPARAM /*wParam*/, LPARAM /*lParam*/, 
BOOL& /*bHandled*/)
// LRESULT CommandHandler(WORD /*wNotifyCode*/, WORD /*wID*/, HWND /*hWndCtl*/, 
BOOL& /*bHandled*/)
// LRESULT NotifyHandler(int /*idCtrl*/, LPNMHDR /*pnmh*/, BOOL& /*bHandled*/)
 LRESULT OnCreate(UINT /*uMsg*/, WPARAM /*wParam*/, LPARAM /*lParam*/, BOOL& 
/*bHandled*/);
 LRESULT OnFileExit(WORD /*wNotifyCode*/, WORD /*wID*/, HWND /*hWndCtl*/, 
BOOL& /*bHandled*/);
 LRESULT OnFileNew(WORD /*wNotifyCode*/, WORD /*wID*/, HWND /*hWndCtl*/, 
BOOL& /*bHandled*/);
 LRESULT OnViewToolBar(WORD /*wNotifyCode*/, WORD /*wID*/, HWND /*hWndCtl*/, 
BOOL& /*bHandled*/);
 LRESULT OnViewStatusBar(WORD /*wNotifyCode*/, WORD /*wID*/, HWND 
/*hWndCtl*/, BOOL& /*bHandled*/);
 LRESULT OnAppAbout(WORD /*wNotifyCode*/, WORD /*wID*/, HWND /*hWndCtl*/, 
BOOL& /*bHandled*/);
};

DECLARE_FRAME_WND_CLASS()宏是为框架窗口指定一个资源ID，可以通过这个ID和应用程序的资源联系起来，比如框架的图标，字符串表，菜单和工具栏等等。

WTL视

通常应用程序的显示区域分成两个部分。一是包含窗口标题，菜单，工具栏和状态栏的主框架窗口。另一部分就是被称为视的部分。这部分是客户区，用于呈现内容给客户。

视可以是包含HWND的任何东西。通过在框架窗口处理WM_CREATE时，将该HWND句柄赋植给主窗口的m_hWndClien成员来设置主窗口的视。

比如，在用ATL/WTL App Wizard创建了一个应用程序，会创建一个视，代码如下：

class CTestView : public CWindowImpl<CTestView>
{
public:
 DECLARE_WND_CLASS(NULL)

 BOOL PreTranslateMessage(MSG* pMsg);

 BEGIN_MSG_MAP(CTestView)
  MESSAGE_HANDLER(WM_PAINT, OnPaint)
 END_MSG_MAP()

// Handler prototypes (uncomment arguments if needed):
// LRESULT MessageHandler(UINT /*uMsg*/, WPARAM /*wParam*/, LPARAM /*lParam*/, 
BOOL& /*bHandled*/)
// LRESULT CommandHandler(WORD /*wNotifyCode*/, WORD /*wID*/, HWND /*hWndCtl*/, 
BOOL& /*bHandled*/)
// LRESULT NotifyHandler(int /*idCtrl*/, LPNMHDR /*pnmh*/, BOOL& /*bHandled*/)
LRESULT OnPaint(UINT /*uMsg*/, WPARAM /*wParam*/, LPARAM /*lParam*/, BOOL& 
/*bHandled*/);
};

这个视是一个从CWindowImpl派生的窗口。

在主窗口的创建函数中，将该视的HWND设置给主窗口的m_hWndClient成员。

LRESULT CMainFrame::OnCreate(UINT /*uMsg*/, WPARAM /*wParam*/, LPARAM /*lParam*/, 
BOOL& /*bHandled*/)
{
    … …
 m_hWndClient = m_view.Create(m_hWnd, rcDefault, NULL, WS_CHILD | WS_VISIBLE 
| WS_CLIPSIBLINGS | WS_CLIPCHILDREN, WS_EX_CLIENTEDGE);
    … …
 return 0;
}

上述代码为主窗口创建了视。

到此为止，我们已经从Win32模型开始，到了解windows界面程序封装以及WTL消息循环机制，详细分析了WTL。通过我们的分析，您是否对WTL有一个深入的理解，并能得心应手的开发出高质量的Windows应用程序？别急，随后，我们还将一起探讨开发WTL应用程序的技巧。