摘要:Windows編程和Dos編程,一個很大的區別就是,Windows編程是事件驅動,消息傳遞的。因此,要學好Windows編程,必須編程
對消息機制有一個清楚的認識,本文但願可以對消息的傳遞作一個全面的分析。windows
1、什麼是消息?數組
消息系統對於一個win32程序來講十分重要,它是一個程序運行的動力源泉。一個消息,是系統定義的一個32位的值,他惟一的定網絡
義了一個事件,向Windows發出一個通知,告訴應用程序某個事情發生了。例如,單擊鼠標、改變窗口尺寸、按下鍵盤上的一個鍵框架
都會使Windows發送一個消息給應用程序。函數
消息自己是做爲一個記錄傳遞給應用程序的,這個記錄中包含了消息的類型以及其餘信息。例如,對於單擊鼠標所產生的消息來字體
說,這個記錄中包含了單擊鼠標時的座標。這個記錄類型叫作MSG,MSG含有來自windows應用程序消息隊列的消息信息,它在ui
Windows中聲明以下: typedef struct tagMsg { HWND hwnd; // 接受該消息的窗口句柄 UINT message; // 消息常量標識符,也就是咱們一般所說的消息號 WPARAM wParam; // 32位消息的特定附加信息,確切含義依賴於消息值 LPARAM lParam; // 32位消息的特定附加信息,確切含義依賴於消息值 DWORD time; // 消息建立時的時間 POINT pt; // 消息建立時的鼠標/光標在屏幕座標系中的位置 }MSG; 消息能夠由系統或者應用程序產生。系統在發生輸入事件時產生消息。舉個例子, 當用戶敲鍵, 移動鼠標或者單擊控件。系統也this
產生消息以響應由應用程序帶來的變化, 好比應用程序改變系統字體,改變窗體大小。應用程序能夠產生消息使窗體執行任務,spa
或者與其餘應用程序中的窗口通信。
2、消息中有什麼? 咱們給出了上面的註釋,是否是會對消息結構有了一個比較清楚的認識?若是尚未,那麼咱們再試着給出下面的解釋:
hwnd 32位的窗口句柄。窗口能夠是任何類型的屏幕對象,由於Win32可以維護大多數可視對象的句柄(窗口、對話框、按鈕、編輯
框等)。 message 用於區別其餘消息的常量值。這些常量能夠是Windows單元中預約義的常量,也能夠是自定義的常量。消息標識符以常量
命名的方式指出消息的含義。當窗口過程接收到消息以後,他就會使用消息標識符來決定如何處理消息。例如、WM_PAINT告訴窗
口過程窗體客戶區被改變了須要重繪。符號常量指定系統消息屬於的類別,其前綴指明瞭處理解釋消息的窗體的類型。 wParam 一般是一個與消息有關的常量值,也多是窗口或控件的句柄。 lParam 一般是一個指向內存中數據的指針。因爲WParam、lParam和Pointer都是32位的,所以,它們之間能夠相互轉換。
3、消息標識符的值
系統保留消息標識符的值在0x0000在0x03ff(WM_USER-1)範圍。這些值被系統定義消息使用。 應用程序不能使用這些值給本身的
消息。
應用程序消息從WM_USER(0X0400)到0X7FFF,或0XC000到0XFFFF;WM_USER到0X7FFF範圍的消息由應用程序本身使用;0XC000到
0XFFFF範圍的消息用來和其餘應用程序通訊,咱們順便說一下具備標誌性的消息值: WM_NULL---0x0000 空消息。 0x0001----0x0087 主要是窗口消息。 0x00A0----0x00A9 非客戶區消息 0x0100----0x0108 鍵盤消息 0x0111----0x0126 菜單消息 0x0132----0x0138 顏色控制消息 0x0200----0x020A 鼠標消息 0x0211----0x0213 菜單循環消息 0x0220----0x0230 多文檔消息 0x03E0----0x03E8 DDE消息 0x0400 WM_USER 0x8000 WM_APP 0x0400----0x7FFF 應用程序自定義私有消息
4、消息有的分類 其實,windows中的消息雖然不少,可是種類並不繁雜,大致上有3種:窗口消息、命令消息和控件通知消息。 窗口消息 大概是系統中最爲常見的消息,它是指由操做系統和控制其餘窗口的窗口所使用的消息。例如CreateWindow、
DestroyWindow和MoveWindow等都會激發窗口消息,還有咱們在上面談到的單擊鼠標所產生的消息也是一種窗口消息。 命令消息 這是一種特殊的窗口消息,他用來處理從一個窗口發送到另外一個窗口的用戶請求,例如按下一個按鈕,他就會向主窗口
發送一個命令消息。 控件通知消息 是指這樣一種消息,一個窗口內的子控件發生了一些事情,須要通知父窗口。通知消息只適用於標準的窗口控件如
按鈕、列表框、組合框、編輯框,以及Windows公共控件如樹狀視圖、列表視圖等。例如,單擊或雙擊一個控件、在控件中選擇部
分文本、操做控件的滾動條都會產生通知消息。 她相似於命令消息,當用戶與控件窗口交互時,那麼控件通知消息就會從控件窗
口發送到它的主窗口。可是這種消息的存在並非爲了處理用戶命令,而是爲了讓主窗口可以改變控件,例如加載、顯示數據。
例如按下一個按鈕,他向父窗口發送的消息也能夠看做是一個控件通知消息;單擊鼠標所產生的消息能夠由主窗口直接處理,然
後交給控件窗口處理。 其中窗口消息及控件通知消息主要由窗口類(即直接或間接由CWND類派生類)處理。相對窗口消息及控件通知消息而言,命令消
息的處理對象範圍就廣得多,它不只能夠由窗口類處理,還能夠由文檔類,文檔模板類及應用類所處理。 因爲控件通知消息很重要的,人們用的也比較多,可是具體的含義每每令初學者暈頭轉向,因此我決定把常見的幾個列出來供大
家參考: 按扭控件 BN_CLICKED 用戶單擊了按鈕 BN_DISABLE 按鈕被禁止 BN_DOUBLECLICKED 用戶雙擊了按鈕 BN_HILITE 用/戶加亮了按鈕 BN_PAINT 按鈕應當重畫 BN_UNHILITE 加亮應當去掉 組合框控件 CBN_CLOSEUP 組合框的列表框被關閉 CBN_DBLCLK 用戶雙擊了一個字符串 CBN_DROPDOWN 組合框的列表框被拉出 CBN_EDITCHANGE 用戶修改了編輯框中的文本 CBN_EDITUPDATE 編輯框內的文本即將更新 CBN_ERRSPACE 組合框內存不足 CBN_KILLFOCUS 組合框失去輸入焦點 CBN_SELCHANGE 在組合框中選擇了一項 CBN_SELENDCANCEL 用戶的選擇應當被取消 CBN_SELENDOK 用戶的選擇是合法的 CBN_SETFOCUS 組合框得到輸入焦點 編輯框控件 EN_CHANGE 編輯框中的文本己更新 EN_ERRSPACE 編輯框內存不足 EN_HSCROLL 用戶點擊了水平滾動條 EN_KILLFOCUS 編輯框正在失去輸入焦點 EN_MAXTEXT 插入的內容被截斷 EN_SETFOCUS 編輯框得到輸入焦點 EN_UPDATE 編輯框中的文本將要更新 EN_VSCROLL 用戶點擊了垂直滾動條消息含義 列表框控件 LBN_DBLCLK 用戶雙擊了一項 LBN_ERRSPACE 列表框內存不夠 LBN_KILLFOCUS 列表框正在失去輸入焦點 LBN_SELCANCEL 選擇被取消 LBN_SELCHANGE 選擇了另外一項 LBN_SETFOCUS 列表框得到輸入焦點
5、隊列消息和非隊列消息 從消息的發送途徑來看,消息能夠分紅2種:隊列消息和非隊列消息。消息隊列又能夠分紅系統消息隊列和線程消息隊列。
系統消息隊列由Windows維護,線程消息隊列則由每一個GUI線程本身進行維護,爲避免給non-GUI現成建立消息隊列,全部線程產生
時並無消息隊列,僅當線程第一次調用GDI函數時,系統給線程建立一個消息隊列。隊列消息送到系統消息隊列,而後到線程消
息隊列;非隊列消息直接送給目的窗口過程。 對於隊列消息,最多見的是鼠標和鍵盤觸發的消息,例如WM_MOUSERMOVE,WM_CHAR等消息,還有一些其它的消息,例如:WM_PAINT
、WM_TIMER和WM_QUIT。當鼠標、鍵盤事件被觸發後,相應的鼠標或鍵盤驅動程序就會把這些事件轉換成相應的消息,而後輸送到
系統消息隊列,由Windows系統去進行處理。Windows系統則在適當的時機,從系統消息隊列中取出一個消息,根據前面咱們所說
的MSG消息結構肯定消息是要被送往那個窗口,而後把取出的消息送往建立窗口的線程的相應隊列,下面的事情就該由線程消息隊
列操心了,Windows開始忙本身的事情去了。線程看到本身的消息隊列中有消息,就從隊列中取出來,經過操做系統發送到合適的
窗口過程去處理。 通常來說,系統老是將消息Post在消息隊列的末尾。這樣保證窗口以先進先出的順序接受消息。然而,WM_PAINT是一個例外,同一
個窗口的多個 WM_PAINT被合併成一個 WM_PAINT 消息, 合併全部的無效區域到一個無效區域。合併WM_PAIN的目的是爲了減小刷
新窗口的次數。 非隊列消息將會繞過系統消息隊列和線程消息隊列,直接將消息發送到窗口過程。系統發送非隊列消息通知窗口。例如,當用戶激
活一個窗口,系統發送WM_ACTIVATE, WM_SETFOCUS, and WM_SETCURSOR。這些消息通知窗口它被激活了。非隊列消息也能夠由當
應用程序調用系統函數產生。例如,當程序調用SetWindowPos,系統發送WM_WINDOWPOSCHANGED消息。一些函數也發送非隊列消息
,例以下面咱們要談到的函數。
6、消息的發送 瞭解了上面的這些基礎理論以後,咱們就能夠進行一下簡單的消息發送與接收。 把一個消息發送到窗口有3種方式:發送、寄送和廣播。 發送消息的函數有SendMessage、SendMessageCallback、SendNotifyMessage、SendMessageTimeout;寄送消息的函數主要有
PostMessage、PostThreadMessage、PostQuitMessage;廣播消息的函數我知道的只有BroadcastSystemMessage、
BroadcastSystemMessageEx。
SendMessage的原型以下:
LRESULT SendMessage(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam)
這個函數主要是向一個或多個窗口發送一條消息,一直等到消息被處理以後纔會返回。不過須要注意的是,若是接收消息的窗口
是同一個應用程序的一部分,那麼這個窗口的窗口函數就被做爲一個子程序立刻被調用;若是接收消息的窗口是被另外的線程所
建立的,那麼窗口系統就切換到相應的線程而且調用相應的窗口函數,這條消息不會被放進目標應用程序隊列中。函數的返回值
是由接收消息的窗口的窗口函數返回,返回的值取決於被髮送的消息。
PostMessage的原型以下:
BOOL PostMessage(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam)該函數把一條消息放置到建立hWnd窗口的線程的消息
隊列中,該函數不等消息被處理就立刻將控制返回。須要注意的是,若是hWnd參數爲HWND_BROADCAST,那麼,消息將被寄送給系
統中的全部的重疊窗口和彈出窗口,可是子窗口不會收到該消息;若是hWnd參數爲NULL,則該函數相似於將dwThreadID參數設置
成當前線程的標誌來調用PostThreadMEssage函數。 從上面的這2個具備表明性的函數,咱們能夠看出消息的發送方式和寄送方式的區別所在:被髮送的消息是否會被當即處理,函數
是否當即返回。被髮送的消息會被當即處理,處理完畢後函數纔會返回;被寄送的消息不會被當即處理,他被放到一個先進先出
的隊列中,一直等到應用程序空閒的時候纔會被處理,不過函數放置消息後當即返回。 實際上,發送消息到一個窗口處理過程和直接調用窗口處理過程之間並無太大的區別,他們直接的惟一區別就在於你能夠要求
操做系統截獲全部被髮送的消息,可是不可以截獲對窗口處理過程的直接調用。 以寄送方式發送的消息一般是與用戶輸入事件相對應的,由於這些事件不是十分緊迫,能夠進行緩慢的緩衝處理,例如鼠標、鍵
盤消息會被寄送,而按鈕等消息則會被髮送。 廣播消息用得比較少,BroadcastSystemMessage函數原型以下: long BroadcastSystemMessage(DWORD dwFlags, LPDWORD lpdwRecipients, UINT uiMessage, WPARAM wParam, LPARAM lParam); 該函數能夠向指定的接收者發送一條消息,這些接收者能夠是應用程序、可安裝的驅動程序、網絡驅動程序、系統級別的設備驅
動消息和他們的任意組合。須要注意的是,若是dwFlags參數是BSF_QUERY而且至少一個接收者返回了BROADCAST_QUERY_DENY,則
返回值爲0,若是沒有指定BSF_QUERY,則函數將消息發送給全部接收者,而且忽略其返回值。
7、消息的接收 消息的接收主要有3個函數:GetMessage、PeekMessage、WaitMessage。 GetMessage原型以下:BOOL GetMessage(LPMSG lpMsg, HWND hWnd, UINT wMsgFilterMin, UINT wMsgFilterMax);
該函數用來獲取與hWnd參數所指定的窗口相關的且wMsgFilterMin和wMsgFilterMax參數所給出的消息值範圍內的消息。須要注意
的是,若是hWnd爲NULL,則GetMessage獲取屬於調用該函數應用程序的任一窗口的消息,若是wMsgFilterMin和wMsgFilterMax都
是0,則GetMessage就返回全部可獲得的消息。函數獲取以後將刪除消息隊列中的除WM_PAINT消息以外的其餘消息,至於
WM_PAINT則只有在其處理以後才被刪除。
PeekMessage原型以下:BOOL PeekMessage(LPMSG lpMsg, HWND hWnd, UINT wMsgFilterMin, UINT wMsgFilterMax, UINT
wRemoveMsg); 該函數用於查看應用程序的消息隊列,若是其中有消息就將其放入lpMsg所指的結構中,不過,與GetMessage不一樣的是,
PeekMessage函數不會等到有消息放入隊列時才返回。一樣,若是hWnd爲NULL,則PeekMessage獲取屬於調用該函數應用程序的任
一窗口的消息,若是hWnd=-1,那麼函數只返回把hWnd參數爲NULL的PostAppMessage函數送去的消息。若是wMsgFilterMin和
wMsgFilterMax都是0,則PeekMessage就返回全部可獲得的消息。函數獲取以後將刪除消息隊列中的除WM_PAINT消息以外的其餘
消息,至於WM_PAINT則只有在其處理以後才被刪除。 WaitMessage原型以下:BOOL VaitMessage();
當一個應用程序無事可作時,該函數就將控制權交給另外的應用程序,同時將該應用程序掛起,直到一個新的消息被放入應用程
序的隊列之中才返回。
8、消息的處理 接下來咱們談一下消息的處理,首先咱們來看一下VC中的消息泵: while(GetMessage(&msg, NULL, 0, 0)) { if(!TranslateAccelerator(msg.hWnd, hAccelTable, &msg)) { TranslateMessage(&msg); DispatchMessage(&msg); } }
首先,GetMessage從進程的主線程的消息隊列中獲取一個消息並將它複製到MSG結構,若是隊列中沒有消息,則GetMessage函數將
等待一個消息的到來之後才返回。 若是你將一個窗口句柄做爲第二個參數傳入GetMessage,那麼只有指定窗口的消息能夠從隊列
中得到。GetMessage也能夠從消息隊列中過濾消息,只接受消息隊列中落在範圍內的消息。這時候就要利用GetMessage/
PeekMessage指定一個消息過濾器。這個過濾器是一個消息標識符的範圍或者是一個窗體句柄,或者二者同時指定。當應用程序要
查找一個後入消息隊列的消息是頗有用。WM_KEYFIRST 和 WM_KEYLAST 常量用於接受全部的鍵盤消息。 WM_MOUSEFIRST 和
WM_MOUSELAST 常量用於接受全部的鼠標消息。 而後TranslateAccelerator判斷該消息是否是一個按鍵消息而且是一個加速鍵消息,若是是,則該函數將把幾個按鍵消息轉換成
一個加速鍵消息傳遞給窗口的回調函數。處理了加速鍵以後,函數TranslateMessage將把兩個按鍵消息WM_KEYDOWN和WM_KEYUP轉
換成一個WM_CHAR,不過須要注意的是,消息WM_KEYDOWN,WM_KEYUP仍然將傳遞給窗口的回調函數。
處理完以後,DispatchMessage函數將把此消息發送給該消息指定的窗口中已設定的回調函數。若是消息是WM_QUIT,則
GetMessage返回0,從而退出循環體。應用程序可使用PostQuitMessage來結束本身的消息循環。一般在主窗口的WM_DESTROY消
息中調用。
下面咱們舉一個常見的小例子來講明這個消息泵的運用: if (::PeekMessage(&msg, m_hWnd, WM_KEYFIRST,WM_KEYLAST, PM_REMOVE)) { if (msg.message == WM_KEYDOWN && msg.wParam == VK_ESCAPE)... }
這裏咱們接受全部的鍵盤消息,因此就用WM_KEYFIRST 和 WM_KEYLAST做爲參數。最後一個參數能夠是PM_NOREMOVE 或者
PM_REMOVE,表示消息信息是否應該從消息隊列中刪除。 因此這段小代碼就是判斷是否按下了Esc鍵,若是是就進行處理。
9、窗口過程 窗口過程是一個用於處理全部發送到這個窗口的消息的函數。任何一個窗口類都有一個窗口過程。同一個類的窗口使用一樣的窗
口過程來響應消息。
系統發送消息給窗口過程將消息數據做爲參數傳遞給他,消息到來以後,按照消息類型排序進行處理,其中的參數則用來區分不
同的消息,窗口過程使用參數產生合適行爲。 一個窗口過程不常常忽略消息,若是他不處理,它會將消息傳回到執行默認的處理。窗口過程經過調用DefWindowProc來作這個處
理。窗口過程必須return一個值做爲它的消息處理結果。大多數窗口只處理小部分消息和將其餘的經過DefWindowProc傳遞給系統
作默認的處理。窗口過程被全部屬於同一個類的窗口共享,能爲不一樣的窗口處理消息。下面咱們來看一下具體的實例:
LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) { int wmId, wmEvent; PAINTSTRUCT ps; HDC hdc; TCHAR szHello[MAX_LOADSTRING]; LoadString(hInst, IDS_HELLO, szHello, MAX_LOADSTRING);
switch (message) { case WM_COMMAND: wmId = LOWORD(wParam); wmEvent = HIWORD(wParam); // Parse the menu selections: switch (wmId) { case IDM_ABOUT: DialogBox(hInst, (LPCTSTR)IDD_ABOUTBOX, hWnd, (DLGPROC)About); break; case IDM_EXIT: DestroyWindow(hWnd); break; default: return DefWindowProc(hWnd, message, wParam, lParam); } break; case WM_PAINT: hdc = BeginPaint(hWnd, &ps); // TODO: Add any drawing code here... RECT rt; GetClientRect(hWnd, &rt); DrawText(hdc, szHello, strlen(szHello), &rt, DT_CENTER); EndPaint(hWnd, &ps); break; case WM_DESTROY: PostQuitMessage(0); break; default: return DefWindowProc(hWnd, message, wParam, lParam); } return 0;
}
消息分流器 一般的窗口過程是經過一個switch語句來實現的,這個事情很煩,有沒有更簡便的方法呢?有,那就是消息分流器,利用消息分
流器,咱們能夠把switch語句分紅更小的函數,每個消息都對應一個小函數,這樣作的好處就是對消息更容易管理。 之因此被稱爲消息分流器,就是由於它能夠對任何消息進行分流。下面咱們作一個函數就很清楚了: void MsgCracker(HWND hWnd,int id,HWND hWndCtl,UINT codeNotify) { switch(id) { case ID_A: if(codeNotify==EN_CHANGE)... break; case ID_B: if(codeNotify==BN_CLICKED)... break; .... } } 而後咱們修改一下窗口過程:
LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) { switch(message) { HANDLE_MSG(hWnd,WM_COMMAND,MsgCracker); HANDLE_MSG(hWnd,WM_DESTROY,MsgCracker); default: return DefWindowProc(hWnd, message, wParam, lParam); } return 0; } 在WindowsX.h中定義了以下的HANDLE_MSG宏: #define HANDLE_MSG(hwnd,msg,fn) \ switch(msg): return HANDLE_##msg((hwnd),(wParam),(lParam),(fn)); 實際上,HANDLE_WM_XXXX都是宏,例如:HANDLE_MSG(hWnd,WM_COMMAND,MsgCracker);將被轉換成以下定義: #define HANDLE_WM_COMMAND(hwnd,wParam,lParam,fn)\ ((fn)((hwnd),(int)(LOWORD(wParam)),(HWND)(lParam),(UINT)HIWORD(wParam)),0L); 好了,事情到了這一步,應該一切都明朗了。 不過,咱們發如今windowsx.h裏面還有一個宏:FORWARD_WM_XXXX,咱們仍是那WM_COMMAND爲例,進行分析: #define FORWARD_WM_COMMAND(hwnd, id, hwndCtl, codeNotify, fn) \ (void)(fn)((hwnd), WM_COMMAND, MAKEWPARAM((UINT)(id),(UINT)(codeNotify)), (LPARAM)(HWND)(hwndCtl)) 因此實際上,FORWARD_WM_XXXX將消息參數進行了從新構造,生成了wParam && lParam,而後調用了咱們定義的函數。
10、MFC消息的處理實現方式 初看MFC中的各類消息,以及在頭腦中根深蒂固的C++的影響,咱們可能很天然的就會想到利用C++的三大特性之一:虛擬機制來實
現消息的傳遞,可是通過分析,咱們看到事情並非想咱們想象的那樣,
在MFC中消息是經過一種所謂的消息映射機制來處理的。 爲何呢?在潘愛民老師翻譯的《Visual C++技術內幕》(第4版)中給出了詳細的緣由說明,我再簡要的說一遍。在CWnd類中大
約有110個消息,還有其它的MFC的類呢,算起來消息太多了,在C++中對程序中用到的每個派生類都要有一個vtable,每個虛
函數在vtable中都要佔用一個4字節大小的入口地址,這樣一來,對於每一個特定類型的窗口或控件,應用程序都須要一個440KB大
小的表來支持虛擬消息控件函數。 若是說上面的窗口或控件能夠勉強實現的話,那麼對於菜單命令消息及按鈕命令消息呢?由於不一樣的應用程序有不一樣的菜單和按
鈕,咱們怎麼處理呢?在MFC庫的這種消息映射系統就避免了使用大的vtable,而且可以在處理常規Windows消息的同時處理各類
各樣的應用程序的命令消息。 說白了,MFC中的消息機制其實質是一張巨大的消息及其處理函數的一一對應表,而後加上分析處理這張表的應用框架內部的一些
程序代碼。這樣就能夠避免在SDK編程中用到的繁瑣的CASE語句。
MFC的消息映射的基類CCmdTarget 若是你想讓你的控件可以進行消息映射,就必須從CCmdTarget類中派生。CCmdTarget類是MFC處理命令消息的基礎、核心。MFC爲
該類設計了許多成員函數和一些成員數據,基本上是爲了解決消息映射問題的,全部響應消息或事件的類都從它派生,例如:應
用程序類、框架類、文檔類、視圖類和各類各樣的控件類等等,還有不少。 不過這個類裏面有2個函數對消息映射很是重要,一個是靜態成員函數DispatchCmdMsg,另外一個是虛函數OnCmdMsg。 DispatchCmdMsg專門供MFC內部使用,用來分發Windows消息。OnCmdMsg用來傳遞和發送消息、更新用戶界面對象的狀態。 CCmdTarget對OnCmdMsg的默認實現:在當前命令目標(this所指)的類和基類的消息映射數組裏搜索指定命令消息的消息處理函數
。 這裏使用虛擬函數GetMessageMap獲得命令目標類的消息映射入口數組_messageEntries,而後在數組裏匹配命令消息ID相同、控
制通知代碼也相同的消息映射條目。其中GetMessageMap是虛擬函數,因此能夠確認當前命令目標的確切類。 若是找到了一個匹配的消息映射條目,則使用DispachCmdMsg調用這個處理函數; 若是沒有找到,則使用_GetBaseMessageMap獲得基類的消息映射數組,查找,直到找到或搜尋了全部的基類(到CCmdTarget)爲
止;若是最後沒有找到,則返回FASLE。 每一個從CCmdTarget派生的命令目標類均可以覆蓋OnCmdMsg,利用它來肯定是否能夠處理某條命令,若是不能,就經過調用下一命
令目標的OnCmdMsg,把該命令送給下一個命令目標處理。一般,派生類覆蓋OnCmdMsg時 ,要調用基類的被覆蓋的OnCmdMsg。 在MFC框架中,一些MFC命令目標類覆蓋了OnCmdMsg,如框架窗口類覆蓋了該函數,實現了MFC的標準命令消息發送路徑。必要的話
,應用程序也能夠覆蓋OnCmdMsg,改變一個或多個類中的發送規定,實現與標準框架發送規定不一樣的發送路徑。例如,在如下情
況能夠做這樣的處理:在要打斷髮送順序的類中把命令傳給一個非MFC默認對象;在新的非默認對象中或在可能要傳出命令的命令
目標中。
消息映射的內容 經過ClassWizard爲咱們生成的代碼,咱們能夠看到,消息映射基本上分爲2大部分:
在頭文件(.h)中有一個宏DECLARE_MESSAGE_MAP(),他被放在了類的末尾,是一個public屬性的;與之對應的是在實現部分
(.cpp)增長了一張消息映射表,內容以下: BEGIN_MESSAGE_MAP(當前類, 當前類的基類) file://{{AFX_MSG_MAP(CMainFrame) 消息的入口項 file://}}AFX_MSG_MAP END_MESSAGE_MAP() 可是僅有這兩項還遠不足以完成一條消息,要使一個消息工做,必須有如下3個部分去協做: 1.在類的定義中加入相應的函數聲明; 2.在類的消息映射表中加入相應的消息映射入口項; 3.在類的實現中加入相應的函數體;
消息的添加 有了上面的這些只是做爲基礎,咱們接下來就作咱們最熟悉、最經常使用的工做:添加消息。
MFC消息的添加主要有2種方法:自動/手動,咱們就以這2種方法爲例,說一下如何添加消息。 一、利用Class Wizard實現自動添加 在菜單中選擇View-->Class Wizard,也能夠用單擊鼠標右鍵,選擇Class Wizard,一樣能夠激活Class Wizard。選擇Message
Map標籤,從Class name組合框中選取咱們想要添加消息的類。在Object IDs列表框中,選取類的名稱。此時, Messages列表框
顯示該類的大多數(若不是所有的話)可重載成員函數和窗口消息。類重載顯示在列表的上部,以實際虛構成員函數的大小寫字母
來表示。其餘爲窗口消息,以大寫字母出現,描述了實際窗口所能響應的消息ID。選中咱們向添加的消息,單擊Add Function按
鈕,Class Wizard自動將該消息添加進來。 有時候,咱們想要添加的消息本應該出如今Message列表中,但是就是找不到,怎麼辦?不要着急,咱們能夠利用Class Wizard上
Class Info標籤以擴展消息列表。在該頁中,找到Message Filter組合框,經過它能夠改變首頁中Messages列表框中的選項。這
裏,咱們選擇Window,從而顯示全部的窗口消息,一把狀況下,你想要添加的消息就能夠在Message列表框中出現了,若是尚未
,那就接着往下看:)
二、手動地添加消息處理函數 若是在Messages列表框中仍然看不到咱們想要的消息,那麼該消息多是被系統忽略掉或者是你本身建立的,在這種狀況下,就
必須本身手工添加。根據咱們前面所說的消息工做的3個部件,咱們一一進行處理: 1) 在類的. h文件中添加處理函數的聲明,緊接在//}}AFX_MSG行以後加入聲明,注意:必定要以afx_msg開頭。 一般,添加處理函數聲明的最好的地方是源代碼中Class Wizard維護的表下面,可是在它標記其領域的{{}}括弧外面。這些
括弧中的任何東西都將會被Class Wizard銷燬。 2) 接着,在用戶類的.cpp文件中找到//}}AFX_MSG_MAP行,緊接在它以後加入消息入口項。一樣,也是放在{ {} }的外面
3) 最後,在該文件中添加消息處理函數的實體