MFC六大關鍵技術之消息映射與命令傳遞(五,六)

題外話:剛開始學視窗程序設計的時候,我就打印了一本Windows消息詳解,裏面列舉了各種已定義消息的意義和作用,共10多頁,在編程的時候翻翻,有時覺得很受用。我發覺很多編程的朋友,雖然每天都面對消息,卻很少關注它。C++程序員有一個通病,很想寫“自己”的程序,即每一行代碼都想自己寫出來。如果用了一些庫,總希望能完全理解庫裏的類或函數是怎麼一回事,否則就“不踏實”。對於消息,許多朋友只關心常用的幾個,對其餘的漠不關心。其實,Windows中有很多不常用的消息卻很有用,程序員可能通過響應這些消息實現更簡捷的編程。

說到消息,在MFC中,“最熟悉的神祕”可算是消息映射,那是我們剛開始接觸MFC時就要面對的東西。有過SDK編程經驗的朋友轉到MFC編程的時候,一下子覺得什麼都變了樣。特別是窗口消息及對消息的處理跟以前相比,更是風馬牛不相及的。如文檔不是窗口,是怎樣響應命令消息的呢?

初次用MFC編程,我們只會用MFC ClassWizard爲我們做大量的東西,最主要的是添加消息響應。記憶中,如果是自已添加消息響應,我們應何等的小心翼翼,對BEGIN_MESSAGE_MAP()……END_MESSAGE_MAP()更要奉若神靈。它就是一個魔盒子,把我們的咒語放入恰當的地方,就會發生神奇的力量,放錯了,自己的程序就連“命”都沒有。

據說,知道得太多未必是好事。我也曾經打算不去理解這神祕的區域,覺得編程的時候知道自己想做什麼就行了。MFC外表上給我們提供了東西,直觀地說,不但給了我個一個程序的外殼,更給我們許多方便。微軟的出發點可能是希望達到“傻瓜編程”的結果,試想,誰不會用ClassWizard?大家知道,Windows是基於消息的,有了ClassWizard,你又會添加類,又會添加消息,那麼你所學的東西似乎學到頭了。於是許多程序員認爲“我們沒有必要走SDK的老路,直接用MFC編程,新的東西通常是簡單、直觀、易學……”

到你真正想用MFC編程的時候,你會發覺光會ClassWizard的你是多麼的愚蠢。MFC不是一個普通的類庫,普通的類庫我們完全可以不理解裏面的細節,只要知道這些類庫能幹什麼,接口參數如何就萬事大吉。如string類,操作順序是定義一個string對象,然後修改屬性,調用方法。

但對於MFC,你並不是在你的程序中寫上一句“#include MFC.h”,然後就在你的程序中用MFC類庫。

MFC是一塊包着糖衣的牛骨頭。你很輕鬆地寫出一個單文檔窗口,在窗口中間打印一句“I love MFC!”,然後,惡夢開始了……想逃避,打算永遠不去理解MFC內幕?門都沒有!在MFC這個黑暗神祕的洞中,即使你打算摸着石頭前行,也註定找不到出口。對着MFC這塊牛骨頭,微軟溫和、民主地告訴你“你當然可以選擇不啃掉它,咳咳……但你必然會因此而餓死!”

消息映射與命令傳遞體現了MFC與SDK的不同。在SDK編程中,沒有消息映射的概念,它有明確的回調函數中,通過一個switch語句去判斷收到了何種消息,然後對這個消息進行處理。所以,在SDK編程中,會發送消息和在回調函數中處理消息就差不多可以寫SDK程序了。

在MFC中,看上去發送消息和處理消息比SDK更簡單、直接,但可惜不直觀。舉個簡單的例子,如果我們想自定義一個消息,SDK是非常簡單直觀的,用一條語句:SendMessage(hwnd,message/*一個大於或等於WM_USER的數字*/,wparam,lparam),之後就可以在回調函數中處理了。但MFC就不同了,因爲你通常不直接去改寫窗口的回調函數,所以只能亦步亦趨對照原來的MFC代碼,把消息放到恰當的地方。這確實是一樣很痛苦的勞動。

要了解MFC消息映射原理並不是一件輕鬆的事情。我們可以逆向思維,想象一下消息映射爲我們做了什麼工作。MFC在自動化給我們提供了很大的方便,比如,所有的MFC窗口都使用同一窗口過程,即所有的MFC窗口都有一個默認的窗口過程。不象在SDK編程中,要爲每個窗口類寫一個窗口過程。

對於消息映射,最直截了當地猜想是:消息映射就是用一個數據結構把“消息”與“響應消息函數名”串聯起來。這樣,當窗口感知消息發生時,就對結構查找,找到相應的消息響應函數執行。其實這個想法也不能簡單地實現:我們每個不同的MFC窗口類,對同一種消息,有不同的響應方式。即是說,對同一種消息,不同的MFC窗口會有不同的消息響應函數。

這時,大家又想了一個可行的方法。我們設計窗口基類(CWnd)時,我們讓它對每種不同的消息都來一個消息響應,並把這個消息響應函數定義爲空虛函數。這樣,從CWnd派生的窗口類對所有消息都有了一個空響應,我們要響應一個特定的消息就重載這個消息響應函數就可以了。但這樣做的結果,一個幾乎什麼也不做的CWnd類要有幾百個“多餘”的函數,那怕這些消息響應函數都爲純虛函數,每個CWnd對象也要揹負着一個巨大的虛擬表,這也是得不償失的。

許多朋友在學習消息映射時苦無突破,其原因是一開始就認爲MFC的消息映射的目的是爲了替代SDK窗口過程的編寫——這本來沒有理解錯。但他們還有多一層的理解,認爲既然是替代“舊”的東西,那麼MFC消息映身應該是更高層次的抽象、更簡單、更容易認識。但結果是,如果我們不通過ClassWizard工具,手動添加消息是相當迷茫的一件事。

所以,我們在學習MFC消息映射時,首先要弄清楚:消息映射的目的,不是爲是更加快捷地向窗口過程添加代碼,而是一種機制的改變。如果不想改變窗口過程函數,那麼應該在哪裏進行消息響應呢?許多朋友一知半解地認爲:我們可以用HOOK技術,搶在消息隊列前把消息抓取,把消息響應提到窗口過程的外面。再者,不同的窗口,會有不同的感興趣的消息,所以每個MFC窗口都應該有一個表把感興趣的消息和相應消息響應函數連繫起來。然後得出——消息映射機制執行步驟是:當消息發生,我們用HOOK技術把本發送到窗口過程的消息抓獲,然後對照一下MFC窗口的消息映射表,如果是表裏面有的消息,就執行其對應的函數。

當然,用HOOK技術,我們理論上可以在不改變窗口過程函數的情況下,可以完成消息響應。MFC確實是這樣做,但實際操作起來可能跟你的想象差別很大。

現在我們來編寫消息映射表,我們先定義一個結構,這個結構至少有兩個項:一是消息ID,二是響應該消息的函數。如下:

struct AFX_MSGMAP_ENTRY

{

UINT nMessage; //感興趣的消息

AFX_PMSG pfn; //響應以上消息的函數指針

}

當然,只有兩個成員的結構連接起來的消息映射表是不成熟的。Windows消息分爲標準消息、控件消息和命令消息,每類型的消息包含數百不同ID、不同意義、不同參數的消息。我們要準確地判別發生了何種消息,必須再增加幾個成員。還有,對於AFX_PMSG pfn,實際上等於作以下聲明:

void (CCmdTarget::*pfn)();

(提示:AFX_PMSG爲類型標識,具體聲明是:typedef void (AFX_MSG_CALL CCmdTarget::*AFX_PMSG)(void);)

pfn是不一不帶參數和返回值的CCmdTarget類型函數指針,只能指向CCmdTarget類中不帶參數和返回值的成員函數,這樣pfn更爲通用,但我們響應消息的函數許多需要傳入參數的。爲了解決這個矛盾,我們還要增加一個表示參數類型的成員。當然,還有其它……

最後,MFC我們消息映射表成員結構如下定義:

struct AFX_MSGMAP_ENTRY

{

UINT nMessage; //Windows 消息ID

UINT nCode; // 控制消息的通知碼

UINT nID; //命令消息ID範圍的起始值

UINT nLastID; //命令消息ID範圍的終點

UINT nSig; // 消息的動作標識

AFX_PMSG pfn;

};

有了以上消息映射表成員結構,我們就可以定義一個AFX_MSGMAP_ENTRY類型的數組,用來容納消息映射項。定義如下:

AFX_MSGMAP_ENTRY _messageEntries[];

但這樣還不夠,每個AFX_MSGMAP_ENTRY數組,只能保存着當前類感興趣的消息,而這僅僅是我們想處理的消息中的一部分。對於一個MFC程序,一般有多個窗口類,裏面都應該有一個AFX_MSGMAP_ENTRY數組。我們知道,MFC還有一個消息傳遞機制,可以把自己不處理的消息傳送給別的類進行處理。爲了能查找各下MFC對象的消息映射表,我們還要增加一個結構,把所有的AFX_MSGMAP_ENTRY數組串聯起來。

於是,我們定義了一個新結構體:

struct AFX_MSGMAP

{

const AFX_MSGMAP* pBaseMap; //指向別的類的AFX_MSGMAP對象

const AFX_MSGMAP_ENTRY* lpEntries; //指向自身的消息表

};

之後,在每個打算響應消息的類中這樣聲明一個變量:AFX_MSGMAP messageMap,讓其中的pBaseMap指向基類或另一個類的messageMap,那麼將得到一個AFX_MSGMAP元素的單向鏈表。這樣,所有的消息映射信息形成了一張消息網。

當然,僅有消息映射表還不夠,它只能把各個MFC對象的消息、參數與相應的消息響應函數連成一張網。爲了方便查找,MFC在上面的類中插入了兩個函數(其中theClass代表當前類):

一個是_GetBaseMessageMap(),用來得到基類消息映射的函數。函數原型如下:

const AFX_MSGMAP* PASCAL theClass::_GetBaseMessageMap() \

{ return &baseClass::messageMap; } \

別一個是GetMessageMap() ,用來得到自身消息映射的函數。函數原型如下:

const AFX_MSGMAP* theClass::GetMessageMap() const \

{ return &theClass::messageMap; } \

 

有了消息映射表之後,我們得討論到問題的關鍵,那就是消息發生以後,其對應的響應函數如何被調用。大家知道,所有的MFC窗口,都有一個同樣的窗口過程——AfxWndProc(…)。在這裏順便要提一下的是,看過MFC源代碼的朋友都得,從AfxWndProc函數進去,會遇到一大堆曲折與迷團,因爲對於這個龐大的消息映射機制,MFC要做的事情很多,如優化消息,增強兼容性等,這一大量的工作,有些甚至用匯編語言來完成,對此,我們很難深究它。所以我們要省略大量代碼,理性地分析它。

對已定型的AfxWndProc來說,對所有消息,最多隻能提供一種默認的處理方式。這當然不是我們想要的。我們想通過AfxWndProc最終執行消息映射網中對應的函數。那麼,這個執行路線是怎麼樣的呢?

從AfxWndProc下去,最終會調用到一個函數OnWndMsg。請看代碼:

LRESULT CALLBACK AfxWndProc(HWND hWnd,UINT nMsg,WPARAM wParam, LPARAM lParam)

{

……

CWnd* pWnd = CWnd::FromHandlePermanent(hWnd); //把對句柄的操作轉換成對CWnd對象。

Return AfxCallWndProc(pWnd,hWnd,nMsg,wParam,lParam);

}

把對句柄的操作轉換成對CWnd對象是很重要的一件事,因爲AfxWndProc只是一個全局函數,當然不知怎麼樣去處理各種windows窗口消息,所以它聰明地把處理權交給windows窗口所關聯的MFC窗口對象。

現大,大家幾乎可以想象得到AfxCallWndProc要做的事情,不錯,它當中有一句:

pWnd->WindowProc(nMsg,wParam,lParam);

到此,MFC窗口過程函數變成了自己的一個成員函數。WindowProc是一個虛函數,我們甚至可以通過改寫這個函數去響應不同的消息,當然,這是題外話。

WindowProc會調用到CWnd對象的另一個成員函數OnWndMsg,下面看看大概的函數原形是怎麼樣的:

BOOL CWnd::OnWndMsg(UINT message,WPARAM wParam,LPARAM lParam,LRESULT* pResult)

{

if(message==WM_COMMAND)

{

OnCommand(wParam,lParam);

……

}

if(message==WM_NOTIFY)

{

OnCommand(wParam,lParam,&lResult);

……

}

const AFX_MSGMAP* pMessageMap; pMessageMap=GetMessageMap();

const AFX_MSGMAP_ENTRY* lpEntry;

/*以下代碼作用爲:用AfxFindMessageEntry函數從消息入口pMessageMap處查找指定消息,如果找到,返回指定消息映射表成員的指針給lpEntry。然後執行該結構成員的pfn所指向的函數*/ if((lpEntry=AfxFindMessageEntry(pMessageMap->lpEntries,message,0,0)!=NULL)

{

lpEntry->pfn();/*注意:真正MFC代碼中沒有用這一條語句。上面提到,不同的消息參數代表不同的意義和不同的消息響應函數有不同類型的返回值。而pfn是一個不帶參數的函數指針,所以真正的MFC代碼中,要根據對象lpEntry的消息的動作標識nSig給消息處理函數傳遞參數類型。這個過程包含很複雜的宏代換,大家在此知道:找到匹配消息,執行相應函數就行!*/

}

}

 

以上,大家看到了OnWndMsg能根據傳進來的消息參數,查找到匹配的消息和執行相應的消息響應。但這還不夠,我們平常響應菜單命令消息的時候,原本屬於框架窗口(CFrameWnd)的WM_COMMAND消息,卻可以放到視對象或文檔對象中去響應。其原理如下:

我們看上面函數OnWndMsg原型中看到以下代碼:

if(message==WM_COMMAND)

{

OnCommand(wParam,lParam);

……

}

即對於命令消息,實際上是交給OnCommand函數處理。而OnCommand是一個虛函數,即WM_COMMAND消息發生時,最終是發生該消息所對應的MFC對象去執行OnCommand。比如點框架窗口菜單,即向CFrameWnd發送一個WM_COMMAND,將會導致CFrameWnd::OnCommand(wParam,lParam)的執行。

且看該函數原型

BOOL CFrameWnd::OnCommand(WPARAM wParam,LPARAM lParam)

{

……

return CWnd:: OnCommand(wParam,lParam);

}

可以看出,它最後把該消息交給CWnd:: OnCommand處理。再看:

BOOL CWnd::OnCommand(WPARAM wParam,LPARAM lParam)

{

……

return OnCmdMsg(nID,nCode,NULL,NULL);

}

這裏包含了一個C++多態性很經典的問題。在這裏,雖然是執行CWnd類的函數,但由於這個函數在CFrameWnd:: OnCmdMsg裏執行,即當前指針是CFrameWnd類指針,再有OnCmdMsg是一個虛函數,所以如果CFrameWnd改寫了OnCommand,程序會執行CFrameWnd::OnCmdMsg(…)。

對CFrameWnd::OnCmdMsg(…)函數原理扼要分析如下:

BOOL CFrameWnd:: OnCmdMsg(…)

{

CView pView = GetActiveView();//得到活動視指針。

if(pView-> OnCmdMsg(…))

return TRUE; //如果CView類對象或其派生類對象已經處理該消息,則返回。

……//否則,同理向下執行,交給文檔、框架、及應用程序執行自身的OnCmdMsg。

}

到此,CFrameWnd:: OnCmdMsg完成了把WM_COMMAND消息傳遞到視對象、文檔對象及應用程序對象實現消息響應。

寫了這麼多,我們清楚MFC消息映射與命令傳遞的大致過程。現在,我們來看MFC“神祕代碼”,會發覺好看多了。

先看DECLARE_MESSAGE_MAP()宏,它在MFC中定義如下:

#define DECLARE_MESSAGE_MAP() \

private: \

static const AFX_MSGMAP_ENTRY _messageEntries[]; \

protected: \

static AFX_DATA const AFX_MSGMAP messageMap; \

virtual const AFX_MSGMAP* GetMessageMap() const; \

可以看出DECLARE_MESSAGE_MAP()定義了我們熟悉的兩個結構和一個函數,顯而易見,這個宏爲每個需要實現消息映射的類提供了相關變量和函數。

 

現在集中精力來看一下BEGIN_MESSAGE_MAP,END_MESSAGE_MAP和ON_COMMAND三個宏,它們在MFC中定義如下(其中ON_COMMAND與另外兩個宏並沒有定義在同一個文件中,把它放到一起是爲了好看):

#define BEGIN_MESSAGE_MAP(theClass, baseClass) \

const AFX_MSGMAP* theClass::GetMessageMap() const \

{ return &theClass::messageMap; } \

AFX_COMDAT AFX_DATADEF const AFX_MSGMAP theClass::messageMap = \

{ &baseClass::messageMap, &theClass::_messageEntries[0] }; \

AFX_COMDAT const AFX_MSGMAP_ENTRY theClass::_messageEntries[] = \

{ \

 

#define ON_COMMAND(id, memberFxn) \

{ WM_COMMAND, CN_COMMAND, (WORD)id, (WORD)id, AfxSig_vv, (AFX_PMSG)&memberFxn },

 

#define END_MESSAGE_MAP() \

{0, 0, 0, 0, AfxSig_end, (AFX_PMSG)0 } \

}; \

 

一下子看三個宏覺得有點複雜,但這僅僅是複雜,公式性的文字代換並不是很難。且看下面例子,假設我們框架中有一菜單項爲“Test”,即定義瞭如下宏:

BEGIN_MESSAGE_MAP(CMainFrame, CFrameWnd)

ON_COMMAND(ID_TEST, OnTest)

END_MESSAGE_MAP()

 

那麼宏展開之後得到如下代碼:

const AFX_MSGMAP* CMainFrame::GetMessageMap() const

{ return &CMainFrame::messageMap; }

///以下填入消息表映射信息

const AFX_MSGMAP CMainFrame::messageMap =

{ &CFrameWnd::messageMap, &CMainFrame::_messageEntries[0] };

//下面填入保存着當前類感興趣的消息,可填入多個AFX_MSGMAP_ENTRY對象

const AFX_MSGMAP_ENTRY CMainFrame::_messageEntries[] =

{

{ WM_COMMAND, CN_COMMAND, (WORD)ID_TEST, (WORD)ID_TEST, AfxSig_vv, (AFX_PMSG)&OnTest }, // 加入的ID_TEST消息參數

{0, 0, 0, 0, AfxSig_end, (AFX_PMSG)0 } //本類的消息映射的結束項

};

 

大家知道,要完成ID_TEST消息映射,還要定義和實現OnTest函數。在此即要在頭文件寫afx_msg void OnTest()並在源文件中實現它。根據以上所學的東西,我們知道了當ID爲ID_TEST的命令消息發生,最終會執行到我們寫的OnTest函數。

    至此,MFC六大關鍵技術寫完了。其中寫得最難的是消息映射與命令傳遞,除了技術複雜之外,最難的是有許多避不開的代碼。爲了大家看得輕鬆一點,我把那繁雜的宏放在文章最後,希望能給你閱讀帶來方便。

    其實,較早前這就描述過MFC六大關鍵技術,也在一些論壇上發表過,但後三篇不知如何遺失了。許多朋友向我索稿,但苦於沒有備份,也不想枯燥地重寫,故推延至今,請大家見諒。

    還有,許多朋友說(二)(三)寫得十分不明白,這也是我意料到的地方。我寫文章,很少回頭看一下,有時自己也不知道自己寫了什麼。有許多朋友把修改後的版本給我,雖然修改了一點點,甚至僅僅修改了一下錯別字,但讀起來容易理解很多。對此,我內心十分感激。如果有更多的時間,我會修改一下前面的文章,放到我的網站上去!

本文來自CSDN博客,轉載請標明出處:http://blog.csdn.net/master_max/archive/2007/03/24/1540204.aspx


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章