做一個MFC程序的時候碰到一個需求。就是需要根據定制情況，動態生成菜單，菜單的具體結構和信息是之前不知道的（因此不能利用工具構造），點擊不同類型的菜單會觸發特定的一類事件（需要動態綁定事件）。這種需求實際是蠻不BT的，很多場合下都可能會有，用C#寫了個Demo花了不到半個小時。但轉到MFC下來寫，就費盡周折。其實這個問題代表了在MFC中動態創建資源綁定事件的一般性問題，所以總結一下。

動態創建菜單需要先了解CMenu類。通常我們利用工具繪制一個菜單，每一個菜單項下都可以視為有一個CMenu類。它們聯系在一起，形成樹狀。典型的一個菜單對應過來是如下圖這個樣子：

 

如上，CMenu可以分成三種，一個是Popup（黃色），一個是Separator（灰色），一個是Item（紅色）。前兩種都是沒有ID信息的，Popup有一個指針，指向其SubMenu；Item保存各種信息有ID可以響應事件；Separator，恩，基本是一窮二白的。

CMenu的CreateMenu方法可以創建一個菜單資源，用DeleteMenu（包含所有子菜單）或DestoryMenu可以銷毀菜單資源，用AppendMenu可以添加一個菜單。了解這些內容，就可以開工了，現實現上圖所示的MainSubMenu1下菜單的動態創建，代碼如下：

    // 假設在ChildFrm中，調用該方法獲得當前的主菜單指針
    CMenu* mainMenu = AfxGetMainWnd()->GetMenu();
    CMenu* subMenu = NULL;

    // 遍歷主菜單下的各級菜單尋找名為MainSubMenu1的菜單

    int menuCount = mainMenu->GetMenuItemCount();

    for(int i = 0; i < menuCount; i++)
    {
        CString menuName;
        if(mainMenu->GetMenuStringA(i, menuName, MF_BYPOSITION)
            && menuName == "&MainSubMenu1")
        {
            drawingMenu = mainMenu->GetSubMenu(i);
            break;
        }
    }

    // 移除原有的菜單項
    int subMenu1Count = subMenu->GetMenuItemCount();
    for(int i = subMenu1Count - 1; i >= 0; i--)
    {
        subMenu->DeleteMenu(i, MF_BYPOSITION);
    }

    // 動態添加Item菜單項
    for(int i = 0; i < 2; i++)
    {

        CString message = "";

        subMenu->AppendMenuA(MF_STRING, ID_BEGIN + i, message.Format("SubSubMenu%i", i);

    }

    // 添加分隔符

    subMenu->AppendMenuA(MF_SEPARATOR);

    // 添加彈出式子菜單

    CMenu * popupMenu = new CMenu();
    popupMenu->CreateMenu();
    for(int i = 0; i < 2; i++)
    {

        CString message = "";

        popupMenu->AppendMenuA(MF_STRING, ID_BEGIN + 2 + i, message.Format("PopupSubMenu%i", i));

    }
    subMenu->AppendMenuA(MF_POPUP, (UINT_PTR)popupMenu->operator HMENU(), "PopupMenu");

有幾個需要注意的地方，一個是主菜單的指針獲得，可以參考《MFC框架各部分指針獲取方式》一文。另一個是Popup的菜單建立，策略是分成兩部分，先new出內存在Create出資源，缺一不可。最后一個是為每個Item菜單合理分配ID，這些ID須事先預留出來，在MFC中，至少40000到49000通常都是沒人用。

這也就引出下一個問題，即菜單事件的動態綁定。我們知道在.net中，事件是真正動態綁定的，而MFC中的事件都是只能靜態綁定，這是由兩者的編譯方式決定的。所以，在MFC中需要定義菜單事件，你需要先挖好坑（預留足夠ID），規定每個坑種什么羅卜（將不同類型的ID綁定到不同類別的事件處理函數上），最后才能按坑種羅卜（為執行相應事件的菜單設置相應的ID）。

可以有兩種方式來綁定對應ID處理的事件，一個是通過ON_COMMAND_RANGE宏（想一下ON_COMMAND宏會不會派上用場？）在MessageMap里綁定批量處理事件的函數；另一個是重載PreTranslateMessage函數，截獲并判斷ID來進行處理。思想都是類似的。值得注意的是，通常還需要配套使用ON_UPDATE_COMMAND_UI_RANGE來保證動態創建的菜單Enable為True，否則很可能菜單不可以點擊（我就被郁悶過很久：（）。

文章來源:http://www.cnblogs.com/duguguiyu/archive/2007/07/21/826816.html 前人在CSDN總結的，曾經幫助過我，整理總結一下，希望也能幫助一下別人。
    



文章來源:http://www.cnblogs.com/duguguiyu/archive/2007/06/22/792511.html

最近在寫一些關于MFC的東西，是因為做了些MFC的項目，一些零散的東西需要總結一下。但這并不代表我有些喜歡他了，其實還是蠻討厭的。畢竟看了.Net Framework，再看N多年前的MFC，多少是有些不順眼的。機理上的東西不敢多說，有些變量和方法名字的設置，站在FCL的設計角度看了，多少覺得有些不爽。也許是我太弱，也許是因為它的設計上考慮還是沒有足夠的經驗，列舉一些，娛樂娛樂。

1. 在構造一個自定義的Dialog對象時，我們會傳入一個CWnd的指針進去，那個名為pParent的對象。但當我在Dialog中調用GetParent函數的時候，無論傳進的是什么指針（比如CYourView），得到的返回值都是指向CMainFrame的指針。曾經由于這個我調了N久的程序，我承認這是由于我對MFC的了解不夠造成的，但這名字也太具有迷惑性了吧。

2. 當然還有臭名昭著的UpdateData函數，很榮幸在這點上我和大師一樣，每次用到的時候都要停下來查看一下才能分清楚那個詭異的bool變量的意義。也許這在有IDE的時候不是問題，但問題是我看書的時候就會很麻煩了。分離成兩個明確命名的函數，也許會好很多。

3. ShowWindow。恩就是它。看到這個名字，不熟悉MFC的人應該都會覺得它是用來顯示一個窗口的。但...，其實它兼有顯示和隱藏窗口的功能，決定這一切的又是一個詭異的bool量...

4. MoveWindow和SetWindowPos。這一對不夠專注的兄弟。它們太強大了，所能做的事遠不止Move和SetPos那么簡單，當我想改變一個窗體大小的時候，我翻來覆去的找函數，萬萬沒想到，原來是這對名不副實的兄弟的工作，Faint...

5. GetWindowRect和GetClientRect。其實他們也許沒有問題，有問題的是我，我不喜歡用引用量代替一個貌似應該由返回值完成的東西...

6. SelectObject。為什么你傳入一個新的Object，它返回一個老的Object呢？不止我一個人，很多人都被這個搞暈過，其實我也不明白，一個函數做兩個函數的事，這確實有點熱心過度了吧...

7. afx_msg。一個永遠都沒被用到的預留量，這樣的東西在MFC中有很多...

文章來源:http://www.cnblogs.com/duguguiyu/archive/2007/06/21/792426.html

利用MFC向導建立一個工程，然后開始編碼。這就是我通常做一個MFC工程的開始。但向導可不是一個守規矩的東西，它會為你添加很多的代碼，為你設置大量的編譯和鏈接選項。大部分時候這種工作是善意的，但是好心不一定辦好事，你不好好了解它，它會給你帶來很多的麻煩。

在配置一個基于OpenCasCade的程序中，我就遇到了很多麻煩。MFC向導在它所生成的View, Document等架構類中都添加了一段如下代碼：

#ifdef _DEBUG
#define new DEBUG_NEW
#endif

在Debug狀態下（VS會為你默認添加一個_DEBUG的預編譯項），你在該類中調用的new操作符都會被DEBUG_NEW所取代，請警惕這個行為，如果你重載過某個類的new，很可能就會由于它導致無法編譯通過或運行不正確。

除此之外一些默認的設置也要注意，在VS2005中是默認支持Unicode的，它會在你的編譯選項中加入/D "_UNICODE" /D "UNICODE"。這就會使得CString和你可能用到的std::string存在很麻煩的轉換問題。你需要修改項目屬性中General-->Character Set為not set，將其設為ununicode，保證與std::string的一致（當然你還可以運用其他的解決方法滿足你的需求）。

有時候IDE也會“好心辦壞事”，比如在一個解決方案中有兩個工程，你為A添加B的編譯依賴，在A的鏈接選項中就會悄悄加上對B生成的dll的引用。當你某天整理代碼取消了這個依賴的時候，你突然發現莫名的出現了很多link錯誤。不要慌張，在A中添加上B鏈接項就好了，這項工作其實是你必須自己做的，只是你添加了依賴編譯器非常主動的幫你完成了。

也許你看上面的錯誤都很簡單，但如果不小心，也許有天也會像我一樣深陷其中半天爬不出來。總之，在天天用VS2005建MFC工程的時候，提前做好兩件事。一件是通讀一遍系統默認生成的代碼，做到心中有數，每一條莫名其妙的東西都要了解一下它的用途；另一件是在剛開始和改變了工程屬性之后查看一下你的編譯和鏈接命令，搞清楚它做了什么事，有時候命令行雖然難記一點，但確實是一目了然，你可以不必每天用命令行編譯程序，但一定要對這些命令心如明鏡，了如指掌才好。

文章來源:http://www.cnblogs.com/duguguiyu/archive/2007/06/21/791161.html