本着不重写已有功能的原则，在MFC中发掘了一圈，没发现有可用的现成控件，上网搜了一下，发现有人做过，但竟然还收费出售，so faint，只能自己动手做一个。

其实思路还是蛮简单的，就是放个Edit控件处理它的键盘输入事件，防止删除之前的记录和提示信息，还要处理结束命令，比如回车、空格之类的。主要有以下几个步骤：

1. 将输入框内的字符串分段，比如分成三段log, tip和command，前两段都不能被修改，command的内容为可修改的。在结束了command输入后，要同步各字符串，示例代码如下：

void CMainFrame::InitCommand(CString tip)
{
 // 记录老字符串，类似于UpdateData(true)

 this->GetText();

 // 设置新的log
 if(this->m_log != "")
  this->m_log += "\r\n";
 this->m_log += tip;

 // 更新字符串，类似与UpdataData(false)
 this->SetText();

 // 将光标置于字符串的尾部（否则光标会在一开始的位置）

 ((CEdit *)m_commandDialogBar.GetDlgItem(IDC_COMMAND))->SetSel(this->m_log.GetLength(),
  this->m_log.GetLength());
}

2. 重载PreTranslateMessage事件，处理键盘信息，示例代码如下：

 BOOL CMainFrame::PreTranslateMessage(MSG* pMsg)
{
 if(pMsg->message == WM_KEYDOWN) // 处理键盘按下事件
 {
  // 判断是否是在脚本输入框上输入的

  if(GetFocus() == m_commandDialogBar.GetDlgItem(IDC_COMMAND))
  {
   // 如果选择的是非正在输入的文字，抛弃这个事件

   DWORD selectedRegion = ((CEdit *)m_commandDialogBar.GetDlgItem(IDC_COMMAND))->GetSel();
   int selectedStart = LOWORD(selectedRegion);
   int selectedEnd   = HIWORD(selectedRegion);

   if(selectedStart != selectedEnd && selectedStart < m_log.GetLength())
    return true;

   if(pMsg->wParam == 8 && selectedStart <= m_log.GetLength()) // 阻止删除之前的文字
    return true;

   if(pMsg->wParam == 13 || pMsg->wParam == 32) // 当输入空格或回车是发送消息
    this->SendCommand();
  }
 }

 return CMDIFrameWnd::PreTranslateMessage(pMsg);
}

其中SendCommand的内容可自定义，处理完成后不要忘记执行1的操作，同步一下字符串就OK。实现效果如下：

当然，这是一个最简单的实现，还有很多问题没有处理，比如自定义菜单，屏蔽系统菜单等；还有很多工作可以做，比如封装成一个自定义控件，做更好的显示效果等等。但基本的思路还是一样的，恩，如果谁有更好的实现方案，也欢迎留言，谢谢先：）

参照这篇文章，可以搞定同码制的字符串转换，如果有unicode到非unicode的转换问题，还需要另寻高招。我通常就是归一化，把工程属性-->General中的Character set统一选为no set或unicode。每每此时，我都会出奇的想念C#。。。

很多时候，能用模态对话框的情况下，都会用模态的。虽然Copper 老先生指着鼻子苦口婆心的教导了我们，但有时候人懒脸皮也就厚了，无所谓了。但，世界总是很残酷，很多时候（比如需要在处理对话框事件的时候也能响应窗体事件），我们不得不去面对非模态对话框。其实了解了资源管理的模式，就像扒开了非模态对话框半遮的琵琶，可以很坦然的面对了。

模态对话框的资源分成两种，一种是内存资源，一种是非内存资源。单看非内存资源的管理，其实和内存资源的管理原理是一样的。在C++中，内存资源的管理讲究new和delete配对，同理，非内存资源的管理需要create和destroy出双入对。在这篇文章中，基本体现了非模态对话框资源管理的一个基本模式，即内存资源管理和非内存资源同步。

这样通过判断内存资源是否占用（即指针是否为空）就可以判断非内存资源的使用状况。当指针为空，说明对话框还未创建（非内存资源未申请）；当指针不为空，对话框已创建，正处于可见或不可见状态。这样将两部分资源管理合并在一起了，只需要判断指针是否为空就可以了解对话框资源的状态。一些内存管理的手段，比如类管理思想（将delete和destroy放到类的析构函数中），可以实现资源的自动管理。

为了实现这种管理模式，要注意以下几点：

1. 在堆上分配非模态对话框的内存资源，通俗一点的描述就是不要用这种方式：CXXDialog t;而是用这种方式：CXXDialog *t = new CXXDialog();来分配内存。

2. 同步构造和析构过程，就是说有new一定配上个create，delete一定要勾搭一个destroy。

3. 被delete的内存指针一定要置空，也就是下面两句要接踵而至：delete xx;和xx == null;。其实这也是普通的内存管理需要遵循的一个良好习惯。

了解了这些，非模态对话框也会只有温柔没有狰狞。

首先，要对头文件进行处理，保证不会出现重定义的错误。这个应该每个人都会，通常有两种做法：

1. 在.cpp文件中添加保护，比如在.cpp文件中添加：

#ifndef _XX_H_
#define _XX_H_
#include "xx.h"
#endif

2. 在.h中添加保护，比如在xx.h文件中添加：

#ifndef _XX_H_
#define _XX_H_
// 头文件声明内容
#endif

_XX_H_是我比较习惯的命名方式，其他的命名方式，比如__XX__H__，XX_H等等，只要足够Unique就好。建议使用第二种方式进行重定义的保护，一劳永逸而且具有通用性，任何人拿来就能用，不需要考虑保护问题。当然，如果在VS（03以上吧？）下，最好的解决方案是用#pragma once，更为简单有效。

其次，最好将所有头文件需要用到的自定义类（或函数）都在定义前声明一下，比如在xx.h的类xx中需要用到yy.h中的yy类，那么最好做以下的处理：

class yy;

class xx
{
 // 实现内容
};

这样就可以保证头文件引用的次序不会对结果造成影响。

通常，保证以上两点，通常涉及到类互指的问题都可以解决。当然如果天生就有设计问题，无论如何都是没有办法的，比如：

// xx.h
class xx
{
 yy t;
};

// yy.h
class yy
{
 xx t;
};

不难看出，这是个递归定义，编译器无法确定类xx和yy的大小，就无法通过编译。一种解决策略是采用指针，比如：

// xx.h
class xx
{
 yy* t;
};

// yy.h
class yy
{
 xx* t;
};

当然，具体情况具体分析，提取一个更高层的类等手段都可以考虑。

还有一个问题，我一直也心存疑问，就是头文件组织问题。在VS中建立一个MFC工程，都会产生一对stdafx文件，按照这种思想我们把工程下通用的头文件都放入stdafx.h中，在.cpp文件的最开始统一#include "stdafx.h"，这样就可以在.h文件中引用很少的头文件。

这种策略在单工程时很好用，相当于做了头文件组织级别的重用，但它违反了我一直恪守的一个原则即谁的头文件谁负责，指.h和.cpp各自负责各自所需的头文件。于是在跨工程的时候会出现一些问题。比如在B工程B的某个.h中引用了工程B中的一个头文件，由于编译次序问题，这个头文件可能无法被编译。不知道大家都如何处理头文件组织问题的，望指教。

其实知道了有这么个东西，剩下的问题都不能称做问题了，其使用和CToolBar类似，可以通过http://msdn2.microsoft.com/zh-cn/library/wc9sxcw1(VS.80).aspx下载MSDN示例，当然也可以在本机的MSDN搜索CDialogBar获得。

动态创建菜单需要先了解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，否则很可能菜单不可以点击（我就被郁闷过很久：（）。

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中有很多...

在配置一个基于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工程的时候，提前做好两件事。一件是通读一遍系统默认生成的代码，做到心中有数，每一条莫名其妙的东西都要了解一下它的用途；另一件是在刚开始和改变了工程属性之后查看一下你的编译和链接命令，搞清楚它做了什么事，有时候命令行虽然难记一点，但确实是一目了然，你可以不必每天用命令行编译程序，但一定要对这些命令心如明镜，了如指掌才好。