深入剖析WTL—WTL框架窗口分析
深入剖析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 |
我们知道一个窗口函数的通常结构就是许多的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 |
上述代码中，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 |
它们都是窗口函数。之所以定义为静态成员函数，是因为每个类必须只有一个窗口函数，而且，窗口函数的申明必须是这样的。
在前面介绍的消息处理逻辑过程中，我们知道怎样通过宏生成虚函数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 |
该函数用于创建一个窗口。它做了两件事。第一件就是通过_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 |
该函数做了四件事：
一是调用_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 |
首先，该函数把hWnd参数cast到一个类的实例指针pThis。
然后调用pThis->ProcessWindowMessage(pThis->m_hWnd, uMsg, wParam, lParam, lRes, 0);语句，也就是调用消息逻辑处理，将具体的消息处理事务交给ProcessWindowMessage()。
接下来，如果ProcessWindowMessage()没有对任何消息进行处理，就调用缺省的消息处理。
注意这里处理WM_NCDESTROY的方法。这和subclass有关，最后恢复没有subclass以前的窗口函数。
WTL对subclass的封装
前面讲到过subclass的原理，这里看一下是怎么封装的。
template |
没什么好说的，它的工作就是初始化一段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 |
DECLARE_FRAME_WND_CLASS()宏是为框架窗口指定一个资源ID，可以通过这个ID和应用程序的资源联系起来，比如框架的图标，字符串表，菜单和工具栏等等。
WTL视
通常应用程序的显示区域分成两个部分。一是包含窗口标题，菜单，工具栏和状态栏的主框架窗口。另一部分就是被称为视的部分。这部分是客户区，用于呈现内容给客户。
视可以是包含HWND的任何东西。通过在框架窗口处理WM_CREATE时，将该HWND句柄赋植给主窗口的m_hWndClien成员来设置主窗口的视。
比如，在用ATL/WTL App Wizard创建了一个应用程序，会创建一个视，代码如下：
class CTestView : public CWindowImpl |
这个视是一个从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应用程序的技巧。