深度剖析訊息反射機制 (轉)
摘要:在前面我們分析了通知訊息WM_NOTIFY,和WM_NOTIFY緊密聯絡的還有一個MFC新特性:訊息反射。本文中,我想就這個問題作一個全面的論述,如果有錯誤,還望各路大蝦批評指正。
什麼是訊息反射?
在裡面,子控制元件經常向父控制元件傳送訊息,例如很多子控制元件要繪製自己的背景,就可能向父視窗傳送訊息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)在 IDs中,選中相應的類名;
(4)在Messages一欄中找到前面帶有=標記的訊息,那就是反射訊息;
(5)雙擊滑鼠或者單擊新增按鈕,然後OK!
訊息處理的過程
(1)子視窗向父視窗傳送通知訊息,激發父視窗去它的虛擬函式CWnd::OnNotify。大致的結構如下
BOOL CWnd::OnNotify(WPARAM wParam, LPARAM lParam, LRESULT* pResult)
{
if (ReflectLastMsg(hWndCtrl, pResult)) 傳送視窗
return TRUE; 果子視窗已處理了此訊息,返回
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",執行,看到了什麼?呵呵。
事情到了一個階段,希望你能夠喜歡,明天見!
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10752043/viewspace-998024/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 分析與理解訊息反射機制 (轉)反射
- OC訊息機制,訊息轉發機制
- 全面剖析Android訊息機制原始碼Android原始碼
- WTL的訊息機制 (轉)
- 由外到內——剖析Android訊息機制Android
- Windows訊息機制初談 (轉)Windows
- 訊息機制
- iOS 訊息轉發機制Demo解析iOS
- MFC訊息響應機制分析 (轉)
- Java反射機制(轉)Java反射
- 深度解析VC中的訊息傳遞機制(上)
- 深度解析VC中的訊息傳遞機制(下)
- iOS訊息機制iOS
- SAP訊息機制
- Android訊息機制,從Java層到Native層剖析AndroidJava
- iOS進階之訊息轉發機制iOS
- 訊息機制篇——初識訊息與訊息佇列佇列
- JMS java 訊息機制Java
- Windows訊息機制概述Windows
- Android訊息機制Message訊息池Android
- 深入VCL 理解BCB的訊息機制 (一) (轉)
- 深度剖析isinstance的檢查機制
- Rabbitmq可靠訊息投遞,訊息確認機制MQ
- Android訊息傳遞之Handler訊息機制Android
- flutter 訊息傳遞機制Flutter
- android訊息機制—HandlerAndroid
- RabbitMQ 訊息確認機制MQ
- 理解 Android 訊息機制Android
- 重拾 ObjC 訊息機制OBJ
- 簡析Windows訊息機制Windows
- Kafka 訊息儲存機制Kafka
- Android訊息機制HandlerAndroid
- Android 之訊息機制Android
- Handler訊息傳遞機制
- Android的訊息機制Android
- WebRTC中的訊息機制Web
- Android非同步訊息機制Android非同步
- Android訊息機制Handler用法Android