[轉載] 深度剖析消息反射機制

什麼是消息反射?

在Windows裏面,子控件經常向父控件發送消息,例如很多子控件要繪製自己的背景,就可能向父窗口發送消息WM_CTLCOLOR。對於從子控件發來的消息,父控件有可能在處理之前,把消息返還給子控件處理,這樣消息看起來就想是從父窗口反射回來一樣,故此得名:消息反射。

消息反射的由來

在Windows和MFC4.0版本以下,父窗口(通常是一個對話框)會對這些消息進行處理,換句話說,子控件的這些消息處理必須在父窗口類體內,每當我們添加子控件的時候,就要在父窗口類中複製這些代碼,我們可以想象這是多麼的複雜,代碼是多麼的臃腫!
我們可以想象,如果這些消息都讓父窗口類去做,父窗口就成了一個萬能的神,一個臃腫不堪的代碼機,無論如何消息的處理都集中在父窗口類中,會使父窗口繁重無比,但是子控件卻無事可做,並且代碼也無法重用,這對於一個程序員來講是多麼痛苦的一件事?!
在老版本的MFC中,設計者也意識到了這個問題,他們對一些消息採用了虛擬機制,例如:WM_DRAWITEM,這樣子控件就有機會控制自己的動作,代碼的可重用性有了一定的提高,但是這還沒有達到大部分人的要求,所以在高版本的MFC中,提出了一種更方便的機制:消息反射。
通過消息反射機制,子控件窗口便能夠自行處理與自身相關的一些消息,增強了封裝性,同時也提高了子控件窗口類的可重用性。不過需要注意的是:消息反射是MFC實現的,不是Windows實現的;要讓你的消息反射機制工作,你的類必須從CWnd類派生。

Message-Map中的處理

如果想要處理消息反射,必須瞭解相應的Message-Map宏和函數原型。一般來講,Message-Map是有一定的規律的,通常她在消息的前面加上一個ON_ ,然後再消息的最後加上 _REFLECT。例如我們前面提到的WM_CTLCOLOR 經過處理後變成了ON_WM_CTLCOLOR_REFLECT;WM_MEASUREITEM則變成了ON_WM_MEASUREITEM_REFLECT。
凡事總會有例外,這裏也是這樣,這裏面有3個例外:
(1) WM_COMMAND 轉換成 ON_CONTROL_REFLECT;
(2) WM_NOTIFY 轉換成 ON_NOTIFY_REFLECT;
(3) ON_UPDATE_COMMAND_UI 轉換成 ON_UPDATE_COMMAND_UI_REFLECT;
對於函數原型,也必須是以 afx_msg 開頭。

利用ClassWizard添加消息反射

(1)在ClassWizard中,打開選擇項Message Maps;
(2)在下拉列表Class name中選擇你要控制的類;
(3)在Object IDs中,選中相應的類名;
(4)在Messages一欄中找到前面帶有=標記的消息,那就是反射消息;
(5)雙擊鼠標或者單擊添加按鈕,然後OK!

消息處理的過程

(1)子窗口向父窗口發送通知消息,激發父窗口去調用它的虛函數CWnd::OnNotify。大致的結構如下

BOOL CWnd::OnNotify(WPARAM wParam, LPARAM lParam, LRESULT* pResult)
{
    
if (ReflectLastMsg(hWndCtrl, pResult)) file://hWndCtrl,爲發送窗口
        return TRUE; file://如果子窗口已處理了此消息,返回
    AFX_NOTIFY notify;
    notify.pResult 
= pResult;
    notify.pNMHDR 
= pNMHDR;
    
return OnCmdMsg(nID, MAKELONG(nCode, WM_NOTIFY)? notify:NULL);
}

(2)ReflectLastMsg聲明如下:
static BOOL PASCAL ReflectLastMsg(HWND hWndChild, LRESULT* pResult = NULL);
它的主要任務就是調用發送窗口的SendChildNotifyLastMsg。
(3)SendChildNotifyLastMsg聲明如下:
BOOL SendChildNotifyLastMsg(LRESULT* pResult = NULL);
調用發送窗口的虛函數OnChildNotify函數,進行處理。 如果發送窗口沒有進行重載處理,則調用ReflectChildNotify(...)函數進行標準的反射消息的消息映射處理。

實用的一個例子

這裏面我們舉一個簡單的例子,希望大家能夠更清晰的掌握消息反射機制。
(1)創建一個基於對話框的工程。
(2)利用嚮導創建一個新的類:CMyEdit,基類是CEdit。
(3)在CMyEdit頭文件中加入3個成員變量:
COLORREF m_clrText ;
COLORREF m_clrBkgnd ;
CBrush m_brBkgnd;
(4)利用嚮導在其中加入WM_CTLCOLOR(看到了麼,前面是不是有一個=?),並且將它的函數體改爲:

HBRUSH CMyEdit::CtlColor(CDC* pDC, UINT nCtlColor)
{
    pDC
->SetTextColor( m_clrText );    // text
    pDC->SetBkColor( m_clrBkgnd );    // text bkgnd
    return m_brBkgnd;                 // ctl bkgnd
}

同時我們在.cpp文件中會看到ON_WM_CTLCOLOR_REFLECT(),這就是我們所說的經過處理的宏,是不是很符合規則?
(5)在對話框中加入一個Edit,增加一個關聯的變量,選擇Control屬性,類別爲CMyEdit。
(6)在對話框.cpp文件中加入#include "MyEdit.h",運行,看到了什麼?呵呵。

事情到了一個階段,希望你能夠喜歡,明天見!

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