訊息反射

return return dChildNotifyLastMsg

訊息反射的基礎知識

1、訊息反射解釋:

 父視窗將控制子視窗發給它的通知訊息,首先反射回子視窗進行處理(即給控制子視窗一個機會,讓控制子視窗處理此訊息),這樣通知訊息就有機會能被子視窗自身進行處理。

2、MFC中引入訊息反射的原因:

 在Windows的訊息處理中,控制子視窗的發給其父視窗的通知訊息只能由其父視窗進行處理,這使得控制子視窗的自身能動性大大降低(你想,它連改變自己的背景色,處理一個自身滾動問題都要其父視窗來完成),為了解決這個問題,在MFC中引入了反射訊息“Reflect Message”的概念,進行訊息反射,可以使得控制子視窗能夠自行處理與自身相關的一些訊息,增強了封裝性,從而提高了控制子視窗的可重用性。

3、訊息反射的處理流程(不考慮OLE控制)

 一、訊息反射處理流程圖:
1、父視窗收到控制子視窗發來的通知訊息後,調用它的虛函式CWnd::OnNotify.
CWnd::OnNotIFY()主體部分:
{
if (ReflectLastMsg(hWndCtrl, pResult)) //此時,hWndCtrl,為傳送視窗,即子視窗的句柄
return TRUE; // 子視窗已處理了此訊息
AFX_NOTIFY notify;
notify.pResult = pResult;
notify.pNMHDR = pNMHDR;
return OnCmdMsg(nID, MAKELONG(nCode, WM_NOTIFY), ¬ify, NULL);
}
分析:首先,調用ReflectLastMsg(hCtrlChildWnd,...)給子視窗一個自身處理的機會,將訊息反射給子視窗處理,函式返回TRUE,表明子視窗處理了此訊息。反之,表示子視窗未處理此訊息,此時,調用OnCmdMsg(...)由父視窗進行通常的處理。
2、ReflectLastMsg中:
主要是調用傳送視窗的SendChildNotifyLastMsg(...)。
3、SendChildNotifyLastMsg 中:
調用傳送視窗的虛函式OnChildNotify函式,進行處理。 如果沒有處理,則調用ReflectChildNotify(...)函式進行標準的反射訊息的訊息映射處理。
二、訊息處理
方式1:
由上述處理流程可以看出來,子視窗要想自身處理此訊息,重載子控制項視窗的OnChildNotify虛擬函式應該是很容易想到的方式。
注意:MFC中對各個子控制項視窗一般都已經重載了OnChildNotify函式,它對應調用類的虛函式進行處理,所以,你重載對應的虛函式即可,如下例:
BOOL CStatusBarCtrl::OnChildNotify(UINT message, WPARAM wParam, LPARAM lParam,LRESULT* pResult)
{
if (message != WM_DRAWITEM) //對應不同的控制,會有不同的有特殊處理要求的訊息。
return CWnd::OnChildNotify(message, wParam, lParam, pResult);
...
...
DrawItem((LPDRAWITEMSTRUCT)lParam);
return TRUE;
}
virtual void DrawItem( LPDRAWITEMSTRUCT lpDrawItemStruct );
void CStatusBarCtrl::DrawItem(LPDRAWITEMSTRUCT)
{
ASSERT(FALSE); // must override for self draw status bars
}
你重載CStatusBarCtrl類的DrawItem虛擬函式,即可實現對反射訊息WM_DRAWITEM的處理。
方式2:
從方式1可以看出,如果你不在被重載的OnChildNotify中對訊息進行處理,函式會調用CWnd::OnChildNotify,它調用ReflectChildNotify函式進行標準的處理。
1、增加反射訊息的映射入口。
2、增加對應的訊息處理函式。
注意:可以使用MFC的ClassWizard作上述動作,在ClassWizard中,可處理的反射訊息以一個"="號以示區別。返回值為TRUE,表示控制項視窗已處理此反射訊息,為FALSE,表示控制項子視窗未處理此反射訊息。
結語:
訊息反射不是很難的概念。它僅出現在MFC中;它的用意是方便控制子視窗的重用;對某些通知訊息你可以重載對應的虛函式(WM_DRAWITEM...)進行處理;對其它你可以使用標準的訊息反射映射進行處理。限於篇幅,一些細節問題,請閱讀MFC中對應的原始碼
什麼是訊息反射?
在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",運行。

相關詞條

熱門詞條

聯絡我們