前言：以下的學習筆記主要前幾章的知識，最重要的爲兩個方面一個是mfc的仿真還有就是mfc的整個框架，加深了對document/view的理念。筆記主要是從書中摘抄的，如需詳細瞭解可以去下侯捷老師的《mfc深入淺出》看看。
1.
call back 函數，意思是指「在你的程序中，被Windows 系統調用」
的函數。這些函數雖然由你設計，但是永遠不會也不該被你調用，它們是爲Windows 系
統準備的。
實際調用只是將函數的地址當做參數傳遞。
2.wm_close wm_destroy wm_quit
爲什麼結束一個程序複雜如斯？因爲操作系統與應用程序職司不同，二者是互相合作的
關係，所以必需各做各的份內事，並互以消息通知對方
3.核心對象（event，mutes，semaphore,file,file_mapping,process,thread）
核心對象是系統的一種資源（噢，這說法對GDI 對象也適用），系統對象一
旦產生，任何應用程序都可以開啓並使用該對象。系統給予核心對象一個計數值（usage
count）做爲管理之用。
前三者用於執行線程的同步化：file-mapping 對象用於內存映射文件（memory mapping
file），process 和thread 對象則是本節的主角
4.
Frame1 並沒有new 任何對象，反倒是有一個全域對象theApp 存在。
C++ 規定，全域對象的構造將比程序進入點（在DOS 環境爲main，在Windows 環境爲
WinMain）更早。
至於執行結果完全是c++構造函數在繼承類中所表現的特性：先調用父類的構造函數，析構函數剛好相反
5.
從frame2可以看出mfc在初始化時，幹了哪些事情 ；主要是兩個初始化函數
CWinApp::InitApplication；CMyWinApp::InitInstance
6.RTTI（執行時期型別辨識）
類別型錄網：這其實就是我們數據結構中學習的鏈表知識。意指針的形式把一個個類連接起來的；
爲了構建者這樣一個類圖：微軟巧妙的用宏畫了這張圖（這個宏怎麼看都讓人煩啊，最好自己手動的展開一個然後帶入看看）
DECLARE_DYNAMIC /IMPLEMENT_DYNAMIC 宏
一個用於結構體的定義，一個用給結構體的賦值
frame3就是用上面的兩個宏構建了一個類型型錄網；需要注意的是在對於鏈表的都節點的特殊處理；
frame4就是在frame3的CObject 中加上IsKindOf 函數的聲明與定義；用於判斷類之間是否有親屬關係
7.Dynamic Creation (動態生成）
動態生成的困難點：你沒有辦法在程序執行期間，根據動態獲得
的一個類別名稱，要求程序產生一個對象
DECLARE_DYNCREATE /IMPLEMENT_DYNCREATE 宏
CObject* (PASCAL* m_pfnCreateObject)()這個函數指針保存了CObject* CreateObject()函數的指針，而這個函數在是現在過程
中動態創建了對應的類。
需要對應的類對象時，只需要調用m_pfnCreateObject這個指針指向的函數即可
8.從宏的定義我們很清楚可以看出，擁有動態生成（Dynamic Creation）能力的類別庫，
必然亦擁有執行時期類型識別（RTTI）能力，因爲_DYNCREATE 宏涵蓋了_DYNAMIC
宏。
9.Persistence（永續生存）機制
Persistence，意思就是把對象永久保留下來
DECLARE_SERIAL/ IMPLEMENT_SERIAL 宏
這個東西看起來感覺蠻複雜的，不過有了動態生成的能力其實也很簡單。就是本來由你輸入類名生成，變成從文件中讀再生成
10.Message Mapping（消息映射）
Windows 程序靠消息的流動而維護生命；
將消息與表格中的元素比對，然後調用對應的處理例程，這種動作我們也稱之爲消息映射（Message Mapping）；
其實也是構建一張消息映射表，更上面的類別圖一樣。也是通過宏來實現的。
DECLARE_MESSAGE_MAP()//聲明
//實現
BEGIN_MESSAGE_MAP(theClass, baseClass)
ON_COMMAND(id, memberFxn）
END_MESSAGE_MAP()
11.Command Routing（命令繞行）
其實就是用虛函數玩的把戲
12.工具這章直接跳過了：vs都出到13了，版本之間還是有區別的
13.第5章就是告訴我們mfc在軟件項目的定位以及怎樣的心態看待它。
其實mfc說到底就是個工具，而且還是個已經落伍的工具。微軟現在都已經不再更新了。
當然只要微軟不退出歷史的舞臺，mfc永遠是有市場的。
MFC 是一個零組件超級市場，所販賣的零組件功能以及零組件彼此之
間的關係都已定義好；我們選擇自己喜歡的零件，兜出一個應用程序
14.當我們面臨軟件工業革命，我們的第一個考量點是：我的軟件開發技術要從哪一個技術
面切入？從raw API 還是從高階一點的工具？如果答案是後者，第二個考量點是我使用
哪一層級的工具？GUI toolkits 還是Class Library 還是Application Framework？如果答
案又是後者，第三個考量點是我使用哪一套產品？MFC 或OWL 或Open Class Library？
這個看了很有感觸，如果我們只是因爲公司用的mfc而只學習mfc，最終的成就必然很低啊。如果只是跟
着別人的腳步，永遠只能更隨而不能超越
15.1989 年微軟公司成立Application Framework 技術團隊，名爲AFX 小組，用以開發C++
對象導向工具給Windows 應用程序開發人員使用
16.CWinApp 代表程序本體 取代 WinMain的地位
■ CFrameWnd 代表一個主框窗口（Frame Window） 取代 WndProc的地位
CWinApp 之中的成員變量將因爲theApp 這個全域對象的誕生而獲得配置與初值。如果
程序中沒有theApp 存在，編譯聯結還是可以順利通過，但執行時會出現系統錯誤消息
17.源代碼部分，因爲以前看過孫鑫老師的視頻（推薦）再加上現在工作原因大概的東西我都瞭解。
CMyWinApp theApp; 程序就是從這啓動的
（1）在構造theApp的時會調用程序的入口函數AfxWinMain()（可能不是直接調用的）；
進入AfxWinMain(...)函數後一起就那麼的熟悉了，
（2）先初始化AfxWinInit(...) 給theApp初始化，還有就是主線程的初始化
（3）InitApplication 初始文檔模板管理者類CDocManager,由它管理應用程序所包含的文檔模板；
文檔模板在mfc中很有用，就是靠它把幾個主要的類聯繫到一起的
(4)InitInstance 調用我們自己的InitInstance 函數，常用在界面起來前做處理時一般都會在這函數
裏面添加處理。使用過程中這個函數比較常見
（5）CWinApp::Run 程序生命的活水源頭 ，是程序進入消息循環中
18.MFC 把消息主要分爲三大類:爲什麼怎麼分，這主要是有消息映射圖的結構決定的
（1）.標準Windows 消息（WM_xxx）的對映規則：
1、除WM_COMMAND之外，所有以WM_開頭的消息。
2、從CWnd派生的類，都可以接收到這類消息。
(2)命令消息（WM_COMMAND）的一般性對映規則是
1、來自菜單、加速鍵或工具欄按鈕的消息。這類消息都以WM_COMMAND呈現。在MFC中，通過菜單項的標識（ID）來區分不同的命令消息；在SDK中，通過消息的wParam參數識別。
2、從CCmdTarget派生的類，都可以接收到這類消息。
(3)「Notification 消息
1、由控件產生的消息，例如，按鈕的單擊，列表框的選擇等均產生此類消息，爲的是向其父窗口（通常是對話框）通知事件的發生。這類消息也是以WM_COMMAND形式呈現。
2、從CCmdTarget派生的類，都可以接收到這類消息。
總結：乍看MFC 應用程序代碼，實在很難推想程序的進行。一開始是一個衍生自CWinApp 的全
域對象application object，然後是一個隱藏的WinMain 函數，調用application object 的
InitInstance 函數，將程序初始化。初始化動作包括構造一個窗口對象（CFrameWnd 物
件），而其構造式又調用CFrameWnd::Create 產生真正的窗口（並在產生之前要求MFC
註冊窗口類別）。窗口產生後WinMain 又調用Run 激活消息循環，將WM_COMMAND
（IDM_ABOUT）和WM_PAINT 分別交給成員函數OnAbout 和OnPaint 處理。
18.Document Template 的意義
（1）.程序每打開一份文件（資料），就應該產生三份對象：
1. 一份Document 對象，
2. 一份View 對象，
3. 一份CMDIChildWnd 對象（做爲外框窗口）
（2）Document Template 接受了三種類別的CRuntimeClass 指針，於是每當使用者
打開一份文件，Document Template 就能夠根據「類別型錄網」），動態生
成出三個對象（document、view、document frame window）
(3)A.CMultiDocTemplate 構造式的第一個參數置入IDR_SCRIBTYPE，
代表RC 文件中的菜單（MENU）、圖標（ICON）、字符串（STRING）三種資源
