在做一個MFC軟件的時候有一個這樣的需求，就是要有類似與AutoCad的命令輸入框，如下圖所示：

 

本著不重寫已有功能的原則，在MFC中發(fā)掘了一圈，沒發(fā)現(xiàn)有可用的現(xiàn)成控件，上網(wǎng)搜了一下，發(fā)現(xiàn)有人做過，但竟然還收費出售，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) // 當輸入空格或回車是發(fā)送消息
    this->SendCommand();
  }
 }

 return CMDIFrameWnd::PreTranslateMessage(pMsg);
}

其中SendCommand的內容可自定義，處理完成后不要忘記執(zhí)行1的操作，同步一下字符串就OK。實現(xiàn)效果如下：

當然，這是一個最簡單的實現(xiàn)，還有很多問題沒有處理，比如自定義菜單，屏蔽系統(tǒng)菜單等；還有很多工作可以做，比如封裝成一個自定義控件，做更好的顯示效果等等。但基本的思路還是一樣的，恩，如果誰有更好的實現(xiàn)方案，也歡迎留言，謝謝先：）

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

在VC++中有著一大把字符串類型。從傳統(tǒng)的char*到std::string到CString，簡直是多如牛毛。期間的轉換相信也是繞暈了許多的人，我曾就是其中的一個。還好，MS還沒有喪失功德心，msdn的一篇文章詳細的解析了各種字符串的轉換問題，鏈接如下：http://msdn2.microsoft.com/zh-cn/library/ms235631(VS.80).aspx。

參照這篇文章，可以搞定同碼制的字符串轉換，如果有unicode到非unicode的轉換問題，還需要另尋高招。我通常就是歸一化，把工程屬性-->General中的Character set統(tǒng)一選為no set或unicode。每每此時，我都會出奇的想念C#。。。

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

非模態(tài)對話框比模態(tài)對話框更難使用這是眾所周知的，這是由于模態(tài)對話框運行時，阻塞了其父窗口的消息循環(huán)，使其能自成一派，所以能夠怡然自得。但非模態(tài)對話框只相當于一個由父窗體創(chuàng)建的一個同級的Hwnd，就像一個長大了的孩子，可以和父母并駕齊驅了，需要父母管又不能管的太厲害，其資源管理、通信都會比模態(tài)的更為復雜。  

很多時候，能用模態(tài)對話框的情況下，都會用模態(tài)的。雖然Copper 老先生指著鼻子苦口婆心的教導了我們，但有時候人懶臉皮也就厚了，無所謂了。但，世界總是很殘酷，很多時候（比如需要在處理對話框事件的時候也能響應窗體事件），我們不得不去面對非模態(tài)對話框。其實了解了資源管理的模式，就像扒開了非模態(tài)對話框半遮的琵琶，可以很坦然的面對了。

模態(tài)對話框的資源分成兩種，一種是內存資源，一種是非內存資源。單看非內存資源的管理，其實和內存資源的管理原理是一樣的。在C++中，內存資源的管理講究new和delete配對，同理，非內存資源的管理需要create和destroy出雙入對。在這篇文章中，基本體現(xiàn)了非模態(tài)對話框資源管理的一個基本模式，即內存資源管理和非內存資源同步。

這樣通過判斷內存資源是否占用（即指針是否為空）就可以判斷非內存資源的使用狀況。當指針為空，說明對話框還未創(chuàng)建（非內存資源未申請）；當指針不為空，對話框已創(chuàng)建，正處于可見或不可見狀態(tài)。這樣將兩部分資源管理合并在一起了，只需要判斷指針是否為空就可以了解對話框資源的狀態(tài)。一些內存管理的手段，比如類管理思想（將delete和destroy放到類的析構函數(shù)中），可以實現(xiàn)資源的自動管理。

為了實現(xiàn)這種管理模式，要注意以下幾點：

1. 在堆上分配非模態(tài)對話框的內存資源，通俗一點的描述就是不要用這種方式：CXXDialog t;而是用這種方式：CXXDialog *t = new CXXDialog();來分配內存。

2. 同步構造和析構過程，就是說有new一定配上個create，delete一定要勾搭一個destroy。

3. 被delete的內存指針一定要置空，也就是下面兩句要接踵而至：delete xx;和xx == null;。其實這也是普通的內存管理需要遵循的一個良好習慣。

了解了這些，非模態(tài)對話框也會只有溫柔沒有猙獰。

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

在C++中經(jīng)常會涉及到處于不同頭文件的類互相引用的情況，有時候頭文件引用（include）會搞得很亂，導致報一堆的錯。其實遵循一定規(guī)則，可以避免大部分的混亂。

首先，要對頭文件進行處理，保證不會出現(xiàn)重定義的錯誤。這個應該每個人都會，通常有兩種做法：

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，更為簡單有效。

其次，最好將所有頭文件需要用到的自定義類（或函數(shù)）都在定義前聲明一下，比如在xx.h的類xx中需要用到y(tǒng)y.h中的yy類，那么最好做以下的處理：

class yy;

class xx
{
 // 實現(xiàn)內容
};

這樣就可以保證頭文件引用的次序不會對結果造成影響。

通常，保證以上兩點，通常涉及到類互指的問題都可以解決。當然如果天生就有設計問題，無論如何都是沒有辦法的，比如：

// 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工程，都會產(chǎn)生一對stdafx文件，按照這種思想我們把工程下通用的頭文件都放入stdafx.h中，在.cpp文件的最開始統(tǒng)一#include "stdafx.h"，這樣就可以在.h文件中引用很少的頭文件。

這種策略在單工程時很好用，相當于做了頭文件組織級別的重用，但它違反了我一直恪守的一個原則即誰的頭文件誰負責，指.h和.cpp各自負責各自所需的頭文件。于是在跨工程的時候會出現(xiàn)一些問題。比如在B工程B的某個.h中引用了工程B中的一個頭文件，由于編譯次序問題，這個頭文件可能無法被編譯。不知道大家都如何處理頭文件組織問題的，望指教。

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

有時候我們經(jīng)常把對話框和視圖結合起來，做成AutoCAD命令輸入框、PhotoShop浮動框之類的效果。但很奇怪的是我看過的MFC的書上都沒有特別說明過這樣的工作該如何去做，我剛接觸MFC的時候都是通過控制非模態(tài)對話框來模擬的，后來才知道這些工作是通過CControlBar的派生類來完成的。比如CDialogBar就是加載一個已有的對話框資源，嵌入Frame中，和視圖配合使用。

其實知道了有這么個東西，剩下的問題都不能稱做問題了，其使用和CToolBar類似，可以通過http://msdn2.microsoft.com/zh-cn/library/wc9sxcw1(VS.80).aspx下載MSDN示例，當然也可以在本機的MSDN搜索CDialogBar獲得。

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