中國的文人，有個根深蒂固的傳統：皓首窮經。

    從三百千千，到四書五經，到諸子百家，詩詞歌賦，琴棋書畫，每個學子往往要經歷漫長的十幾年甚至三十年。所謂十年寒窗無人問，一朝成名天下知，是所有文人的潛藏情節。所以，有老實人說出了老實話：百無一用是書生。我一直覺得他們仿佛在學東方不敗大俠，先對自己狠心點，然后閉門苦練，最后終于明白了萬物滋生的大道，乃至所向無敵。

    作為普通人，我們還是盡早動手為好。

 

    第一項任務很簡單，精確點描述是這樣的：創建一個應用程序，使用兩個Ribbon按鈕，在兩個窗體中切換。

    是啊，用戶做的第一件事情，就是找到功能，然后進入相應的界面，菜單、工具欄還有Vc++2010提供的Ribbon功能區方式，無論怎樣，這都是首先要掌握的內容。

    站在程序員的角度，你最經常遇見的可能是哪些場景呢？界面、讀寫文件、讀寫數據庫、設計業務類，就這些，做得專業點，號稱程序員就順理成章了。我覺得各種知識的講解很多，但如何在實際工作中，做到像模象樣，好象沒有多少這樣的資料。因此，這個系列講解的雖然只是一項不太復雜的功能，但會盡量的講透，涉及到界面、性能、異常、用戶體驗諸方面。

 

    因為是首次接觸VC，那么我給自己定下的規矩很明確：學習階段，絕不考慮重用性問題、絕不考慮擴展性問題、絕不考慮代碼風格問題，盡量在第一時間將功能穩定的實現。在不熟悉語言的時候，你七七八八太多，那簡直是在虐待自己的大腦。語言熟悉后這些東西你有精力再去玩，現在，還是老實點好。

     那么，我們首先面臨的問題是使用傳統的菜單、工具欄形式，還是使用Ribbon界面。這種選擇對于我來說，不是什么問題，喜新厭舊據說是男人的本能，嗯，照照鏡子，我發現里面是一張男人胡子拉碴的臉。然后呢？我遇到的第一個問題，是文檔視圖結構。

     這是一種延續了幾十年的模式，換句話說，是一種古老的模式。大家看看記事本就知道了，處理一種后綴名為TXT的文件，打開、關閉、保存文件，將文件后綴在操作系統注冊到記事本，簡單的說，就是你創建的這種應用，將針對某種專用的格式，相關的一些處理工作，由文檔視圖結構預先的幫你做好，很貼心，是不是？

    所謂文檔視圖結構，馬上動手，用項目向導創建一個簡單的單文檔、單視圖結構的應用，可以看到VS幫我們創建的一些代碼，嗯，四個類：一個應用程序類，是整個系統的入口，然后創建MainFrame實例、后者將管理文檔類和視圖類。文檔類負責處理對這種格式的文檔的各類操作，視圖類負責呈現、編輯這種格式的文檔。

    但是，兩個問題：首先，我們現在已經很少敢于制定自己專有的文件格式，比如各類視頻格式，都是幾家恐怖的巨頭在發布標準然后互相撕咬。一個可憐的程序員竟然做這種不合身份的事情，實在令人齒冷。其次，相對于專有格式而言，我們做桌面應用普遍還是以數據庫應用居多。

    所以我的想法很簡單，文檔類基本不用，放個空殼在哪里。視圖類呢？首先我想找尋類似Wpf的窗體設計器，視圖能不能直接的“畫界面”？很沮喪，不能，我只找到了對話框設計器。接下來，我們知道，若視圖繼承于CFormView，則可以使用對話框設計器來設計界面。 但這樣我們需要做多視圖項目，

    為了利用對話框的界面設計能力、同時保持整個程序的簡單，浮現在我腦子里的，是一種古怪的想法：對話框有一種“子對話框”風格，我們在視圖中直接打開這個對話框，則看起來是無縫集成的，我們就能自如的在兩個對話框之間切換了。

    嗯，有熟悉的程序員馬上要問了：不是有基于對話框的應用程序向導嗎？兩個問題：首先我們希望的是處理多個窗體，但不要彈出，這個是木有辦法的；其次，更重要的是，這時候你不能在應用程序向導中選擇Ribbon方式，也許有“在對話框應用中使用Ribbon“之類的深入研究，但我確實很懶惰，不太愿意在這類事情上消耗時間。

 

    接下來，我按照工作的步驟，簡單的描述完成這項任務的過程。需要說明的是，這個系列的帖子是休閑貼，我不會一邊做一邊截圖一邊寫，時間和精力不允許，所以很難做到step by step的方式，僅僅是列出步驟和基本的知識點，當然也包括初學者肯定會鬧出的笑話。

 

1、創建項目：創建一個MFC應用，在配置向導中，注意勾上“功能區方式”，提供文檔視圖支持，單文檔模式，其他無所謂。項目創建完畢后，運行一下。

 

 

 

 

 

 

 

 

 

 

2、簡單的閱讀一下生成的代碼，次序是App類->MainFrame類->Document類->View類。不要深究，比如View中那堆很混亂的宏，只要從字面理解就行了：定義消息循環，不需要學究到一定要弄懂這堆宏究竟會轉換成怎樣的代碼。讀代碼的方法，嘿嘿，這是秘籍：看看類結構，揣摩一下方法的名字，然后不要太關注每個函數內部的代碼，會很快的。需要注意的問題，是我們經常見到的項目按文件夾組織的方式，這里沒有，VC項目中叫做篩選器，僅僅將同一個目錄下的文件分類，并不改變文件的物理位置。

3、我們將創建兩個對話框，注意：style設為child，去掉確定和取消按鈕，不要邊框。僅僅放上一個靜態文本字段，分別是“第一個”和“第二個”。

4、我們要為兩個對話框創建類，這個不要傻乎乎的自己寫代碼：右鍵，為對話框生成類，就行了。為什么要有這個步驟？對話框以“資源”形式保存，僅僅保留了一個唯一的ID和控件類型、位置、大小等信息，我們畢竟要通過代碼控制其工作，那么創建類綁定這個對話框就是必須要做的事情。

我不太喜歡用記事本寫程序那一套，今后自然會理解：類向導自動的幫我們創建對應的對話框類，一般是繼承自一個公用的基類，添加消息循環等代碼片段，重寫一些虛方法。

5、那么，我們在Ribbon設計器中，創建一個“面板”，然后放上兩個按鈕。

6、當然，需要為兩個按鈕創建“添加消息處理程序”，也是在Ribbon設計器中，右鍵，就能看到了。針對消息類型“Command"”和“Update_Command_UI”都要創建，前者是用戶點擊按鈕后要做的事情，后者我們用來處理按鈕是否可用的問題，當然，這兩個方法添加到View類中。

7、我們現在有了四個消息處理函數，以Command為例，怎樣在視圖中顯示一個對話框？

8、看看下面的代碼：

void CSouGuView::OnButtonHome()
{

    if (CurrentDialog) //如果已經有對話框打開了，干掉它。
    {
        CurrentDialog->DestroyWindow();
        delete CurrentDialog;
    }

    CHomeDialog* dlg = new CHomeDialog(this);  //創建對話框類的實例
    CurrentDialog =dlg; //我們在View中定義的CDialogEx* CurrentDialog; 我們創建的對話框類都是從CDialogEx繼承的，因此，這個指針用來表示當前顯示的窗體。
    CurrentDialog->Create(dlg->IDD,this); //這里創建窗體
    CurrentDialog->ShowWindow(SW_SHOW);  //顯示窗體
    CurrentDialog->CenterWindow(this);//將對話框在視圖中居中，注意屏幕大小改變后，就不再居中，需要在OnSize事件中處理
    CurrentDialog->SetBackgroundColor(RGB(255,255,255));//將背景色改為白色，馬虎應付一下

}

9、然后看看消息循環中的代碼：

BEGIN_MESSAGE_MAP(CSouGuView, CView)
    ON_WM_CONTEXTMENU()
    ON_WM_RBUTTONUP()
    ON_COMMAND(ID_BUTTON_HOME, &CSouGuView::OnButtonHome)
    ON_WM_SIZE()
    ON_UPDATE_COMMAND_UI(ID_BUTTON_HOME, &CSouGuView::OnUpdateButtonHome) //注意這句，如果對應的對話框已經打開，則按鈕不可用
    ON_COMMAND(ID_BUTTON_QUOTE, &CSouGuView::OnButtonQuote) //注意這一句：如果用戶點擊這個按鈕，執行OnButtonQuote方法。
    ON_UPDATE_COMMAND_UI(ID_BUTTON_QUOTE, &CSouGuView::OnUpdateButtonQuote)
    ON_COMMAND(ID_BUTTON_CHART, &CSouGuView::OnButtonChart)
    ON_UPDATE_COMMAND_UI(ID_BUTTON_CHART, &CSouGuView::OnUpdateButtonChart)
END_MESSAGE_MAP()

10、當然，如果你打開了這個對話框，可以讓這個按鈕失效：

void CSouGuView::OnUpdateButtonHome(CCmdUI *pCmdUI)
{
    if (CurrentDialog)
    {
        pCmdUI->Enable(CurrentDialog->GetRuntimeClass()!=RUNTIME_CLASS(CHomeDialog));
    }
}

很顯然，消息映射中ON_UPDATE_COMMAND_UI(ID_BUTTON_HOME, &CSouGuView::OnUpdateButtonHome)，是對應這個的。

大致的意思：如果當前有對話框打開，那么：如果是CHomeDialog類的實例，這個按鈕就不可用。已經打開了這個對話框，你還打開它干嘛？

11、另一個對話框也是一樣，算起來我們創建了四個消息處理函數。代碼就復制一下，運行，能夠看到來回切換的效果就行。

12、存在的問題：

     首先，VC的對話框的布局問題，很原始。原始的意思，就是你需要自己處理。當你改變主窗體大小、或者在不同分辨率的機器上，對話框的所有控件總顯示在視圖的左上角，界面是很丑陋的。這是以后的問題，我最后的解決方案是：多數情況下窗體比較小，保持居中顯示就行了；少數情況下，比如顯示K線圖的時候，需要自動適應主窗體的大小，使用一套叫做EasySize的宏解決問題。

    其次，這里雖然實現了對話框居中顯示，但由于OnSize事件中沒有處理，窗體大小改變的時候，對話框的位置將不再居中，這個此后再處理。

 

總結一下遇到的問題：

1、首先是所謂指針的概念：

    其實這真是幼兒園級別的問題，往下看，五分鐘差不多能夠弄清了：我們假設內存有1000個字節(不用說2G了，只說1k吧，好描述)，從0開始給每個字節編號，最后一個是999。這個編號就是指針，很顯然，指針實際上是整數，表示內存的編號，也就是內存地址。我們常見的，32位操作系統的電腦，不能利用4G內存的事情，大家可以算算，32位也就是4個字節的整數，最大值是什么。

    比如我們定義一個int 指針，怎么做？

    int *p；

    意思是我們現在有了一個int指針變量p

    然后p=0，什么意思？指向內存0的位置。

    你如果沒有為指針分配空間，那么對指針的操作就是一種令人崩潰的游戲。

    雖然指到了那個地方，但那里并沒有你分配的一個整型的4個字節的空間，而很可能是另一個變量的位置。

    所以第二步我們可以為其分配空間：

    p=new int;

    或者p=new int();

    這個時候，你設置斷點看看，p的值已經變化了。怎么回事呢？系統將從空閑的內存中畫出四個字節給你，并將這小片內存的地址：也就是第一個字節的編號傳給p。系統同時會給這部分內存做上標記，繼續分配空間的時候，不要再拿出來獻寶，

     好吧，第三步：這片內存里的值是不可知的，為其賦值。

     *p=10；

     嗯，第四步，我想將p的值傳給一個局部變量 int x;

     容易：x=*p；看看，x現在也是10了。

     注意x是局部變量，不是指針，那么背后發生了什么事情呢？p所指向的四個字節的內容，拷貝到x所占用的四個自己的內容，如此而已。

     那么第五步，我們反過來，令x=100，想讓p接管x所占用的四個字節，怎么辦？

     p=&x；

    這就行了，&表示x的地址，再看看p，他的值顯然發生變化了，指向另一片位置了么。

    不過馬上你面臨第6步：

    原來p的那四個字節呢？沒主了，誰都遺忘了，它還在那里，不再能夠使用。內存泄漏？一個函數可能短暫時間執行幾千次，這樣不斷失去控制、不斷丟失的內存就可能膨脹起來，最終的結果大家很容易想象。內存泄漏是很多大俠不斷用來表達自己功力深厚的東西，其實不復雜是不是？

    第7步，怎么避免呢？

    容易，請在改變p之前，先delete p;先不說執行析構方法之類，我們簡單的理解：將p指向的內存空間還給系統，那么，雖然p指向其他地方的話，這塊地方也能繼續分配給其他變量。

    第8步，那么int類型的局部變量，是不是也要delete呢？不需要，堆的概念、棧的概念也不用多講，一個函數結束的時候，所有局部變量都會自動的析構，不用我們操心。只有用手工方式分配內存的，比如new出來的，需要我們處理。我最初鬧過這個笑話，自己在函數里創建一個對象，退出前自作聰明的運行其析構函數，程序運行時崩潰，因為析構方法執行了兩次，第二次執行的時候那個對象已經不存在了。嗯，這種錯誤犯過兩次，弄半天才找到原因，相當于在同一條溝溝里跌倒兩次，所以我對自己的智商也委實不太自信。

    第九步：int畢竟是簡單的，你創建一個類的實例，用指針指向它，一切行為沒什么不同，兩個區別：1、你創建的對象可能需要更多的空間；2、p->訪問對象的成員，對象x則用“.”這種符號。

    需要一個月才弄清指針的概念嗎？不需要，沒有更多的知識了，指針的指針是什么？嗯，指向指針變量本身的指針而已；Void *是什么：指向一塊不知類型的內存空間罷了。p++什么意思？指針越過其類型所占的字節，這里是加4。如果你刻意將這種概念弄得太精巧和復雜，要整出很多變態的用法，我要問問你為什么？你其實只需要這些知識就能輕松的做事，何必折磨自己的大腦。

    第十步，我是怎樣弄清這些的？知道內存，知道內存地址，知道指針是存放內存地址的變量，這么三句話之后，上面的這些不是很自然的理解了嗎？

    第十一步，有大牛說過，不解決內存泄漏的問題，C++無法做超大型的項目，怎么辦？嗯，搜索一下“智能指針”，不過好象我們很少做超大型的項目吧？雖然這里有高手說起500萬行以上代碼的項目，但做那個的，我覺得和我們幾乎是兩個世界的人物，或者就是一幫精神病院的家伙。暫時就不要杞人憂天了，發現問題解決問題就是，仿佛一句流行的官話：“發現一起，查處一起”，當然，聰明人馬上會想到：怎樣才能發現？誰來監督你是否去想辦法發現了？怎樣查處？誰能知道是否真被查處了？查處了以后會不會馬上就復出？中國語言的模糊性，注定了中國程序員的質地。

2、然后是頭文件的問題：

    對于習慣C#命名空間的人來說，頭文件真是很無聊的東西，太古老、太原始，Too simple,some times naive。

    我很快弄清了原因，為什么這個是需要的？.net 最終編譯之后，保存了元數據，所以你使用一個dll，有反射機制可用。C++沒這種東西。

    在頭文件中聲明，在源文件中實現。

    聲明的意思是告訴編譯器，我這里定義了一個類，編譯器只需要知道，卻不會將這些東西編譯到obj或者dll中去。事實上，主要的作用，是編譯器知道某個對象分配多少空間，相當于編譯器使用的參數。

    源文件中include “xx.h”

    意思是將頭文件全文復制到這里，然后一起交給編譯器。

    在這里我鬧的笑話很簡單，就是void CSouGuView::OnButtonHome()

    看看這個符號“::”

    表示這個類的方法，頭文件里要聲明，源文件里要實現。

    如果沒有這個呢？

    最初我本能的在源文件中寫int xxxx；

    當然，不在任何函數內，用起來似乎也比較正常，但總是很奇怪，為什么這里改變了，在那里它也同樣改變了。

   直到后來出現問題。

   甚至你這樣自由的在源文件中定義不帶“：：”符號的函數

   似乎也可以用，但卻很奇怪為什么里面的智能感知失效了，用類的成員會出現編譯錯誤。

    噢，這種簡單的問題是一周后才弄清楚的，不要笑話我，所有人都會碰到的，高手們不會講解這種問題。   

3、代碼的壞味道：

    極限編程、Scrum這類敏捷流派，耳熟能詳的一句話是：“當你復制剪切的時候，就要嗅到代碼的壞味道，啊，重構的時機來了。”

    看看，兩個Command消息函數、兩個update的消息函數，是不是都是復制的？為了重用，這里顯然要重構一番是吧？對不起，我現在沒工夫，就這么對付了。要知道自己的目的，時間花在主要目的上，對于重構也好、對于怎樣將代碼設計的更柔韌也好，我相信自己比多數人都會強一些----可是我現在在干什么？盡快實現功能，熟練掌握Vc++。重構不需要時間嗎？需要的，但這個階段不能花這種時間。這個小的應用程序，總數不超過15個窗體，幾秒鐘就能復制粘貼一番，估計到項目結束之后才有空去考慮這個問題。

    第二個壞味道，是View類必須知道每個對話框類的名字，當然，這也意味著有多少對話框就要include多少頭文件。哇，設計模式發揮作用的地方到了，為每個類提供一個創建實例的方法，然后整個接口？創建一個對話框的基類？我說是吃飽了撐的，有閑的時候再做好不好？每個小時都很重要，你追求的是可擴展性，可是至少要等到你的產品做出來再說吧？或者今后就完全沒有擴展的需要呢？或者今后接手的是個菜鳥呢？最優先考慮的肯定是如期完成項目，可擴展性服務的是程序員而不是用戶，而大量使用各類設計模式，因為更抽象，所消耗的時間往往是簡單實現的數倍以上，是一個工時和5個工時的區別。是否能夠分清重點，是智商是否達到及格線的問題，不是技術能力問題。并不是某位高手說“我主要找寫庫之類的崗位”，那就更高人一等，雖然寫庫這種詞聽起來就有些別扭的味道。

    做類設計的時候，多一個類可能意味著10%以上的理解難度、開發成本的增長，所以我的目標往往首先是用最少的類實現，只在會影響到實現、或者通用性考慮不足會加大開發成本的情形下，才考慮那些稍稍抽象的東西。我當然也經歷過設計模式狂熱的短暫階段，以這種實用主義、直觸本質的學習方法，武器顯然是不缺乏的。最明顯的例子，大家可以看看通達信的股票行情軟件，這樣以產品吃飯的公司來說，居然存在針對不同證券公司的多種版本，對于開發團隊的維護、升級來說，這絕對是一個災難：不同的公司顯然會提出一些各自特色的要求，有些可以拒絕，不能拒絕的往往是公司很關注的部分，這要做好業務分析、精心抽象，并通過通用化的設計，進行單一版本的升級來向所有客戶提供同樣的功能，是否使用由客戶自己決定。這種多樣版本并存的情形，源代碼管理、開發人員是否永遠在公司、自動升級服務器的部署，復雜度和工作量完全是幾何級數的增長。至于應用項目，短周期的情形下，則要盡可能回避復雜化的苗頭。軟件開發首先是生意中的一個環節，在保證交付、穩定運行的前提下，開發和維護成本該怎樣控制、如何保證如期交付、如何保證符合合同規定的質量要求，其實是團隊要重點平衡拿捏的，這種觀念必須貫穿于軟件過程的始終。簡單的說：你是在工作，不是在研究。

    所以按照前面說的，我理直氣壯的忽略這些“代碼的壞味道”，留待項目結束之后。

 

    再總結一下這短短幾行代碼，我們逐漸嗅到了些什么東西，當然，談不上熟悉：

    1、消息循環：宏語句，不要探究細節，從字面上理解足夠了。

    2、類向導：能夠用工具就不要手工寫了，相當于代碼生成器，多用。

    3、頭文件的問題：理解多數情況下，頭文件僅僅是嵌入源代碼的“聲明部分”。

    4、調試、斷點設置之類，這個沒什么變化。

    5、指針：整數，記錄某塊內存的開始地址。

    6、文檔視圖機制：當作闌尾吧，留著。

    7、Ribbon界面的設計：操作問題罷了。

    8、對話框的設計、創建類、在視圖中顯示子對話框。

    9、this指針：和C#中一樣，this指向是指向類的當前實例的指針，訪問類的成員，不是我們習慣的“this.xxx”而是this->xxx，因為是指針么。創建對話框的方法中，this作為參數，意思是將目前的這個view對象的指針，作為參數傳遞進去。

    可能都不是特別的清晰，但不停編碼的過程中，不知不覺的你的理解會一步步增強。慢慢來，最終也不會超過一個月的，我們今后會遇到std、stl、各類字符串、unicode問題、多線程問題、Directx Api，發現一起查處一起，這項功能做完，由任務的驅動會逼著我們逐一弄清所有這些語法細節，這樣比你主動的去看書強吧？到時候象我這樣寫幾篇博客總結一下，思路能夠整理得更為清晰、眾多有如牛毛或者過江之鯽的高手們如果肯指出理解上的問題的話，又能夠更上層樓，何樂而不為？

 

略微解釋幾句：

    這個系列，由于是面向初學者的東西，主要是希望提供一個學習的路徑圖，因此內容相當的初級，也不會太過詳細。這里還是希望高手們要么當作游戲之作，要么帶點容忍異己的心態。當然，我說起高手，一般是當貶義詞用的，這是習慣，很難改變。同時因為時間的關系，一篇帖子往往用不了半個小時，兩分鐘寫個提綱，然后順著往下胡侃，因此錯漏之處必定也有很多，就內容挑毛病我是很歡迎的，也會盡量修改。至于對我的人品挑毛病的話，就看興趣了：興致高的時候我會爭鋒相對，練練嘴皮子，體驗斗嘴的樂趣，對心態保持年青、養顏防老還是很有好處的。興致不高的時候直接忽略，所以還請各位罵手體諒，不予還擊并不是不尊重你的勞動，當然也不是看不到您鼻孔朝天一臉不屑的模樣，而是此人正在沮喪中……非洲還有許多孩子沒有校車呢。

    關于侯捷，嗯，我還是強調一下：這個人真的很無聊。他的粉絲眾多，也掩蓋不了這種無聊。你可以喜歡他“滴人”，我也可以不喜歡他的方法，我不能勉強你，也希望你不要逼著我和你一起做粉絲，既然都那么博大精深，我也期待你們成為星星本身，呃，通過追星這種方式？偷偷說一句：我唯一喜歡的是他的表達方式，這是個人好惡的問題，無關其他。

    繼續預告：下一篇將將講述怎樣設計“導入日線對話框”的界面，如何獲取對話框控件的值、處理相應的消息。