第三章 ATL的窗口類
CWindowImpl、CWindow、CWinTraits，ATL窗口類的奧秘盡在此三者之中。在本章里，李馬將為你詳細(xì)解說(shuō)它們的使用方法。另外，本章的內(nèi)容也可以算是本書(shū)的核心部分——如果你要進(jìn)行ATL的GUI程序設(shè)計(jì)的話，就必須將ATL的窗口類設(shè)計(jì)理念了然于心。
窗口的組成
把ATL的窗口類撇開(kāi)不談先。我在上一章中提到：窗口類并非任何一種OOP語(yǔ)言中的類——它所包括的并不是通稱的屬性和方法（在C++中稱作成員變量和成員函數(shù)），而是屬性和響應(yīng)。現(xiàn)在是解釋這句話的時(shí)候了。
所謂窗口的屬性，無(wú)非是窗口的樣式（style）、背景畫刷（brush）、圖標(biāo)（icon）、光標(biāo)（cursor）……等元素。你可以從WNDCLASS及WNDCLASSEX中找到它們。需要特別指出的是，窗口的樣式事實(shí)上包括窗口類的樣式和窗口實(shí)例的樣式，窗口類的樣式在注冊(cè)窗口類之前經(jīng)由WNDCLASS::style或WNDCLASSEX::style指定，而窗口實(shí)例的樣式則是在創(chuàng)建窗口（CreateWindow/CreateWindowEx）的時(shí)候指定的。
對(duì)于窗口的響應(yīng)，即是指窗口收到某消息后的處理。（在VB、Delphi等RAD環(huán)境中，處理窗口的響應(yīng)亦稱作窗口的事件處理。）對(duì)于SDK而言，為窗口提供響應(yīng)也就是為窗口類提供一個(gè)回調(diào)函數(shù)，在回調(diào)函數(shù)中對(duì)我們感興趣的窗口消息進(jìn)行特殊處理，譬如上一章中針對(duì)WM_DESTROY和WM_PAINT的處理。
另外，我們?cè)谶M(jìn)行Win32程序設(shè)計(jì)的時(shí)候，往往還需要對(duì)窗口進(jìn)行操作，譬如ShowWindow和UpdateWindow——姑且讓我稱之為“方法”。
屬性、方法、事件，這回這哥仨算齊了。我們?cè)趯?duì)窗口進(jìn)行C++封裝時(shí)，需要考慮的也正是這三者。自然，依據(jù)OO的理念，我們可以很簡(jiǎn)單地將句柄作為成員變量，將方法作為成員函數(shù)，然后將事件經(jīng)由某種特定的消息分流手段移交給各個(gè)成員函數(shù)進(jìn)行響應(yīng)處理，加之對(duì)不同種類的窗口使用繼承進(jìn)行區(qū)分——這就是MFC的封裝做法。大家如果有興趣的話，可以打開(kāi)MFC的afxwin.h看一看CWnd類的代碼。
ATL窗口類的活版封裝
MFC的CWnd是一個(gè)冗長(zhǎng)得有些過(guò)分的類。究其原因，窗口類的封裝理念決定了窗口類的消息分流，而消息分流則決定了類的代碼篇幅。如果你已經(jīng)打開(kāi)了afxwin.h文件，就可以發(fā)現(xiàn)CWnd花了很大的篇幅在“On”開(kāi)頭的事件響應(yīng)函數(shù)上。其實(shí)在我們進(jìn)行Win32程序設(shè)計(jì)的時(shí)候，真正感興趣的事件沒(méi)有幾個(gè)，所以說(shuō)“萬(wàn)能”勢(shì)必造就冗長(zhǎng)。
另外，考慮MFC的誕生年代，所以對(duì)于窗口的封裝只是采用了C++的低端特性——例如薄層的封裝和單向繼承。（題外話：而且MFC中還存在著一些諸如CString、CArray、CList之類的工具，蓋因其時(shí)STL還未標(biāo)準(zhǔn)化之故。）隨著MFC的發(fā)展，任憑它做出任何優(yōu)化，也無(wú)法避免當(dāng)初架構(gòu)理念帶來(lái)的效率陰影和偏差。
ATL的誕生年代晚于MFC，使之能夠有機(jī)會(huì)使用C++的高端特性，也就是模板和多重繼承。于是，它使用了一種全新的封裝理念：將屬性、方法、事件分別獨(dú)立出來(lái)，然后利用模板和多重繼承的特性將這三者根據(jù)需要而組合在一起——打個(gè)比方來(lái)說(shuō)，如果MFC的窗口封裝是雕版印刷術(shù)，那么ATL的窗口封裝就是活版印刷術(shù)。以上一章的CHelloATLWnd類為例，它的繼承層次如下圖：
這是一個(gè)稍顯冗長(zhǎng)的繼承鏈，不過(guò)我并不打算對(duì)它進(jìn)行詳細(xì)的解說(shuō)。在此，我只請(qǐng)你看這個(gè)繼承層次的最底層和最上層。從最底層來(lái)看，CHelloATLWnd繼承自CWindowImpl，CWindowImpl有三個(gè)模板參數(shù)：T、TBase、TWinTraits。再看最上層，CWindowImplRoot繼承自TBase和CMessageMap。T參數(shù)即是你所繼承下來(lái)的子類名，通常用于編譯期的虛函數(shù)機(jī)制（后邊我會(huì)對(duì)這一機(jī)制進(jìn)行介紹）；TBase參數(shù)為對(duì)窗口方法和句柄的封裝；TWinTraits是窗口樣式的類封裝；CMessageMap是對(duì)窗口事件響應(yīng)的封裝。
下面，就讓李馬來(lái)逐一將這些組成部分介紹給你吧。
窗口樣式的封裝
窗口樣式通常由CWinTraits類封裝，這個(gè)類很簡(jiǎn)單，如下：
/////////////////////////////////////////////////////////////////////////////
// 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;
}
}; |
這個(gè)類有兩個(gè)模板參數(shù)：dwStyle和dwExStyle，也就是CreateWindowEx中要用到的那兩個(gè)樣式參數(shù)。在CHelloATLWnd::Create（其實(shí)也就是CWindowImpl::Create）調(diào)用的時(shí)候，窗口的樣式就是由CWinTraits::GetWndStyle/CWinTraits::GetWndExStyle決定的。
另外，ATL還為常用的窗口樣式提供了幾個(gè)typedef，如CControlWinTraits、CFrameWinTraits、CMDIChildWinTraits。在你需要它們這些特定樣式或者需要對(duì)它們進(jìn)行擴(kuò)展的時(shí)候，可以直接進(jìn)行使用或者使用CWinTraitsOR類來(lái)進(jìn)行進(jìn)一步的樣式組合，這里我就不多介紹了。
窗口方法的封裝
說(shuō)白了，窗口方法的封裝其實(shí)就是把窗口句柄和常用的窗口操作API函數(shù)（也就是那些第一個(gè)參數(shù)為HWND類型的API函數(shù)）進(jìn)行一層薄薄的綁定。這樣做的好處有二：第一，使代碼更有邏輯性，符合OO的設(shè)計(jì)理念；第二，在對(duì)SendMessage進(jìn)行封裝后，可以增加對(duì)消息參數(shù)的類型檢查。
CWindow類的內(nèi)容我就不列出了，因?yàn)樗瑯邮秩唛L(zhǎng)，大家可以參看atlwin.h的相關(guān)內(nèi)容。在這里我僅對(duì)其中的幾個(gè)地方進(jìn)行解說(shuō)：
- 它只有一個(gè)非static的成員變量，也就是窗口的句柄m_hWnd。這樣做的好處是使得CWindow類的對(duì)象占用最小的資源，同時(shí)給程序員提供最大的自由度。與MFC的CWnd類相比，CWindow的優(yōu)點(diǎn)體現(xiàn)得尤為明顯。CWnd之中還存在著一些MFC Framework要用到的東西，比如RTTI信息等等。此外，MFC內(nèi)部還會(huì)為每個(gè)窗口句柄維護(hù)一個(gè)相對(duì)應(yīng)的CWnd對(duì)象，形成一個(gè)對(duì)象鏈，這樣程序員可以通過(guò)GetDlgItem獲取CWnd類的指針，但是這同時(shí)也為系統(tǒng)增加了很多額外的負(fù)擔(dān)。
- CWindow提供了對(duì)operator=操作符的重載，這樣程序員可以直接將一個(gè)HWND賦給一個(gè)CWindow對(duì)象。
- CWindow::Attach/CWindow::Detach提供了CWindow對(duì)象與HWND的綁定/解除綁定功能。
- CWindow提供了對(duì)operator HWND類型轉(zhuǎn)換操作符的重載，這樣在用到HWND類型變量的時(shí)候，可以直接使用CWindow對(duì)象來(lái)代替。
有了CWindow類之后，如果你需要對(duì)窗口進(jìn)行更多的操作，就可以對(duì)其進(jìn)行繼承，例如CButton、CListBox、CEdit等等。這樣一來(lái)，代碼的復(fù)用性就大大提高了。
窗口事件響應(yīng)的封裝
窗口事件響應(yīng)的封裝，也就是這個(gè)類如何對(duì)窗口消息進(jìn)行分流。你應(yīng)該還記得，CHelloATLWnd類是通過(guò)BEGIN_MSG_MAP、END_MSG_MAP和MESSAGE_HANDLER宏實(shí)現(xiàn)的。如果你參閱了atlwin.h中它們的定義，你就會(huì)發(fā)現(xiàn)其實(shí)它們會(huì)組成一個(gè)ProcessWindowMessage函數(shù)。是的，CMessageMap就是由這個(gè)函數(shù)組成的：
/////////////////////////////////////////////////////////////////////////////
// CMessageMap - abstract class that provides an interface for message maps
class ATL_NO_VTABLE CMessageMap
{
public:
virtual BOOL ProcessWindowMessage(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam,
LRESULT& lResult, DWORD dwMsgMapID) = 0;
}; |
CWindowImplRoot派生自CMessageMap，所以CWindowImplRoot及至CWindowImpl都需要實(shí)現(xiàn)ProcessWindowMessage以完成窗口消息的分流。大家可以看到，這個(gè)函數(shù)的前四個(gè)參數(shù)是在SDK程序設(shè)計(jì)中窗口回調(diào)的原班人馬，在此不多介紹。lResult用來(lái)接收各消息處理函數(shù)的返回值，然后返回給最初的WndProc作為返回值。dwMsgMapID是一個(gè)神秘參數(shù)，且待李馬留到以后再進(jìn)行講解。
“等等！”也許你會(huì)突然打斷我，“——ATL是如何將WndProc封裝到類的成員函數(shù)中的？”的確，在編譯器的處理下，C++類中非static成員函數(shù)的參數(shù)尾部會(huì)被加入一個(gè)隱藏的this指針，這就使得它實(shí)際與回調(diào)函數(shù)的規(guī)格不合，所以非static成員函數(shù)是不能作為Win32的回調(diào)函數(shù)的。
先看MFC是如何做的吧。它采用一張龐大的消息映射表避開(kāi)了這個(gè)敏感的地方，對(duì)此感興趣的朋友們可參見(jiàn)JJHou先生的《深入淺出MFC》。也正因此，CWnd不得不為大部分消息各實(shí)現(xiàn)一個(gè)消息處理函數(shù)。還好這些消息處理函數(shù)不是虛函數(shù)，否則CWnd會(huì)維護(hù)多么龐大的一張?zhí)摵瘮?shù)表！
而ATL的奇妙之處也正是在此。它采用了thunk機(jī)制，即是在執(zhí)行真正的WndProc回調(diào)之前刷改了內(nèi)存中的機(jī)器碼，將HWND參數(shù)用本窗口類的this指針替換了，然后在執(zhí)行真正的代碼之前再將這個(gè)指針轉(zhuǎn)換回來(lái)。這樣，就將this指針的矛盾巧妙化解了。由于本書(shū)講解的是關(guān)于如何使用ATL進(jìn)行GUI程序設(shè)計(jì)方面的內(nèi)容，所以李馬不在此進(jìn)行過(guò)多探討了就，感興趣的朋友們可以自己研究atlwin.h中CWindowImplBaseT的代碼，或者參考Zeeshan Amjad先生的《ATL Under the Hook Part 5》一文。
在thunk機(jī)制的幫助下，ATL的窗口類就可以直接將不感興趣的消息交由DefWindowProc進(jìn)行處理，而不用像MFC一樣實(shí)現(xiàn)那么多消息處理函數(shù)。對(duì)于我們感興趣的消息，可以使用ATL中的BEGIN_MSG_MAP/END_MSG_MAP宏來(lái)在窗口類的成員函數(shù)ProcessWindowMessage中完成。此外對(duì)于消息的分流，除了MESSAGE_HANDLER宏，我們還可以使用其它的幾個(gè)宏進(jìn)行各種消息（命令消息、普通控件通知消息、公共控件通知消息）的分流，我將在后邊專門的一章中對(duì)ATL的CMessageMap的使用方法來(lái)進(jìn)行講解。
組合
葫蘆兄弟單打獨(dú)斗都不是蛇精的對(duì)手，所以葫蘆山神就會(huì)派仙鶴攜帶七色彩蓮找到他們，最后七個(gè)葫蘆娃合體成為威力無(wú)比的葫蘆小金剛，消滅了妖精，人世間重獲太平……
這自然是一個(gè)非常老套的故事，但想必如我一樣的80s生人看到后仍然會(huì)感慨不已。在那個(gè)少兒的精神食糧異常匱乏的年代，這部有些程式化臉譜化的動(dòng)畫片告訴了我們一個(gè)簡(jiǎn)單的道理：只有團(tuán)結(jié)起來(lái)，才能發(fā)揮最大的力量。
ATL的窗口類也是如此，單憑CWinTraits、CWindow、CMessageMap這哥仨單打獨(dú)斗是不可能成就大氣候的。我們需要做的，就是使用某種方法來(lái)將它們組合起來(lái)。感謝C++為我們帶來(lái)的多重繼承和模板——多重繼承讓我們能夠?qū)⑺鼈兘M合，模板讓我們能夠?qū)⑺鼈冹`活地組合（所謂“靈活地組合”，即是在CWindowImpl層通過(guò)填入模板參數(shù)來(lái)決定繼承鏈的頂層CWindowImplRoot的多重繼承情況）。那么，再回到上一章的窗口類CHelloATLWnd：
class CHelloATLWnd : public CWindowImpl< CHelloATLWnd, CWindow, CWinTraits< WS_OVERLAPPEDWINDOW > >
{
public:
CHelloATLWnd()
public:
DECLARE_WND_CLASS( _T("HelloATL") )
public:
BEGIN_MSG_MAP( CHelloATLWnd )
MESSAGE_HANDLER( WM_DESTROY, OnDestroy )
MESSAGE_HANDLER( WM_PAINT, OnPaint )
END_MSG_MAP()
public:
LRESULT OnDestroy( UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& hHandled )
{
::PostQuitMessage( 0 );
return 0;
}
LRESULT OnPaint( UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& hHandled )
{
HDC hdc;
PAINTSTRUCT ps;
hdc = BeginPaint( &ps );
DrawText( hdc, _T("Hello, ATL!"), -1, &ps.rcPaint, DT_CENTER | DT_VCENTER | DT_SINGLELINE );
EndPaint( &ps );
return 0;
}
}; |
不知道你現(xiàn)在再看到這個(gè)類是否會(huì)少幾分生疏？在這里，CWindowImpl就擔(dān)任了“七色彩蓮”的角色——BEGIN_MSG_MAP/END_MSG_MAP是CMessageMap由繼承帶來(lái)的，BeginPaint/EndPaint是CWindow由模板和多重繼承帶來(lái)的，以及控制窗口樣式的CWinTraits（在這里要提醒一點(diǎn)，在將CWinTraits作為CWindowImpl的模板參數(shù)時(shí)，一定要將CWinTraits的模板參數(shù)右尖括號(hào)與CWindowImpl的模板參數(shù)右尖括號(hào)用空格分隔開(kāi)，否則湊在一起的兩個(gè)右尖括號(hào)“>>”將會(huì)被編譯器判斷為右移操作符）是由模板帶來(lái)的。
當(dāng)然，我還要回答上一章遺留下來(lái)的問(wèn)題：WNDCLASSEX窗口類是如何注冊(cè)的？
如果你是前已經(jīng)偷偷看過(guò)CWindowImpl::Create的代碼，那么相信這個(gè)問(wèn)題你已經(jīng)知道答案了。不過(guò)我還是要把相關(guān)代碼列出來(lái)：
// from CWindowImpl::Create
if (T::GetWndClassInfo().m_lpszOrigName == NULL)
T::GetWndClassInfo().m_lpszOrigName = GetWndClassName();
ATOM atom = T::GetWndClassInfo().Register(&m_pfnSuperWindowProc); |
也就是說(shuō)，窗口類的注冊(cè)是在窗口創(chuàng)建前完成的。
下面，李馬請(qǐng)你注意上面代碼中GetWndClassInfo的部分。這個(gè)函數(shù)是由窗口類的編寫者——也就是我們，ATL的GUI開(kāi)發(fā)者——完成的，它的主要功能是用來(lái)獲取窗口類的屬性。在通常的情況下，GetWndClassInfo使用DECLARE_WND_CLASS/DECLARE_WND_CLASS_EX的形式來(lái)實(shí)現(xiàn)。參看DECLARE_WND_CLASS宏的定義：
#define DECLARE_WND_CLASS(WndClassName)
static CWndClassInfo& GetWndClassInfo()
{
static CWndClassInfo wc =
{
{ sizeof(WNDCLASSEX), CS_HREDRAW | CS_VREDRAW | CS_DBLCLKS, StartWindowProc,
0, 0, NULL, NULL, NULL, (HBRUSH)(COLOR_WINDOW + 1), NULL, WndClassName, NULL },
NULL, NULL, IDC_ARROW, TRUE, 0, _T("")
};
return wc;
} |
這里已經(jīng)為要注冊(cè)的窗口類設(shè)置好了絕大多數(shù)的常用屬性，當(dāng)然，如果你仍然覺(jué)得自己需要更改更多的屬性的話，可以像CHelloATLWnd的構(gòu)造函數(shù)里那么做。特別要指出的一點(diǎn)是，ATL對(duì)窗口類的光標(biāo)（cursor）屬性是進(jìn)行特殊處理的，對(duì)CWndClassInfo::m_wc.hCursor直接賦值是不行的。
編譯期的虛函數(shù)機(jī)制
ATL的效率遠(yuǎn)遠(yuǎn)高于MFC，其中一方面的原因就是它把很多的工作都通過(guò)模板來(lái)交給編譯器了，比如我上文提到的編譯期的虛函數(shù)機(jī)制。這個(gè)機(jī)制可以避免虛函數(shù)帶來(lái)的一切開(kāi)銷而靜態(tài)實(shí)現(xiàn)虛函數(shù)的特性。考慮以下代碼：
template < typename T >
class Parent
{
public:
void f()
void g()
{
T* pT = (T*)this;
pT->f();
}
};
class Child1 : public Parent< Child1 >
{
public:
void f()
};
class Child2 : public Parent< Child2 >
; |
然后，這樣進(jìn)行調(diào)用：
Child1 c1;
Child2 c2;
c1.g(); // f from Child1.
c2.g(); // f from Parent. |
所有的奧秘盡在Parent::g之中，它通過(guò)一個(gè)類型轉(zhuǎn)換在編譯期就決定了調(diào)用哪個(gè)函數(shù)，頗有些多態(tài)性的味道。ATL就是借助這樣的機(jī)制來(lái)保證效率的，如果你深入到atlwin.h的源代碼之中，肯定會(huì)發(fā)現(xiàn)更多諸如此類的例子。