MFC六大关键技术
2012-09-06 14:58 1272人閱讀 評論(0) 收藏 舉報 mfccommandnullclasspascal編程 MFC六大關鍵技術之初始化過程 我并不認為MFC減輕了程序員們的負擔，MFC出現的目的雖然似乎是為了讓程序員不用懂得太多就可以進行視窗編程，但本人在MFC里徘徊了很久很久（因為那時沒有書本詳細介紹MFC的原理），毫無收獲。可能朋友們會說，怎么一定要了解MFC的具體呢，“黑箱”作業不行嗎？這不是微軟的初衷嗎？
不行！！！如果這樣，我寧愿永遠不選擇MFC！在學電腦之前，本人學習的東西大都與藝術不無關系，小學時參加過全國書畫比賽獲銀獎。兒時的愛好就是在一張紙上隨心所欲地畫畫！MFC“黑箱”就象一幅碩大的抽象畫（抽象到你不能理解），它用鉛筆勾畫好線條，然后請你填顏色。
我們怎么能忍受“黑箱”作業？我們選擇C++，就是因為它夠自由，夠藝術，我們可以在此放飛幻想。所以，我們要攻克MFC。
偉大孫老師在剖析MFC的時候雖然盡心盡力，但可能由于篇幅所限，說得并不大清楚（我相信許多學員都有這方面的感受）。在此，我突發奇想，想與大家一同分享一下著名的MFC六大關鍵技術。
從什么地方開始講起好呢？我覺得回到最初摸索MFC的時候，從基本談起最好。
因為我知道，一個走過來程序員，總是忘記了當初自己是怎么走過來的，忘記了一個學員最想知道的是什么。一個小小的問題（一兩句話就可以解釋的），足學以令手無寸鐵的學員頭大半個月，所以，我努力回憶當初是怎么讓自己豁然開朗的。
轉入正題，MFC的六大關鍵技術包括：
·MFC程序的初始化過程
·運行時類型識別（RTTI）
·動態創建
·永久保存
·消息映射
·消息傳遞
MFC程序的初始化過程
1、設計一個簡單完整MFC程序，產生一個窗口。當然這不能讓AppWizard自動為我們生成。我們可以在Win32 Application工程下面那樣寫：
| #include ＜afxwin.h＞ class MyApp : public CWinApp { public: BOOL InitInstance() //②程序入點 { CFrameWnd *Frame=new CFrameWnd();//構造框架 m_pMainWnd=Frame; //將m_pMainWnd設定為Frame; Frame-＞Create(NULL,"最簡單的窗口");//建立框架 Frame-＞ShowWindow(SW_SHOW); //顯示框架 return true; //返回 } }; MyApp theApp; //①建立應用程序。 |
設定鏈接MFC庫，運行，即可看見一個窗口。
從上面，大家可以看到建立一個MFC窗口很容易，只用兩步：一是從CWinApp派生一個應用程序類（這里是MyApp），,然后建立應用程序對象（theApp），就可以產生一個自己需要的窗口(即需要什么樣就在InitInstance()里創建就行了)。
整個程序，就改寫一個InitInstance()函數，創建那么一個對象（theApp）,就是一個完整的窗口程序。這就是“黑箱”作業的魅力！！！！
在我們正想為微軟鼓掌的時候，我們突然覺得心里空蕩蕩的，我們想知道微軟幫我們做了什么事情，而我們想編自己的程序時又需要做什么事情，那怕在上面幾行的程序里面，我們還有不清楚的地方，比如，干嘛有一個m_pMainWnd指針變量，它從哪里來，又要到哪里去呢？想一想在DOS下編程是多么美妙的一件事呵，我們需要什么變量，就聲明什么變量，需要什么樣的函數，就編寫什么樣的函數，或者引用函數庫……但是現在我們怎么辦！！！
我們可以逆向思維一下，MFC要達到這種效果，它是怎么做的呢？首先我們要弄明白，VC不是一種語言，它就象我們學c語言的時候的一個類似記事本的編輯器（請原諒我的不貼切的比喻），所以，在VC里面我們用的是C++語言編程，C++才是根本（初學者總是以為VC是一門什么新的什么語言，一門比C++先進很多的復雜語言，汗）。說了那么多，我想用一句簡單的話概括“MFC‘黑箱’就是幫助我們插入了‘C++代碼’的東西”。
既然MFC黑箱幫我們插入了代碼，那么大家想想它會幫我們插入什么樣的代碼呢？他會幫我們插入求解一元二次方程的代碼嗎？當然不會，所以它插入的實際上是每次編寫窗口程序必須的，通用的代碼。
再往下想，什么才是通用的呢？我們每次視窗編程都要寫WinMain()函數，都要有注冊窗口，產生窗口，消息循環，回調函數……即然每次都要的東西，就讓它們從我們眼前消失，讓MFC幫忙寫入！
要知道MFC初始化過程，大家當然可以跟蹤執行程序。孫老師的第三課跟蹤了很長一段時間，我相信大家都有點暈頭轉向。本人覺得那怕你理解了MFC代碼，也很容易讓人找不著北，我們完全不懂的時候，在成千上萬行程序的迷宮中如何能找到出口？
我們要換一種方法，不如就來重新編寫個MFC庫吧，嘩！大家不要笑，小心你的大牙，我不是瘋子（雖然瘋子也說自己不瘋）。我們要寫的就是最簡單的MFC類庫，就是把MFC宏觀上的，理論上的東西寫出來。我們要用最簡化的代碼，簡化到剛好能運行。
既然，我們這一節寫的是MFC程序的初始化過程，上面我們還有了一個可執行的MFC程序。程序中只是用了兩個MFC類，一個是CWinApp,另一個是CFrameWnd。當然，還有很多同樣重要MFC類如視圖類，文檔類等等。但在上面的程序可以不用到，所以暫時省去了它（總之是為了簡單）。
好，現在開始寫MFC類庫吧……唉，面前又有一個大難題，就是讓大家背一下MFC層次結構圖。天，那張魚網怎么記得住，但既然我們要理解他，總得知道它是從那里派生出來的吧。
考慮到大家都很辛苦，那我們看一下上面兩個類的父子關系(箭頭代表派生)：
| CObject-＞CCmdTarget-＞CWinThread-＞CWinApp-＞自己的重寫了InitInstance()的應用程序類。 CObject（同上）-＞CCmdTarget（同上）-＞CWnd-＞CFrameWnd |
看到層次關系圖之后，終于可以開始寫MFC類庫了。按照上面層次結構，我們可以寫以下六個類（為了直觀，省去了構造函數和析構函數）。
| / class CObiect{};//MFC類的基類。 class CCmdTarget : public CObject{}; ------------------------------------------------ class CWinThread : public CCmdTarget{}; class CWinApp : public CWinThread{}; ------------------------------------------------ class CWnd : public CCmdTarget{}; class CFrameWnd : public CWnd{}; / |
大家再想一下，在上面的類里面，應該有什么？大家馬上會想到，CWinApp類或者它的基類CCmdTarget里面應該有一個虛函數virtual BOOL InitInstance(),是的，因為那里是程序的入口點，初始化程序的地方，那自然少不了的。可能有些朋友會說，反正InitInstance()在派生類中一定要重載，我不在CCmdTarget或CWinApp類里定義，留待CWinApp的派生類去增加這個函數可不可以。扯到這個問題可能有點越說越遠，但我想信C++的朋友對虛函數應該是沒有太多的問題的。總的來說，作為程序員如果清楚知道基類的某個函數要被派生類用到，那定義為虛函數要方便很多。也有很多朋友問，C++為什么不自動把基類的所有函數定義為虛函數呢，這樣可以省了很多麻煩，這樣所有函數都遵照派生類有定義的函數就調用派生類的，沒定義的就調用基類的，不用寫virtual的麻煩多好！其實，很多面向對象的語言都這樣做了。但定義一個虛函數要生成一個虛函數表，要占用系統空間，虛函數越多，表就越大，有時得不償失！這里哆嗦幾句，是因為往后要說明的消息映射中大家更加會體驗到這一點，好了，就此打往。
上面我們自己解決了一個問題，就是在CCmdTarge寫一個virtual BOOL InitInstance()。 大家再下想，我們還要我們MFC“隱藏”更多的東西：WinMain()函數，設計窗口類，窗口注冊，消息循環，回調函數……我們馬上想到封裝想封裝他們。大家似乎隱約地感覺到封裝WinMain()不容易,覺得WinMain()是一個特殊的函數，許多時候它代表了一個程序的起始和終結。所以在以前寫程序的時候，我們寫程序習慣從WinMain()的左大括寫起，到右大括弧返回、結束程序。
我們換一個角度去想，有什么東西可以拿到WinMain()外面去做，許多初學者們，總覺得WinMain()函數天大的函數，什么函數都好象要在它里面才能真正運行。其實這樣了解很片面，甚至錯誤。我們可以寫一個這樣的C++程序：
| #include ＜iostream.h＞ class test{ public: test(){cout＜＜"請改變你對main()函數的看法！"＜＜endl;} }; test test1; /**************************/ void main(){} |
在上面的程序里，入口的main()函數表面上什么也不做，但程序執行了（注：實際入口函數做了一些我們可以不了解的事情），并輸出了一句話（注：全局對象比main()首先運行）。現在大家可以知道我們的WinMain()函數可以什么都不做，程序依然可以運行，但沒有這個入口函數程序會報錯。
那么WinMain()函數會放哪個類上面呢，請看下面程序：
| #include ＜afxwin.h＞ class MyApp : public CWinApp { public: BOOL InitInstance() //②程序入點 { AfxMessageBox("程序依然可以運行！"); return true; } }; MyApp theApp; //①建立應用程序。 |
大家可以看到，我并沒有構造框架，而程序卻可以運行了——彈出一個對話框（如果沒有WinMain()函數程序會報錯）。上面我這樣寫還是為了直觀起見，其實我們只要寫兩行程序：
| #include ＜afxwin.h＞ CWinApp theApp; //整個程序只構造一個CWinApp類對象，任可事情，程序就可以運行！ |
所以說，只要我們構造了CWinApp對象，就可以執行WinMain()函數。我們馬上相信WinMain()函數是在CWinApp類或它的基類中，而不是在其他類中。其實這種看法是錯誤的，我們知道編寫C++程序的時候，不可能讓你在一個類中包含入口函數，WinMain()是由系統調用，跟我們的平時程序自身調用的函數有著本質的區別。我們可以暫時簡單想象成，當CWinApp對象構造完的時候，WinMain()跟著執行。
現在大家明白了，大部分的“通用代碼（我們想封裝隱藏的東西）”都可以放到CWinApp類中，那么它又是怎樣運行起來的呢？為什么構造了CWinApp類對象就“自動”執行那么多東西。
大家再仔細想一下，CWinApp類對象構造之后，它會“自動”執行自己的構造函數。那么我們可以把想要“自動”執行的代碼放到CWinApp類的構造函數中。
那么CWinApp類可能打算這樣設計（先不計較正確與否）：
| class CWinApp : public CWinThead{ public: virtual BOOL InitInstance(); //解釋過的程序的入點 CWinApp ::CWinApp(){ //構造函數 WinMain(); //這個是大家一眼看出的錯誤 Create(); //設計、創建、更新顯示窗口 Run(); //消息循環 // } }; |
寫完后，大家又馬上感覺到似乎不對，WinMain()函數在這里好象真的一點用處都沒有，并且能這樣被調用嗎（請允許我把手按在圣經上聲明一下：WinMain()不是普通的函數，它要肩負著初始化應用程序，包括全局變量的初始化，是由系統而不是程序本身調用的，WinMain()返回之后，程序就結束了，進程撤消）。再看Create()函數，它能確定設計什么樣的窗口，創建什么樣的窗口嗎？如果能在CWinApp的構造函數里確定的話，我們以后設計MFC程序時窗口就一個樣，變得寫程序變有必要。再看Run()函數，它能在WinMain()函數外面運行嗎？
回過頭來，我們可以讓WinMain()函數一條語句都不包含嗎？不可以，我們看一下WinMain()函數的四個參數：
| WinMain(HINSTANCE, HINSTANCE, LPSTR, int) |
其中第一個參數指向一個實例句柄，我們在設計WNDCLASS的時候一定要指定實例句柄。我們窗口編程，肯定要設計窗口類。所以，WinMain()再簡單也要這樣寫：
| int WinMain(HINSTANCE hinst, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { hInstance=hinst } |
既然實例句柄要等到程序開始執行才能知道，那么我們用于創建窗口的Create()函數也要在WinMain（）內部才能執行[因為如果等到WinMain（）執行完畢后，程序結束，進程撤消，當然Create()也不可能創建窗口]
那么Run()(消息循環)放在那里執行好呢？眾所周知，消息循環就是相同的那么幾句代碼，但我們也不要企圖把它放在WinMain（）函數之外執行。
所以我們在WinMain（）函數里面，我們程序要象以下這樣寫
| WinMain（……） { ……窗口類對象執行創建窗口函數…… ……程序類對象執行消息循環函數…… } |
對于WinMain（）的問題，得總結一下，我們封裝的時候是不可以把它封裝到CWinApp類里面，但由于WinMain（）的不變性（或者說有規律可循），MFC完全有能力在我們構造CWinApp類對象的時候，幫我們完成那幾行代碼。 轉了一個大圈，我們仿佛又回到了SDK編程的開始。但現在我們現在能清楚地知道，表面上MFC與SDK編程截然不同，但實質上MFC只是用類的形式封裝了SDK函數，封裝之后，我們在WinMain（）函數中只需要幾行代碼，就可以完成一個窗口程序。我們也由此知道了應如何去封裝應用程序類（CWinApp）和主框架窗口類（CFrameWnd）。下面把上開始設計這兩個類。
為了簡單起見，我們忽略這兩個類的基類和派生類的編寫，可能大家會認為這是一種很不負責任的做法，但本人覺得這既可減輕負擔，又免了大家在各類之間穿來穿去，更好理解一些（我們在關鍵的地方作注明）。還有，我把全部代碼寫在同一個文件中，讓大家看起來不用那么吃力，但這是最不提倡的寫代碼方法，大家不要學哦！
| #include ＜windows.h＞ HINSTANCE hInstance; class CFrameWnd { HWND hwnd; public: CFrameWnd(); //也可以在這里調用Create() virtual ~CFrameWnd(); int Create(); //類就留意這一個函數就行了！ BOOL ShowWnd(); }; class CWinApp1 { public: CFrameWnd* m_pMainWnd;//在真正的MFC里面 //它是CWnd指針，但這里由于不寫CWnd類 //只要把它寫成CFrameWnd指針 CWinApp1* m_pCurrentWinApp;//指向應用程序對象本身 CWinApp1(); virtual ~CWinApp1(); virtual BOOL InitInstance();//MFC原本是必須重載的函數，最重要的函數！！！！ virtual BOOL Run();//消息循環 }; CFrameWnd::CFrameWnd(){} CFrameWnd::~CFrameWnd(){} int CFrameWnd::Create() //封裝創建窗口代碼 { WNDCLASS wndcls; wndcls.style=0; wndcls.cbClsExtra=0; wndcls.cbWndExtra=0; wndcls.hbrBackground=(HBRUSH)GetStockObject(WHITE_BRUSH); wndcls.hCursor=LoadCursor(NULL,IDC_CROSS); wndcls.hIcon=LoadIcon(NULL,IDC_ARROW); wndcls.hInstance=hInstance; wndcls.lpfnWndProc=DefWindowProc;//默認窗口過程函數。 //大家可以想象成MFC通用的窗口過程。 wndcls.lpszClassName="窗口類名"; wndcls.lpszMenuName=NULL; RegisterClass(&wndcls); hwnd=CreateWindow("窗口類名","窗口實例標題名",WS_OVERLAPPEDWINDOW,0,0,600,400,NULL,NULL,hInstance,NULL); return 0; } BOOL CFrameWnd::ShowWnd()//顯示更新窗口 { ShowWindow(hwnd,SW_SHOWNORMAL); UpdateWindow(hwnd); return 0; } / CWinApp1::CWinApp1() { m_pCurrentWinApp=this; } CWinApp1::~CWinApp1(){} //以下為InitInstance()函數，MFC中要為CWinApp的派生類改寫， //這里為了方便理解，把它放在CWinApp類里面完成！ //你只要記住真正的MFC在派生類改寫此函數就行了。 BOOL CWinApp1::InitInstance() { m_pMainWnd=new CFrameWnd; m_pMainWnd-＞Create(); m_pMainWnd-＞ShowWnd(); return 0; } BOOL CWinApp1::Run()//封裝消息循環 { MSG msg; while(GetMessage(&msg,NULL,0,0)) { TranslateMessage(&msg); DispatchMessage(&msg); } return 0; } //封裝消息循環 CWinApp1 theApp; //應用程序對象（全局） int WINAPI WinMain( HINSTANCE hinst, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { hInstance=hinst; CWinApp1* pApp=theApp.m_pCurrentWinApp; //真正的MFC要寫一個全局函數AfxGetApp，以獲取CWinApp指針。 pApp-＞InitInstance(); pApp-＞Run(); return 0; } |
代碼那么長，實際上只是寫了三個函數，一是CFrameWnd類的Create(),第二個是CWinApp類的InitInstance()和Run()。在此特別要說明的是InitInstance()，真正的MFC中，那是我們跟據自己構造窗口的需要，自己改寫這個函數。
大家可以看到，封裝了上面兩個類以后，在入口函數WinMain中就寫幾行代碼，就可以產生一個窗口程序。在MFC中，因為WinMain函數就是固定的那么幾行代碼，所以MFC絕對可以幫我們自動完成（MFC的特長就是幫我們完成有規律的代碼），所以我們創造MFC應用程序的時候，看不到WinMain函數。
寫到這里，MFC六大關鍵技術之一：MFC程序的初始化過程（模擬），就差不多寫完了。回頭看一下，居然寫了八千多字，原本以為寫完六大關鍵技術也不用寫那么多字，現在還覺得慶幸的是不把文檔、視類牽連進去，否則更不知寫到何時。
還有五大關鍵技術沒有寫，我還應該寫下去嗎？上面寫了八千多字，都是我一個字一個字地敲進去，每個例子都是自己生硬地想出來。用了十多個小時，換來的可能更多是論壇中朋友們的漫罵，譏諷！
但我覺得還是值得的，我一向認為VC沒有敵人，只有朋友，放眼周圍，發覺學VC的朋友越來越少，也沒有發現多少招收VC程序員的地方。記得讀大學的時候，我遇到一位搞美術的師兄，本來同行如敵國（我曾經搞過美術）。師兄美術功底很好，但他從來沒有在學校獲過美術一等獎，原因評獎的不懂得欣賞他的作品。我的出現，他深刻地體會到了：多一個朋友，會少一分孤獨！有時覺得學習VC的朋友是英雄（但我不是英雄，因為我學VC多年來無甚突破），是值得尊敬的人物，大家交流一下，糾正一下自己的錯誤，真是一種福份…… MFC六大關鍵技術之運行時類型識別(RTTI) 運行時類型識別（RTTI）即是程序執行過程中知道某個對象屬于某個類，我們平時用C++編程接觸的RTTI一般是編譯器的RTTI，即是在新版本的VC++編譯器里面選用“使能RTTI”，然后載入typeinfo.h文件，就可以使用一個叫typeid（）的運算子，它的地位與在C++編程中的sizeof()運算子類似的地方（包含一個頭文件，然后就有一個熟悉好用的函數）。typdid()關鍵的地方是可以接受兩個類型的參數：一個是類名稱，一個是對象指針。所以我們判別一個對象是否屬于某個類就可以象下面那樣：
if （typeid (ClassName)== typeid（*ObjectName））{
((ClassName*)ObjectName)->Fun();
}
象上面所說的那樣，一個typeid（）運算子就可以輕松地識別一個對象是否屬于某一個類，但MFC并不是用typeid（）的運算子來進行動態類型識別，而是用一大堆令人費解的宏。很多學員在這里很疑惑，好象MFC在大部分地方都是故作神秘。使們大家編程時很迷惘，只知道在這里加入一組宏，又在那兒加入一個映射，而不知道我們為什么要加入這些東東。
其實，早期的MFC并沒有typeid（）運算子，所以只能沿用一個老辦法。我們甚至可以想象一下，如果MFC早期就有template（模板）的概念，可能更容易解決RTTI問題。
所以，我們要回到“古老”的年代，想象一下，要完成RTTI要做些什么事情。就好像我們在一個新型（新型到我們還不認識）電器公司里面，我們要識別哪個是電飯鍋，哪個是電磁爐等等，我們要查看登記的各電器一系列的信息，我們才可以比較、鑒別，那個東西是什么！
要登記一系列的消息并不是一件簡單的事情，大家可能首先想到用數組登記對象。但如果用數組，我們要定義多大的數組才好呢，大了浪費空間，小了更加不行。所以我們要用另一種數據結構——鏈表。因為鏈表理論上可大可小，可以無限擴展。
鏈表是一種常用的數據結構，簡單地說，它是在一個對象里面保存了指向下一個同類型對象的指針。我們大體可以這樣設計我們的類：
struct CRuntimeClass
{
……類的名稱等一切信息……
CRuntimeClass * m_pNextClass;//指向鏈表中下一CRuntimeClass對象的指針
};
鏈表還應該有一個表頭和一個表尾，這樣我們在查鏈表中各對象元素的信息的時候才知道從哪里查起，到哪兒結束。我們還要注明本身是由哪能個類派生。所以我們的鏈表類要這樣設計：
struct CRuntimeClass
{
……類的名稱等一切信息……
CRuntimeClass * m_pBaseClass;//指向所屬的基類。
CRuntimeClass * m_pNextClass;//定義表尾的時候只要定義此指針為空就可以 了。
static CRuntimeClass* pFirstClass;//這里表頭指針屬于靜態變量，因為我們知道static變量在內存中只初始化一次，就可以為各對象所用！保證了各對象只有一個表頭。
};
有了CRuntimeClass結構后，我們就可以定義鏈表了：
static CRuntimeClass classCObject={NULL,NULL};//這里定義了一個CRuntimeClass對象，因為classCObject無基類，所以m_pBaseClass為NULL。因為目前只有一個元素（即目前沒有下一元素），所以m_pNextClass為NULL（表尾）。
至于pFirstClass（表頭），大家可能有點想不通，它到什么地方去了。因為我們這里并不想把classCObject作為鏈表表頭，我們還要在前面插入很多的CRuntimeClass對象，并且因為pFirstClass為static指針，即是說它不是屬于某個對象，所以我們在用它之前要先初始化：CRuntimeClass* CRuntimeClass：：pFirstClass=NULL;
現在我們可以在前面插入一個CRuntimeClass對象，插入之前我得重要申明一下：如果單純為了運行時類型識別，我們未必用到m_pNextClass指針（更多是在運行時創建時用），我們關心的是類本身和它的基類。這樣，查找一個對象是否屬于一個類時，主要關心的是類本身及它的基類，
CRuntimeClass classCCmdTarget={ &classCObject, NULL};
CRuntimeClass classCWnd={ &classCCmdTarget ,NULL };
CRuntimeClass classCView={ &classCWnd , NULL };
好了，上面只是僅僅為一個指針m_pBaseClass賦值（MFC中真正CRuntimeClass有多個成員變量和方法），就連接成了鏈表。假設我們現在已全部構造完成自己需要的CRuntimeClass對象，那么，這時候應該定義表頭。即要用pFirstClass指針指向我們最后構造的CRuntimeClass對象——classCView。
CRuntimeClass：：pFirstClass=&classCView;
現在鏈表有了，表頭表尾都完善了，問題又出現了，我們應該怎樣訪問每一個CRuntimeClass對象？要判斷一個對象屬于某類，我們要從表頭開始，一直向表尾查找到表尾，然后才能比較得出結果嗎。肯定不是這樣！
大家可以這樣想一下，我們構造這個鏈表的目的，就是構造完之后，能夠按主觀地拿一個CRuntimeClass對象和鏈表中的元素作比較，看看其中一個對象中否屬于你指定的類。這樣，我們需要有一個函數，一個能返回自身類型名的函數GetRuntimeClass()。
上面簡單地說一下鏈表的過程，但單純有這個鏈表是沒有任何意義。回到MFC中來，我們要實現的是在每個需要有RTTI能力的類中構造一個CRuntimeClass對象，比較一個類是否屬于某個對象的時候，實際上只是比較CRuntimeClass對象。
如何在各個類之中插入CRuntimeClass對象，并且指定CRuntimeClass對象的內容及CRuntimeClass對象的鏈接，這里起碼有十行的代碼才能完成。在每個需要有RTTI能力的類設計中都要重復那十多行代碼是一件乏味的事情，也容易出錯，所以MFC用了兩個宏代替這些工作，即DECLARE_DYNAMIC(類名)和IMPLEMENT_DYNAMIC(類名，基類名)。從這兩個宏我們可以看出在MFC名類中的CRuntimeClass對象構造連接只有類名及基類名的不同！
到此，可能會有朋友問：為什么要用兩個宏，用一個宏不可以代換CRuntimeClass對象構造連接嗎？個人認為肯定可以，因為宏只是文字代換的游戲而已。但我們在編程之中，頭文件與源文件是分開的，我們要在頭文件頭聲明變量及方法，在源文件里實具體實現。即是說我們要在頭文件中聲明：
public:
static CRuntimeClass classXXX //XXX為類名
virtual CRuntime* GetRuntimeClass() const;
然后在源文件里實現：
CRuntimeClass* XXX：：classXXX={……}；
CRuntime* GetRuntimeClass() const;
{ return &XXX:: classXXX;}//這里不能直接返回&classXXX，因為static變量是類擁有而不是對象擁有。
我們一眼可以看出MFC中的DECLARE_DYNAMIC(類名)宏應該這樣定義：
#define DECLARE_DYNAMIC(class_name) public: static CRuntimeClass class##class_name; virtual CRuntimeClass* GetRuntimeClass() const;
其中##為連接符，可以讓我們傳入的類名前面加上class，否則跟原類同名，大家會知道產生什么后果。
有了上面的DECLARE_DYNAMIC(類名)宏之后，我們在頭文件里寫上一句
DECLARE_DYNAMIC(XXX)
宏展開后就有了我們想要的：
public:
static CRuntimeClass classXXX //XXX為類名
virtual CRuntime* GetRuntimeClass() const;
對于IMPLEMENT_DYNAMIC(類名，基類名)，看來也不值得在這里代換文字了，大家知道它是知道回事，宏展開后為我們做了什么，再深究真是一點意義都沒有！
有了此鏈表之后，就像有了一張存放各類型的網，我們可以輕而易舉地RTTI。CObject有一個函數BOOL IsKindOf(const CRuntimeClass* pClass) const;，被它以下所有派生員繼承。
此函數實現如下：
BOOL CObject::IsKindOf(const CRuntimeClass* pClass) const
{
CRuntimeClass* pClassThis=GetRuntimeClass();//獲得自己的CRuntimeClass對象指針。
while(pClassThis!=NULL)
{
if(pClassThis==pClass) return TRUE;
pClassThis=pClassThis->m_pBaseClass;//這句最關鍵，指向自己基類，再回頭比較，一直到盡頭m_pBaseClass為NULL結束。
}
return FALSE;
}
說到這里，運行時類型識別（RTTI）算是完成了。寫這篇文章的時候，我一直重感冒。我曾一度在想，究竟寫這東西是為了什么。因為如果我把這些時間用在別的地方（甚至幫別人打打字），應該有數百元的報酬。
是什么讓“嗜財如命”的我繼續寫下去？我想，無非是想交幾個計算機的朋友而已。計算機是大家公認高科技的東西，但學習它的朋友大多只能默默無聞，外界的朋友也不知道怎么去認識你。程序員更不是“潮流”的東西，更加得不到別人的認可。
有一件個人認為很典型的事情，有一天，我跟一個朋友到一個單位里面。里面有一個女打字員。朋友看著她熟練的指法，心悅誠服地說：“她的電腦水平比你的又高了一個很高的層次！”，那個女的打字高手亦自豪地說：“我靠電腦為生，電腦水平肯定比你（指筆者）的好一點！換著是你，如果以電腦為生，我也不敢說好過你！”。雖然我想聲明我是計算機專業的，但我知道沒有理解，所以我只得客氣地點頭。
選擇電腦“潮流”的東西實際是選擇了平凡，而選擇做程序員就是選擇了孤獨！幸好我不是一個專門的程序員，但即使如此，我愿意做你們的朋友，因為我愛你們！ MFC六大關鍵技術之動態創建 動態創建就是運行時創建指定類的對象，在MFC中大量使用。如框架窗口對象、視對象，還有文檔對象都需要由文檔模板類對象來動態的創建。我覺得這是每個MFC的學習者很希望理解的問題。 初次接觸MFC的時候，很容易有這樣的迷惘。MFC的幾大類不用我們設計也就罷了，但最疑惑的是不用我們實例化對象。本來最直觀的理解就是，我們需要框架的時候，親手寫上CFrameWnd myFrame；需要視的時候，親自打上CView myView;…… 但MFC不給我們這個機會，致使我們錯覺窗口沒有實例化就彈出來了！就象畫了張電視機的電路圖就可以看電視一樣令人難以置信。但大伙想了一下，可能會一拍腦門，認為簡單不過：MFC自動幫我們完成CView myView之流的代碼不就行了么！！！其實不然，寫MFC程序的時候，我們幾乎要對每個大類進行派生改寫。換句話說，MFC并不知道我們打算怎樣去改寫這些類，當然也不打算全部為我們“靜態”創建這些類了。即使靜態了創建這些類也沒有用，因為我們從來也不會直接利用這些類的實例干什么事情。我們只知道，想做什么事情就往各大類里塞，不管什么變量、方法照塞，塞完之后，我們似乎并未實例化對象，程序就可以運行！ 要做到把自己的類交給MFC，MFC就用同一樣的方法，把不同的類一一準確創建，我們要做些什么事情呢？同樣地，我們要建立鏈表，記錄各類的關鍵信息，在動態創建的時候找出這些信息，就象上一節RTTI那樣！我們可以設計一個類： struct CRuntimeClass{ ???? LPCSTR m_lpszClassName;??????????????? //類名指針 ???? CObject* (PASCAL *m_pfnCreateObject)();?? //創建對象的函數的指針 ????? CRuntimeClass* m_pBaseClass;???????????????????????? //講RTTI時介紹過 ???? CRuntimeClass* m_pNextClass;?????????? ?//指向鏈表的下一個元素(許多朋友說上一節講RTTI時并沒有用到這個指針，我原本以為這樣更好理解一些，因為沒有這個指針，這個鏈表是無法連起來，而m_pBaseClass僅僅是向基類走，在MFC的樹型層次結構中m_pBaseClass是不能遍歷的) ??????? CObject* CreateObject();???????????????? //創建對象 ???? static CRuntimeClass* PASCAL Load();??? //遍歷整個類型鏈表，返回符合動態創建的對象。 ?static CRuntimeClass* pFirstClass;??????? //類型鏈表的頭指針 }; 一下子往結構里面塞了那么多的東西，大家可以覺得有點頭暈。至于CObject* (PASCAL *m_pfnCreateObject)();，這定義函數指針的方法，大家可能有點陌生。函數指針在C++書籍里一般被定為選學章節，但MFC還是經常用到此類的函數，比如我們所熟悉的回調函數。簡單地說m_pfnCreateObject即是保存了一個函數的地址，它將會創建一個對象。即是說，以后，m_pfnCreateObject指向不同的函數，我們就會創建不同類型的對象。 有函數指針，我們要實現一個與原定義參數及返回值都相同一個函數，在MFC中定義為： static CObject* PASCAL CreateObject(){return new XXX};//XXX為類名。類名不同，我們就創建不同的對象。 由此，我們可以如下構造 CRuntimeClass到鏈表： CRuntimeClass classXXX={ 類名， ……， XXX::CreateObject()，?? //m_pfnCreateObject指向的函數 RUNTIME_CLASS(基類名)?// RUNTIME_CLASS宏可以返回CRuntimeClass對象指針。 NULL????? //m_pNextClass暫時為空，最后會我們再設法讓它指向舊鏈表表頭。 }; 這樣，我們用函數指針m_pfnCreateObject（指向CreateObject函數)，就隨時可new新對象了。并且大家留意到，我們在設計CRuntimeClass類對時候，只有類名（和基類名）的不同（我們用XXX代替的地方），其它的地方一樣，這正是我們想要的，因為我們動態創建也象RTTI那樣用到兩個宏，只要傳入類名和基類作宏參數，就可以滿足條件。 即是說，我們類說明中使用DECLARE_DYNCREATE（CLASSNMAE）宏和在類的實現文件中使用IMPLEMENT_DYNCREATE（CLASSNAME，BASECLASS）宏來為我們加入鏈表，至于這兩個宏怎么為我們建立一個鏈表，我們自己可以玩玩文字代換的游戲，在此不一一累贅。但要說明的一點就是：動態創建宏xxx_DYNCREATE包含了RTTI宏，即是說， xxx_DYNCREATE是xxx_DYNAMIC的“增強版”。 到此，我們有必要了解一下上節課沒有明講的m_pNextClass指針。因為MFC層次結構是樹狀的，并不是直線的。如果我們只有一個m_pBaseClass指針，它只會沿著基類上去，會漏掉其它分支。在動態創建時，必需要檢查整個鏈表，看有多少個要動態創建的對象，即是說要從表頭（pFirstClass）開始一直遍歷到表尾（m_pNextClass=NULL），不能漏掉一個CRuntimeClass對象。 所以每當有一個新的鏈表元素要加入鏈表的時候，我們要做的就是使新的鏈表元素成為表頭，并且m_pNextClass指向原來鏈表的表頭，即像下面那樣（當然，這些不需要我們操心，是RTTI宏幫助我們完成的）： pNewClass->m_pNextClass=CRuntimeClass::pFirstClass;//新元素的m_pNextClass指針指向想加入的鏈表的表頭。 CRuntimeClass::pFirstClass=pNewClass;//鏈表的頭指針指向剛插入的新元素。 好了，有了上面的鏈表，我們就可以分析動態創建了。 有一了張有類名，函數指針，動態創建函數的鏈表，我們就可以知道應該按什么步驟去動態創建了：1、獲得一要動態創建的類的類名（假設為A）。2、將A跟鏈表里面每個元素的m_lpszClassName指向的類名作比較。3、若找到跟A相同的類名就返回A所屬的CRuntimeClass元素的指針。4、判斷m_pfnCreateObject是否有指向創建函數，有則創建對象，并返回該對象。代碼演示如下（以下兩個函數都是CRuntimeClass類函數）： ///以下為根據類名從表頭向表尾查找所屬的CRuntimeClass對象 CRuntimeClass* PASCAL CRuntimeClass::Load() { char szClassXXX[64]; CRuntimeClass* pClass; cin>>szClassXXX;????? //假定這是我們希望動態創建的類名 for(pClass=pFirstClass;pClass!=NULL;pClass=pClass->m_pNextClass) { ??????? if(strcmp(szClassXXX,pClass->m_lpszClassName)==0) ??????? return pClass; } ??????? return NULL } ///根據CRuntimeClass創建對象/// CObject* CRuntimeClass::CreateObject() { ??????? if(m_pfnCreateObject==NULL) return NULL; ??????? CObject *pObject; pObject=(* m_pfnCreateObject)();??????? //函數指針調用 ??????? return pObject;?????????????????????????????????? } 有了上面兩個函數，我們在程序執行的時候調用，就可以動態創建對象了。 我們還可以更簡單地實現動態創建，大家注意到，就是在我們的程序類里面有一個RUNTIME_CLASS(class_name)宏，這個宏在MFC里定義為： RUNTIME_CLASS(class_name)?((CRuntimeClass*)(&class_name::class##class_name)) 作用就是得到類的RunTime信息，即返回class_name所屬CRuntimeClass的對象。在我們的應用程序員類(CMyWinApp)的InitInstance()函數下面的CSingleDocTemplate函數中，有： RUNTIME_CLASS(CMyDoc), ??????? RUNTIME_CLASS(CMainFrame),?????? // main SDI frame window ??????? RUNTIME_CLASS(CMyView) 構造文檔模板的時候就用這個宏得到文檔、框架和視的RunTime信息。有了RunTime信息，我們只要一條語句就可以動態創建了，如： classMyView->CreateObject();????? //對象直接調用用CRuntimeClass本身的CreateObject() 現在，細心的朋友已經能清楚動態創建需要的步驟： 1、定義一個不帶參數的構造函數（默認構造函數）；因為我們是用CreateObject()動態創建，它只有一條語句就是return new XXX，不帶任何參數。所以我們要有一個無參構造函數。 2、類說明中使用DECLARE_DYNCREATE（CLASSNMAE）宏；和在類的實現文件中使用IMPLEMENT_DYNCREATE（CLASSNAME，BASECLASS）宏；這個宏完成構造CRuntimeClass對象，并加入到鏈表中。 3、使用時先通過宏RUNTIME_CLASS得到類的RunTime信息，然后使用CRuntimeClass的成員函數CreateObject創建一個該類的實例。 4、CObject* pObject = pRuntimeClass->CreateObject();//完成動態創建。 MFC六大關鍵技術之永久保存(串行化) 先用一句話來說明永久保存的重要：弄懂它以后，你就越來越像個程序員了！
如果我們的程序不需要永久保存，那幾乎可以肯定是一個小玩兒。那怕我們的記事本、畫圖等小程序，也需要保存才有真正的意義。
對于MFC的很多地方我不甚滿意，總覺得它喜歡拿一組低能而神秘的宏來故弄玄虛，但對于它的連續存儲（serialize）機制，卻是我十分鐘愛的地方。在此，可讓大家感受到面向對象的幸福。
MFC的連續存儲（serialize）機制俗稱串行化。“在你的程序中盡管有著各種各樣的數據，serialize機制會象流水一樣按順序存儲到單一的文件中，而又能按順序地取出，變成各種不同的對象數據。”不知我在說上面這一句話的時候，大家有什么反應，可能很多朋友直覺是一件很簡單的事情，只是說了一個“爽”字就沒有下文了。
要實現象流水一樣存儲其實是一個很大的難題。試想，在我們的程序里有各式各樣的對象數據。如畫圖程序中，里面設計了點類，矩形類，圓形類等等，它們的繪圖方式及對數據的處理各不相同，用它們實現了成百上千的對象之后，如何存儲起來？不想由可，一想頭都大了：我們要在程序中設計函數store()，在我們單擊“文件/保存”時能把各對象往里存儲。那么這個store()函數要神通廣大，它能清楚地知道我們設計的是什么樣的類，產生什么樣的對象。大家可能并不覺得這是一件很困難的事情，程序有能力知道我們的類的樣子，對象也不過是一塊初始化了存儲區域罷了。就把一大堆對象“轉換”成磁盤文件就行了。
即使上面的存儲能成立，但當我們單擊“文件/打開”時，程序當然不能預測用戶想打開哪個文件，并且當打開文件的時候，要根據你那一大堆垃圾數據new出數百個對象，還原為你原來存儲時的樣子，你又該怎么做呢？
試想，要是我們有一個能容納各種不同對象的容器，這樣，用戶用我們的應用程序打開一個磁盤文件時，就可以把文件的內容讀進我們程序的容器中。把磁盤文件讀進內存，然后識別它“是什么對象”是一件很難的事情。首先，保存過程不像電影的膠片，把景物直接映射進去，然后，看一下膠片就知道那是什么內容。可能有朋友說它象錄像磁帶，拿著錄像帶我們看不出里面變化的磁場信號，但經過錄像機就能把它還原出來。
其實不是這樣的，比如保存一個矩形，程序并不是把矩形本身按點陣存儲到磁盤中，因為我們繪制矩形的整個過程只不過是調用一個GDI函數罷了。它保存只是坐標值、線寬和某些標記等。程序面對“00 FF”這樣的東西，當然不知道它是一個圓或是一個字符！
拿剛才錄像帶的例子，我們之所以能最后放映出來，前提我們知道這對象是“錄像帶”，即確定了它是什么類對象。如果我們事先只知道它“里面保存有東西，但不知道它是什么類型的東西”，這就導致我們無法把它讀出來。拿錄像帶到錄音機去放，對錄音機來說，那完全是垃圾數據。即是說，要了解永久保存，要對動態創建有深刻的認識。
現在大家可以知道困難的根源了吧。我們在寫程序的時候，會不斷創造新的類，構造新的對象。這些對象，當然是舊的類對象（如MyDocument）從未見過的。那么，我們如何才能使文檔對象可以保存自己新對象呢，又能動態創建自己新的類對象呢？
許多朋友在這個時候想起了CObject這個類，也想到了虛函數的概念。于是以為自己“大致了解”串行化的概念。他們設想：“我們設計的MyClass（我們想用于串行化的對象）全部從CObject類派生，CObject類對象當然是MyDocument能認識的。”這樣就實現了一個目的：本來MyDocument不能識別我們創建的MyClass對象，但它能識別CObject類對象。由于MyClass從CObject類派生，我產的新類對象“是一個CObject”，所以MyDocument能把我們的新對象當作CObiect對象讀出。或者根據書本上所說的：打開或保存文件的時候，MyDocument會調用Serialize（），MyDocument的Serialize（）函會呼叫我們創建類的Serialize函數[即是在MyDocument Serialize（）中調用：m_pObject->Serialize()，注意：在此m_pObject是CObject類指針，它可以指向我們設計的類對象]。最終結果是MyDocument的讀出和保存變成了我們創建的類對象的讀出和保存，這種認識是不明朗的。
有意思還有，在網上我遇到幾位自以為懂了Serialize的朋友，居然不約而同的犯了一個很低級得讓人不可思議的錯誤。他們說：Serialize太簡單了！Serialize（）是一個虛函數，虛函數的作用就是“優先派生類的操作”。所以MyDocument不實現Serialize（）函數，留給我們自己的MyClass對象去調用Serialize（）……真是哭笑不得，我們創建的類MyClass并不是由MyDocument類派生，Serialize（）函數為虛在MyDocument和MyClass之間沒有任何意義。MyClass產生的MyObject對象僅僅是MyDocument的一個成員變量罷了。
話說回來，由于MyClass從CObject派生，所以CObject類型指針能指向MyClass對象，并且能夠讓MyClass對象執行某些函數（特指重載的CObject虛函數），但前提必須在MyClass對象實例化了，即在內存中占領了一塊存儲區域之后。不過，我們的問題恰恰就是在應用程序隨便打開一個文件，面對的是它不認識的MyClass類，當然實例化不了對象。
幸好我們在上一節課中懂得了動態創建。即想要從CObject派生的MyClass成為可以動態創建的對象只要用到DECLARE_DYNAMIC/IMPLEMENT_DYNAMIC宏就可以了（注意：最終可以Serialize的對象僅僅用到了DECLARE_SERIAL/IMPLEMENT_SERIAL宏，這是因為DECLARE_SERIAL/IMPLEMENT_SERIAL包含了DECLARE_DYNAMIC/IMPLEMENT_DYNAMIC宏）。
從解決上面的問題中，我們可以分步理解了：
1、 Serialize的目的：讓MyDocument對象在執行打開/保存操作時，能讀出（構造）和保存它不認的MyClass類對象。
2、 MyDocument對象在執行打開/保存操作時會調用它本身的Serialize（）函數。但不要指望它會自動保存和讀出我們的MyClass類對象。這個問題很容易解決，就直接在MyDocument:: Serialize（）{
// 在此函數調用MyClass類的Serialize（）就行了！即
MyObject. Serialize（）;
}
3、我們希望MyClass對象為可以動態創建的對象，所以要求在MyClass類中加上DECLARE_DYNAMIC/IMPLEMENT_DYNAMIC宏。
但目前的Serialize機制還很抽象。我們僅僅知道了表面上的東西，實際又是如何的呢？下面作一個簡單深刻的詳解。
先看一下我們文檔類的Serialize（）
void CMyDoc::Serialize(CArchive& ar)
{
if (ar.IsStoring())
{
// TODO: add storing code here
}
else
{
// TODO: add loading code here
}
}
目前這個子數什么也沒做（沒有數據的讀出和寫入），CMyDoc類正等待著我們去改寫這個函數。現在假設CMyDoc有一個MFC可識別的成員變量m_MyVar,那么函數就可改寫成如下形式：
void CMyDoc::Serialize(CArchive& ar)
{
if (ar.IsStoring()) //讀寫判斷
{
ar<<m_MyVar; //寫
}
else
{
ar>>m_MyVar; //讀
}
}
許多網友問：自己寫的類（即MFC未包含的類）為什么不行？我們在CMyDoc里包含自寫類的頭文件MyClass.h，這樣CMyDoc就認識MyDoc類對象了。這是一般常識性的錯誤，MyDoc類認識MyClass類對象與否并沒有用，關鍵是CArchive類，即對象ar不認識MyClass（當然你夢想重寫CArchive類當別論）。“>>”、“<<”都是CArchive重載的操作符。上面ar>>m_MyVar說白即是在執行一個以ar和m_MyVar為參數的函數，類似于function(ar,m_MyVar)罷了。我們當然不能傳遞一個它不認識的參數類型，也因此不會執行function(ar,m_MyObject)了。
[注：這里我們可以用指針。讓MyClass從Cobject派生，一切又起了質的變化，假設我們定義了：MyClass *pMyClass = new MyClass;因為MyClass從CObject派生，根據虛函數原理，pMyClass也是一個CObject*，即pMyClass指針是CArchive類可認識的。所以執行上述function(ar, pMyClass)，即ar << pMyClass是沒有太多的問題（在保證了MyClass對象可以動態創建的前提下）。]
回過頭來，如果想讓MyClass類對象能Serialize，就得讓MyClass從CObject派生，Serialize（）函數在CObject里為虛，MyClass從CObject派生之后就可以根據自己的要求去改寫它，象上面改寫CMyDoc::Serialize（）方法一樣。這樣MyClass就得到了屬于MyClass自己特有的Serialize（）函數。
現在，程序就可以這樣寫：
……
#include “MyClass.h”
……
void CMyDoc::Serialize(CArchive& ar)
{
//在此調用MyClass重寫過的Serialize()
m_MyObject. Serialize(ar); // m_MyObject為MyClass實例
}
至此，串行化工作就算完成了，一即簡單直觀：從CObject派生自己的類，重寫Serialize（）。在此過程中，我刻意安排：在沒有用到DECLARE_SERIAL/IMPLEMENT_SERIAL宏，也沒有用到CArray等模板類的前提下就完成了串行化的工作。我看過某些書，總是一開始就講DECLARE_SERIAL/IMPLEMENT_SERIAL宏或馬上用CArray模板，讓讀者覺得串行化就是這兩個東西，導致許多朋友因此找不著北。
大家看到了，沒有DECLARE_SERIAL/IMPLEMENT_SERIAL宏和CArray等數據結構模板也依然可以完成串行化工作。
現在可以騰出時間講一下大家覺得十分抽象的CArchive。我們先看以下程序（注：以下程序包含動態創建等，請包含DECLARE_SERIAL/IMPLEMENT_SERIAL宏）
void MyClass::Serialize(CArchive& ar)
{
if (ar.IsStoring()) //讀寫判斷
{
ar<< m_pMyVar; //問題：ar如何把m_pMyVar所指的對象變量保存到磁盤？
}
else
{
pMyClass = new MyClass; //準備存儲空間
ar>> m_pMyVar;
}
}
要回答上面的問題，即“ar<<XXX”的問題。和我們得看一下模擬CArchive的代碼。
“ar<<XXX”是執行CArchive對運算符“<<”的重載動作。ar和XXX都是該重載函數中的一參數而已。函數大致如下：
CArchive& operator<<( CArchive& ar, const CObject* pOb)
{
…………
//以下為CRuntimeClass鏈表中找到、識別pOb資料。
CRuntimeClass* pClassRef = pOb->GetRuntimeClass();
//保存pClassRef即類信息（略）
((CObject*)pOb)->Serialize();//保存MyClass數據
…………
}
從上面可以看出，因為Serialize()為虛函數，即“ar<<XXX”的結果是執行了XXX所指向對象本身的Serialize()。對于“ar>>XXX”，雖然不是“ar<<XXX”逆過程，大家可能根據動態創建和虛函數的原理料想到它。
至此，永久保存算是寫完了。在此過程中，我一直努力用最少的代碼，詳盡的解釋來說明問題。以前我為本課題寫過一個版本，并在幾個論壇上發表過，但不知怎么在網上遺失（可能被刪除）。所以這篇文章是我重寫的版本。記得第一個版本中，我是對DECLARE_SERIAL/IMPLEMENT_SERIAL和可串行化的數組及鏈表對象說了許多。這個版本中我對DECLARE_SERIAL/IMPLEMENT_SERIAL其中奧秘幾乎一句不提，目的是讓大家能找到中心，有更簡潔的永久保存的概念，我覺得這種感覺很好！ ? MFC六大關鍵技術之消息映射與命令傳遞
???????? 題外話：剛開始學視窗程序設計的時候，我就打印了一本Windows消息詳解，里面列舉了各種已定義消息的意義和作用，共10多頁，在編程的時候翻翻，有時覺得很受用。我發覺很多編程的朋友，雖然每天都面對消息，卻很少關注它。C++程序員有一個通病，很想寫“自己”的程序，即每一行代碼都想自己寫出來。如果用了一些庫，總希望能完全理解庫里的類或函數是怎么一回事，否則就“不踏實”。對于消息，許多朋友只關心常用的幾個，對其余的漠不關心。其實，Windows中有很多不常用的消息卻很有用，程序員可能通過響應這些消息實現更簡捷的編程。
說到消息，在MFC中，“最熟悉的神秘”可算是消息映射，那是我們剛開始接觸MFC時就要面對的東西。有過SDK編程經驗的朋友轉到MFC編程的時候，一下子覺得什么都變了樣。特別是窗口消息及對消息的處理跟以前相比，更是風馬牛不相及的。如文檔不是窗口，是怎樣響應命令消息的呢？
初次用MFC編程，我們只會用MFC ClassWizard為我們做大量的東西，最主要的是添加消息響應。記憶中，如果是自已添加消息響應，我們應何等的小心翼翼，對BEGIN_MESSAGE_MAP（）……END_MESSAGE_MAP()更要奉若神靈。它就是一個魔盒子，把我們的咒語放入恰當的地方，就會發生神奇的力量，放錯了，自己的程序就連“命”都沒有。
據說，知道得太多未必是好事。我也曾經打算不去理解這神秘的區域，覺得編程的時候知道自己想做什么就行了。MFC外表上給我們提供了東西，直觀地說，不但給了我個一個程序的外殼，更給我們許多方便。微軟的出發點可能是希望達到“傻瓜編程”的結果，試想，誰不會用ClassWizard？大家知道，Windows是基于消息的，有了ClassWizard，你又會添加類，又會添加消息，那么你所學的東西似乎學到頭了。于是許多程序員認為“我們沒有必要走SDK的老路，直接用MFC編程，新的東西通常是簡單、直觀、易學……”
到你真正想用MFC編程的時候，你會發覺光會ClassWizard的你是多么的愚蠢。MFC不是一個普通的類庫，普通的類庫我們完全可以不理解里面的細節，只要知道這些類庫能干什么，接口參數如何就萬事大吉。如string類，操作順序是定義一個string對象，然后修改屬性，調用方法。
但對于MFC，你并不是在你的程序中寫上一句“#include MFC.h”，然后就在你的程序中用MFC類庫。
MFC是一塊包著糖衣的牛骨頭。你很輕松地寫出一個單文檔窗口，在窗口中間打印一句“I love MFC!”，然后，惡夢開始了……想逃避，打算永遠不去理解MFC內幕？門都沒有！在MFC這個黑暗神秘的洞中，即使你打算摸著石頭前行，也注定找不到出口。對著MFC這塊牛骨頭，微軟溫和、民主地告訴你“你當然可以選擇不啃掉它，咳咳……但你必然會因此而餓死！”
消息映射與命令傳遞體現了MFC與SDK的不同。在SDK編程中，沒有消息映射的概念，它有明確的回調函數中，通過一個switch語句去判斷收到了何種消息，然后對這個消息進行處理。所以，在SDK編程中，會發送消息和在回調函數中處理消息就差不多可以寫SDK程序了。
在MFC中，看上去發送消息和處理消息比SDK更簡單、直接，但可惜不直觀。舉個簡單的例子，如果我們想自定義一個消息，SDK是非常簡單直觀的，用一條語句：SendMessage(hwnd,message/*一個大于或等于WM_USER的數字*/,wparam,lparam)，之后就可以在回調函數中處理了。但MFC就不同了，因為你通常不直接去改寫窗口的回調函數，所以只能亦步亦趨對照原來的MFC代碼，把消息放到恰當的地方。這確實是一樣很痛苦的勞動。
要了解MFC消息映射原理并不是一件輕松的事情。我們可以逆向思維，想象一下消息映射為我們做了什么工作。MFC在自動化給我們提供了很大的方便，比如，所有的MFC窗口都使用同一窗口過程，即所有的MFC窗口都有一個默認的窗口過程。不象在SDK編程中，要為每個窗口類寫一個窗口過程。
對于消息映射，最直截了當地猜想是：消息映射就是用一個數據結構把“消息”與“響應消息函數名”串聯起來。這樣，當窗口感知消息發生時，就對結構查找，找到相應的消息響應函數執行。其實這個想法也不能簡單地實現：我們每個不同的MFC窗口類，對同一種消息，有不同的響應方式。即是說，對同一種消息，不同的MFC窗口會有不同的消息響應函數。
這時，大家又想了一個可行的方法。我們設計窗口基類（CWnd）時，我們讓它對每種不同的消息都來一個消息響應，并把這個消息響應函數定義為空虛函數。這樣，從CWnd派生的窗口類對所有消息都有了一個空響應，我們要響應一個特定的消息就重載這個消息響應函數就可以了。但這樣做的結果，一個幾乎什么也不做的CWnd類要有幾百個“多余”的函數，那怕這些消息響應函數都為純虛函數，每個CWnd對象也要背負著一個巨大的虛擬表，這也是得不償失的。
許多朋友在學習消息映射時苦無突破，其原因是一開始就認為MFC的消息映射的目的是為了替代SDK窗口過程的編寫——這本來沒有理解錯。但他們還有多一層的理解，認為既然是替代“舊”的東西，那么MFC消息映身應該是更高層次的抽象、更簡單、更容易認識。但結果是，如果我們不通過ClassWizard工具，手動添加消息是相當迷茫的一件事。
所以，我們在學習MFC消息映射時，首先要弄清楚：消息映射的目的，不是為是更加快捷地向窗口過程添加代碼，而是一種機制的改變。如果不想改變窗口過程函數，那么應該在哪里進行消息響應呢？許多朋友一知半解地認為：我們可以用HOOK技術，搶在消息隊列前把消息抓取，把消息響應提到窗口過程的外面。再者，不同的窗口，會有不同的感興趣的消息，所以每個MFC窗口都應該有一個表把感興趣的消息和相應消息響應函數連系起來。然后得出——消息映射機制執行步驟是：當消息發生，我們用HOOK技術把本發送到窗口過程的消息抓獲，然后對照一下MFC窗口的消息映射表，如果是表里面有的消息，就執行其對應的函數。
當然，用HOOK技術，我們理論上可以在不改變窗口過程函數的情況下，可以完成消息響應。MFC確實是這樣做，但實際操作起來可能跟你的想象差別很大。
現在我們來編寫消息映射表，我們先定義一個結構，這個結構至少有兩個項：一是消息ID，二是響應該消息的函數。如下：
struct AFX_MSGMAP_ENTRY
{
UINT nMessage; //感興趣的消息
AFX_PMSG pfn; //響應以上消息的函數指針
}
當然，只有兩個成員的結構連接起來的消息映射表是不成熟的。Windows消息分為標準消息、控件消息和命令消息，每類型的消息包含數百不同ID、不同意義、不同參數的消息。我們要準確地判別發生了何種消息，必須再增加幾個成員。還有，對于AFX_PMSG pfn，實際上等于作以下聲明：
void (CCmdTarget::*pfn)();
(提示：AFX_PMSG為類型標識，具體聲明是：typedef void (AFX_MSG_CALL CCmdTarget::*AFX_PMSG)(void);)
pfn是不一不帶參數和返回值的CCmdTarget類型函數指針，只能指向CCmdTarget類中不帶參數和返回值的成員函數，這樣pfn更為通用，但我們響應消息的函數許多需要傳入參數的。為了解決這個矛盾，我們還要增加一個表示參數類型的成員。當然，還有其它……
最后，MFC我們消息映射表成員結構如下定義：
struct AFX_MSGMAP_ENTRY
{
UINT nMessage; //Windows 消息ID
UINT nCode; // 控制消息的通知碼
UINT nID; //命令消息ID范圍的起始值
UINT nLastID; //命令消息ID范圍的終點
UINT nSig; // 消息的動作標識
AFX_PMSG pfn;
};
有了以上消息映射表成員結構，我們就可以定義一個AFX_MSGMAP_ENTRY類型的數組，用來容納消息映射項。定義如下：
AFX_MSGMAP_ENTRY _messageEntries[];
但這樣還不夠，每個AFX_MSGMAP_ENTRY數組，只能保存著當前類感興趣的消息，而這僅僅是我們想處理的消息中的一部分。對于一個MFC程序，一般有多個窗口類，里面都應該有一個AFX_MSGMAP_ENTRY數組。我們知道，MFC還有一個消息傳遞機制，可以把自己不處理的消息傳送給別的類進行處理。為了能查找各下MFC對象的消息映射表，我們還要增加一個結構，把所有的AFX_MSGMAP_ENTRY數組串聯起來。
于是，我們定義了一個新結構體：
struct AFX_MSGMAP
{
const AFX_MSGMAP* pBaseMap; //指向別的類的AFX_MSGMAP對象
const AFX_MSGMAP_ENTRY* lpEntries; //指向自身的消息表
};
之后，在每個打算響應消息的類中這樣聲明一個變量：AFX_MSGMAP messageMap，讓其中的pBaseMap指向基類或另一個類的messageMap，那么將得到一個AFX_MSGMAP元素的單向鏈表。這樣，所有的消息映射信息形成了一張消息網。
當然，僅有消息映射表還不夠，它只能把各個MFC對象的消息、參數與相應的消息響應函數連成一張網。為了方便查找，MFC在上面的類中插入了兩個函數（其中theClass代表當前類）：
一個是_GetBaseMessageMap()，用來得到基類消息映射的函數。函數原型如下：
const AFX_MSGMAP* PASCAL theClass::_GetBaseMessageMap() /
{ return &baseClass::messageMap; } /
別一個是GetMessageMap() ，用來得到自身消息映射的函數。函數原型如下：
const AFX_MSGMAP* theClass::GetMessageMap() const /
{ return &theClass::messageMap; } /
有了消息映射表之后，我們得討論到問題的關鍵，那就是消息發生以后，其對應的響應函數如何被調用。大家知道，所有的MFC窗口，都有一個同樣的窗口過程——AfxWndProc(…)。在這里順便要提一下的是，看過MFC源代碼的朋友都得，從AfxWndProc函數進去，會遇到一大堆曲折與迷團，因為對于這個龐大的消息映射機制，MFC要做的事情很多，如優化消息，增強兼容性等，這一大量的工作，有些甚至用匯編語言來完成，對此，我們很難深究它。所以我們要省略大量代碼，理性地分析它。
對已定型的AfxWndProc來說，對所有消息，最多只能提供一種默認的處理方式。這當然不是我們想要的。我們想通過AfxWndProc最終執行消息映射網中對應的函數。那么，這個執行路線是怎么樣的呢？
從AfxWndProc下去，最終會調用到一個函數OnWndMsg。請看代碼：
LRESULT CALLBACK AfxWndProc(HWND hWnd,UINT nMsg,WPARAM wParam, LPARAM lParam)
{
……
CWnd* pWnd = CWnd::FromHandlePermanent(hWnd); //把對句柄的操作轉換成對CWnd對象。
Return AfxCallWndProc(pWnd,hWnd,nMsg,wParam,lParam);
}
把對句柄的操作轉換成對CWnd對象是很重要的一件事，因為AfxWndProc只是一個全局函數，當然不知怎么樣去處理各種windows窗口消息，所以它聰明地把處理權交給windows窗口所關聯的MFC窗口對象。
現大，大家幾乎可以想象得到AfxCallWndProc要做的事情，不錯，它當中有一句：
pWnd->WindowProc(nMsg,wParam,lParam);
到此，MFC窗口過程函數變成了自己的一個成員函數。WindowProc是一個虛函數，我們甚至可以通過改寫這個函數去響應不同的消息，當然，這是題外話。
WindowProc會調用到CWnd對象的另一個成員函數OnWndMsg，下面看看大概的函數原形是怎么樣的：
BOOL CWnd::OnWndMsg(UINT message,WPARAM wParam,LPARAM lParam,LRESULT* pResult)
{
if(message==WM_COMMAND)
{
OnCommand(wParam,lParam);
……
}
if(message==WM_NOTIFY)
{
OnCommand(wParam,lParam,&lResult);
……
}
const AFX_MSGMAP* pMessageMap; pMessageMap=GetMessageMap();
const AFX_MSGMAP_ENTRY* lpEntry;
/*以下代碼作用為：用AfxFindMessageEntry函數從消息入口pMessageMap處查找指定消息，如果找到，返回指定消息映射表成員的指針給lpEntry。然后執行該結構成員的pfn所指向的函數*/ if((lpEntry=AfxFindMessageEntry(pMessageMap->lpEntries,message,0,0)!=NULL)
{
lpEntry->pfn();/*注意：真正MFC代碼中沒有用這一條語句。上面提到，不同的消息參數代表不同的意義和不同的消息響應函數有不同類型的返回值。而pfn是一個不帶參數的函數指針，所以真正的MFC代碼中，要根據對象lpEntry的消息的動作標識nSig給消息處理函數傳遞參數類型。這個過程包含很復雜的宏代換，大家在此知道：找到匹配消息，執行相應函數就行！*/
}
}
以上，大家看到了OnWndMsg能根據傳進來的消息參數，查找到匹配的消息和執行相應的消息響應。但這還不夠，我們平常響應菜單命令消息的時候，原本屬于框架窗口（CFrameWnd）的WM_COMMAND消息，卻可以放到視對象或文檔對象中去響應。其原理如下：
我們看上面函數OnWndMsg原型中看到以下代碼：
if(message==WM_COMMAND)
{
OnCommand(wParam,lParam);
……
}
即對于命令消息，實際上是交給OnCommand函數處理。而OnCommand是一個虛函數，即WM_COMMAND消息發生時，最終是發生該消息所對應的MFC對象去執行OnCommand。比如點框架窗口菜單，即向CFrameWnd發送一個WM_COMMAND，將會導致CFrameWnd::OnCommand(wParam,lParam)的執行。
且看該函數原型
BOOL CFrameWnd::OnCommand(WPARAM wParam,LPARAM lParam)
{
……
return CWnd:: OnCommand(wParam,lParam);
}
可以看出，它最后把該消息交給CWnd:: OnCommand處理。再看：
BOOL CWnd::OnCommand(WPARAM wParam,LPARAM lParam)
{
……
return OnCmdMsg(nID,nCode,NULL,NULL);
}
這里包含了一個C++多態性很經典的問題。在這里，雖然是執行CWnd類的函數，但由于這個函數在CFrameWnd:: OnCmdMsg里執行，即當前指針是CFrameWnd類指針，再有OnCmdMsg是一個虛函數，所以如果CFrameWnd改寫了OnCommand，程序會執行CFrameWnd::OnCmdMsg(…)。
對CFrameWnd::OnCmdMsg(…)函數原理扼要分析如下：
BOOL CFrameWnd:: OnCmdMsg(…)
{
CView pView = GetActiveView();//得到活動視指針。
if(pView-> OnCmdMsg(…))
return TRUE; //如果CView類對象或其派生類對象已經處理該消息，則返回。
……//否則，同理向下執行，交給文檔、框架、及應用程序執行自身的OnCmdMsg。
}
到此，CFrameWnd:: OnCmdMsg完成了把WM_COMMAND消息傳遞到視對象、文檔對象及應用程序對象實現消息響應。
寫了這么多，我們清楚MFC消息映射與命令傳遞的大致過程。現在，我們來看MFC“神秘代碼”，會發覺好看多了。
先看DECLARE_MESSAGE_MAP()宏，它在MFC中定義如下：
#define DECLARE_MESSAGE_MAP() /
private: /
static const AFX_MSGMAP_ENTRY _messageEntries[]; /
protected: /
static AFX_DATA const AFX_MSGMAP messageMap; /
virtual const AFX_MSGMAP* GetMessageMap() const; /
可以看出DECLARE_MESSAGE_MAP()定義了我們熟悉的兩個結構和一個函數，顯而易見，這個宏為每個需要實現消息映射的類提供了相關變量和函數。
現在集中精力來看一下BEGIN_MESSAGE_MAP，END_MESSAGE_MAP和ON_COMMAND三個宏，它們在MFC中定義如下（其中ON_COMMAND與另外兩個宏并沒有定義在同一個文件中，把它放到一起是為了好看）：
#define BEGIN_MESSAGE_MAP(theClass, baseClass) /
const AFX_MSGMAP* theClass::GetMessageMap() const /
{ return &theClass::messageMap; } /
AFX_COMDAT AFX_DATADEF const AFX_MSGMAP theClass::messageMap = /
{ &baseClass::messageMap, &theClass::_messageEntries[0] }; /
AFX_COMDAT const AFX_MSGMAP_ENTRY theClass::_messageEntries[] = /
{ /
#define ON_COMMAND(id, memberFxn) /
{ WM_COMMAND, CN_COMMAND, (WORD)id, (WORD)id, AfxSig_vv, (AFX_PMSG)&memberFxn },
#define END_MESSAGE_MAP() /
{0, 0, 0, 0, AfxSig_end, (AFX_PMSG)0 } /
}; /
一下子看三個宏覺得有點復雜，但這僅僅是復雜，公式性的文字代換并不是很難。且看下面例子，假設我們框架中有一菜單項為“Test”，即定義了如下宏：
BEGIN_MESSAGE_MAP(CMainFrame, CFrameWnd)
ON_COMMAND(ID_TEST, OnTest)
END_MESSAGE_MAP()
那么宏展開之后得到如下代碼：
const AFX_MSGMAP* CMainFrame::GetMessageMap() const
{ return &CMainFrame::messageMap; }
///以下填入消息表映射信息
const AFX_MSGMAP CMainFrame::messageMap =
{ &CFrameWnd::messageMap, &CMainFrame::_messageEntries[0] };
//下面填入保存著當前類感興趣的消息，可填入多個AFX_MSGMAP_ENTRY對象
const AFX_MSGMAP_ENTRY CMainFrame::_messageEntries[] =
{
{ WM_COMMAND, CN_COMMAND, (WORD)ID_TEST, (WORD)ID_TEST, AfxSig_vv, (AFX_PMSG)&OnTest }, // 加入的ID_TEST消息參數
{0, 0, 0, 0, AfxSig_end, (AFX_PMSG)0 } //本類的消息映射的結束項
};
大家知道，要完成ID_TEST消息映射，還要定義和實現OnTest函數。在此即要在頭文件寫afx_msg void OnTest()并在源文件中實現它。根據以上所學的東西，我們知道了當ID為ID_TEST的命令消息發生，最終會執行到我們寫的OnTest函數。
??? 至此，MFC六大關鍵技術寫完了。其中寫得最難的是消息映射與命令傳遞，除了技術復雜之外，最難的是有許多避不開的代碼。為了大家看得輕松一點，我把那繁雜的宏放在文章最后，希望能給你閱讀帶來方便。
??? 其實，較早前這就描述過MFC六大關鍵技術，也在一些論壇上發表過，但后三篇不知如何遺失了。許多朋友向我索稿，但苦于沒有備份，也不想枯燥地重寫，故推延至今，請大家見諒。
??? 還有，許多朋友說（二）（三）寫得十分不明白，這也是我意料到的地方。我寫文章，很少回頭看一下，有時自己也不知道自己寫了什么。有許多朋友把修改后的版本給我，雖然修改了一點點，甚至僅僅修改了一下錯別字，但讀起來容易理解很多。對此，我內心十分感激。如果有更多的時間，我會修改一下前面的文章，放到我的網站上去！
總結
- 上一篇： C++异常处理try throw cat
- 下一篇： C++播放声音文件