Windows操作系統(tǒng)采用消息驅(qū)動機(jī)制，即以消息來驅(qū)動應(yīng)用程序的運(yùn)行。如果說窗口是用戶操作的接口，消息就是流過這個(gè)接口的血液。MFC的消息映射與處理機(jī)制是其精華所在，相比之下其他語言如c#、VB等提供給開發(fā)者的消息處理方式顯得格外局促和僵化。

MFC中的窗口封裝類CWnd為各種窗口消息定義了對應(yīng)的虛擬函數(shù)（如OnkeyDown(),Onpaint()等），而一個(gè)消息處理調(diào)度函數(shù)WindowProc()為響應(yīng)各種窗口消息，調(diào)用相應(yīng)的虛擬函數(shù)進(jìn)行處理，例如WM_KEYDOWN消息到來，就調(diào)用Onkeydown()虛函數(shù)進(jìn)行處理。如果派生類需要特殊處理某個(gè)消息（系類的處理不能滿足需要），重載相應(yīng)的虛函數(shù)即可。這種消息處理機(jī)制在MFC沒有誕生之前，被認(rèn)為是顯而易見的。

但這種處理機(jī)制存在明顯的缺陷。因?yàn)槿绻惗x了虛擬函數(shù)，系統(tǒng)要為基類和每個(gè)派生類分別建立一張?zhí)摂M函數(shù)表，其中每個(gè)虛擬函數(shù)有4字節(jié)的入口地址，無論派生類是否重載了某個(gè)虛函數(shù)。要為100個(gè)以上的窗口消息都定義相應(yīng)的虛函數(shù)，成本是可觀的。另外，不可能為所有菜單、按鈕的命令消息都定義處理函數(shù)，并且控件的通知消息、反射消息也是不可以預(yù)知的。在這種機(jī)制下，處理不可預(yù)知的命令和通知消息，只能像WIN32API編程那樣，使用繁瑣的switch-case語句。所以，由于以上種種原因，MFC沒有采用虛擬函數(shù)機(jī)制，而是新創(chuàng)了所謂的消息映射機(jī)制。

消息映射就是在基類中建立一張窗口消息和消息處理函數(shù)的映射表（以數(shù)組形式存儲），將大部分窗口消息和處理消息的對應(yīng)關(guān)系存儲在該表中。注意，這些處理函數(shù)雖然也是基類為每個(gè)窗口消息分別定義的，但是他們并不是虛函數(shù)。基類（如CWnd）為大部分窗口消息定義了處理函數(shù)，并建立了二者之間的映射關(guān)系，這些處理函數(shù)通常對消息進(jìn)行常規(guī)處理或默認(rèn)處理。而派生類的初始消息映射表是空的，如果派生類需要對某個(gè)消息進(jìn)行特殊處理，它可以定義一個(gè)新的消息處理函數(shù)，并在自己的映射表中添加一項(xiàng)，存儲該消息和該函數(shù)的對應(yīng)關(guān)系。這里也有一個(gè)消息處理跳讀函數(shù)，它是CWnd::OnWndMsg()。針對某個(gè)消息，該函數(shù)首先在當(dāng)前派生類的消息映射表中尋找對應(yīng)的處理函數(shù)，不成功就向上尋找父類的映射表，直到成功或者搜索完基類為止。如果最終沒有發(fā)現(xiàn)對應(yīng)的處理函數(shù)，則執(zhí)行系統(tǒng)級的默認(rèn)處理。

基類沒有為命令、通知等不可預(yù)知的消息定義處理函數(shù)，但是能夠根據(jù)需要，將他們添加在派生類的消息映射表中。當(dāng)消息到來時(shí)，存儲在該表中的相應(yīng)處理函數(shù)的入口地址（函數(shù)指針）就被提取、調(diào)用。
雖然建立消息映射表的方法顯得機(jī)械，但這些機(jī)械的工作可以由類向?qū)硗瓿?#xff0c;類向?qū)Р粌H能夠建立消息映射項(xiàng)目，還能為消息處理函數(shù)生成框架。只有少數(shù)類向?qū)Р恢С值拇翱谙⒒蜃远x消息，才必須勞煩程序員動手。

總結(jié)

以上是生活随笔為你收集整理的MFC的消息映射的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。