在做一個(gè)MFC軟件的時(shí)候有一個(gè)這樣的需求,就是要有類似與AutoCad的命令輸入框,如下圖所示:

本著不重寫已有功能的原則,在MFC中發(fā)掘了一圈,沒發(fā)現(xiàn)有可用的現(xiàn)成控件,上網(wǎng)搜了一下,發(fā)現(xiàn)有人做過,但竟然還收費(fèi)出售,so faint,只能自己動(dòng)手做一個(gè)。
其實(shí)思路還是蠻簡(jiǎn)單的,就是放個(gè)Edit控件處理它的鍵盤輸入事件,防止刪除之前的記錄和提示信息,還要處理結(jié)束命令,比如回車、空格之類的。主要有以下幾個(gè)步驟:
1. 將輸入框內(nèi)的字符串分段,比如分成三段log, tip和command,前兩段都不能被修改,command的內(nèi)容為可修改的。在結(jié)束了command輸入后,要同步各字符串,示例代碼如下:
void CMainFrame::InitCommand(CString tip)
{
// 記錄老字符串,類似于UpdateData(true)
this->GetText();
// 設(shè)置新的log
if(this->m_log != "")
this->m_log += "\r\n";
this->m_log += tip;
// 更新字符串,類似與UpdataData(false)
this->SetText();
// 將光標(biāo)置于字符串的尾部(否則光標(biāo)會(huì)在一開始的位置)
((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))
{
// 如果選擇的是非正在輸入的文字,拋棄這個(gè)事件
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) // 當(dāng)輸入空格或回車是發(fā)送消息
this->SendCommand();
}
}
return CMDIFrameWnd::PreTranslateMessage(pMsg);
}
其中SendCommand的內(nèi)容可自定義,處理完成后不要忘記執(zhí)行1的操作,同步一下字符串就OK。實(shí)現(xiàn)效果如下:

當(dāng)然,這是一個(gè)最簡(jiǎn)單的實(shí)現(xiàn),還有很多問題沒有處理,比如自定義菜單,屏蔽系統(tǒng)菜單等;還有很多工作可以做,比如封裝成一個(gè)自定義控件,做更好的顯示效果等等。但基本的思路還是一樣的,恩,如果誰有更好的實(shí)現(xiàn)方案,也歡迎留言,謝謝先:)
文章來源:
http://www.cnblogs.com/duguguiyu/archive/2007/07/21/826901.html
posted @
2007-07-21 21:43 duguguiyu 閱讀(696) |
評(píng)論 (0) |
編輯 收藏
在VC++中有著一大把字符串類型。從傳統(tǒng)的char*到std::string到CString,簡(jiǎn)直是多如牛毛。期間的轉(zhuǎn)換相信也是繞暈了許多的人,我曾就是其中的一個(gè)。還好,MS還沒有喪失功德心,msdn的一篇文章詳細(xì)的解析了各種字符串的轉(zhuǎn)換問題,鏈接如下:http://msdn2.microsoft.com/zh-cn/library/ms235631(VS.80).aspx。
參照這篇文章,可以搞定同碼制的字符串轉(zhuǎn)換,如果有unicode到非unicode的轉(zhuǎn)換問題,還需要另尋高招。我通常就是歸一化,把工程屬性-->General中的Character set統(tǒng)一選為no set或unicode。每每此時(shí),我都會(huì)出奇的想念C#。。。
文章來源:
http://www.cnblogs.com/duguguiyu/archive/2007/07/21/826869.html
posted @
2007-07-21 21:04 duguguiyu 閱讀(563) |
評(píng)論 (0) |
編輯 收藏
非模態(tài)對(duì)話框比模態(tài)對(duì)話框更難使用這是眾所周知的,這是由于模態(tài)對(duì)話框運(yùn)行時(shí),阻塞了其父窗口的消息循環(huán),使其能自成一派,所以能夠怡然自得。但非模態(tài)對(duì)話框只相當(dāng)于一個(gè)由父窗體創(chuàng)建的一個(gè)同級(jí)的Hwnd,就像一個(gè)長(zhǎng)大了的孩子,可以和父母并駕齊驅(qū)了,需要父母管又不能管的太厲害,其資源管理、通信都會(huì)比模態(tài)的更為復(fù)雜。
很多時(shí)候,能用模態(tài)對(duì)話框的情況下,都會(huì)用模態(tài)的。雖然Copper 老先生指著鼻子苦口婆心的教導(dǎo)了我們,但有時(shí)候人懶臉皮也就厚了,無所謂了。但,世界總是很殘酷,很多時(shí)候(比如需要在處理對(duì)話框事件的時(shí)候也能響應(yīng)窗體事件),我們不得不去面對(duì)非模態(tài)對(duì)話框。其實(shí)了解了資源管理的模式,就像扒開了非模態(tài)對(duì)話框半遮的琵琶,可以很坦然的面對(duì)了。
模態(tài)對(duì)話框的資源分成兩種,一種是內(nèi)存資源,一種是非內(nèi)存資源。單看非內(nèi)存資源的管理,其實(shí)和內(nèi)存資源的管理原理是一樣的。在C++中,內(nèi)存資源的管理講究new和delete配對(duì),同理,非內(nèi)存資源的管理需要create和destroy出雙入對(duì)。在這篇文章中,基本體現(xiàn)了非模態(tài)對(duì)話框資源管理的一個(gè)基本模式,即內(nèi)存資源管理和非內(nèi)存資源同步。
這樣通過判斷內(nèi)存資源是否占用(即指針是否為空)就可以判斷非內(nèi)存資源的使用狀況。當(dāng)指針為空,說明對(duì)話框還未創(chuàng)建(非內(nèi)存資源未申請(qǐng));當(dāng)指針不為空,對(duì)話框已創(chuàng)建,正處于可見或不可見狀態(tài)。這樣將兩部分資源管理合并在一起了,只需要判斷指針是否為空就可以了解對(duì)話框資源的狀態(tài)。一些內(nèi)存管理的手段,比如類管理思想(將delete和destroy放到類的析構(gòu)函數(shù)中),可以實(shí)現(xiàn)資源的自動(dòng)管理。
為了實(shí)現(xiàn)這種管理模式,要注意以下幾點(diǎn):
1. 在堆上分配非模態(tài)對(duì)話框的內(nèi)存資源,通俗一點(diǎn)的描述就是不要用這種方式:CXXDialog t;而是用這種方式:CXXDialog *t = new CXXDialog();來分配內(nèi)存。
2. 同步構(gòu)造和析構(gòu)過程,就是說有new一定配上個(gè)create,delete一定要勾搭一個(gè)destroy。
3. 被delete的內(nèi)存指針一定要置空,也就是下面兩句要接踵而至:delete xx;和xx == null;。其實(shí)這也是普通的內(nèi)存管理需要遵循的一個(gè)良好習(xí)慣。
了解了這些,非模態(tài)對(duì)話框也會(huì)只有溫柔沒有猙獰。
文章來源:
http://www.cnblogs.com/duguguiyu/archive/2007/07/21/826858.html
posted @
2007-07-21 20:56 duguguiyu 閱讀(1453) |
評(píng)論 (1) |
編輯 收藏
在C++中經(jīng)常會(huì)涉及到處于不同頭文件的類互相引用的情況,有時(shí)候頭文件引用(include)會(huì)搞得很亂,導(dǎo)致報(bào)一堆的錯(cuò)。其實(shí)遵循一定規(guī)則,可以避免大部分的混亂。
首先,要對(duì)頭文件進(jìn)行處理,保證不會(huì)出現(xiàn)重定義的錯(cuò)誤。這個(gè)應(yīng)該每個(gè)人都會(huì),通常有兩種做法:
1. 在.cpp文件中添加保護(hù),比如在.cpp文件中添加:
#ifndef _XX_H_
#define _XX_H_
#include "xx.h"
#endif
2. 在.h中添加保護(hù),比如在xx.h文件中添加:
#ifndef _XX_H_
#define _XX_H_
// 頭文件聲明內(nèi)容
#endif
_XX_H_是我比較習(xí)慣的命名方式,其他的命名方式,比如__XX__H__,XX_H等等,只要足夠Unique就好。建議使用第二種方式進(jìn)行重定義的保護(hù),一勞永逸而且具有通用性,任何人拿來就能用,不需要考慮保護(hù)問題。當(dāng)然,如果在VS(03以上吧?)下,最好的解決方案是用#pragma once,更為簡(jiǎn)單有效。
其次,最好將所有頭文件需要用到的自定義類(或函數(shù))都在定義前聲明一下,比如在xx.h的類xx中需要用到y(tǒng)y.h中的yy類,那么最好做以下的處理:
class yy;
class xx
{
// 實(shí)現(xiàn)內(nèi)容
};
這樣就可以保證頭文件引用的次序不會(huì)對(duì)結(jié)果造成影響。
通常,保證以上兩點(diǎn),通常涉及到類互指的問題都可以解決。當(dāng)然如果天生就有設(shè)計(jì)問題,無論如何都是沒有辦法的,比如:
// xx.h
class xx
{
yy t;
};
// yy.h
class yy
{
xx t;
};
不難看出,這是個(gè)遞歸定義,編譯器無法確定類xx和yy的大小,就無法通過編譯。一種解決策略是采用指針,比如:
// xx.h
class xx
{
yy* t;
};
// yy.h
class yy
{
xx* t;
};
當(dāng)然,具體情況具體分析,提取一個(gè)更高層的類等手段都可以考慮。
還有一個(gè)問題,我一直也心存疑問,就是頭文件組織問題。在VS中建立一個(gè)MFC工程,都會(huì)產(chǎn)生一對(duì)stdafx文件,按照這種思想我們把工程下通用的頭文件都放入stdafx.h中,在.cpp文件的最開始統(tǒng)一#include "stdafx.h",這樣就可以在.h文件中引用很少的頭文件。
這種策略在單工程時(shí)很好用,相當(dāng)于做了頭文件組織級(jí)別的重用,但它違反了我一直恪守的一個(gè)原則即誰的頭文件誰負(fù)責(zé),指.h和.cpp各自負(fù)責(zé)各自所需的頭文件。于是在跨工程的時(shí)候會(huì)出現(xiàn)一些問題。比如在B工程B的某個(gè).h中引用了工程B中的一個(gè)頭文件,由于編譯次序問題,這個(gè)頭文件可能無法被編譯。不知道大家都如何處理頭文件組織問題的,望指教。
文章來源:
http://www.cnblogs.com/duguguiyu/archive/2007/07/21/826821.html
posted @
2007-07-21 19:37 duguguiyu 閱讀(623) |
評(píng)論 (1) |
編輯 收藏
有時(shí)候我們經(jīng)常把對(duì)話框和視圖結(jié)合起來,做成AutoCAD命令輸入框、PhotoShop浮動(dòng)框之類的效果。但很奇怪的是我看過的MFC的書上都沒有特別說明過這樣的工作該如何去做,我剛接觸MFC的時(shí)候都是通過控制非模態(tài)對(duì)話框來模擬的,后來才知道這些工作是通過CControlBar的派生類來完成的。比如CDialogBar就是加載一個(gè)已有的對(duì)話框資源,嵌入Frame中,和視圖配合使用。
其實(shí)知道了有這么個(gè)東西,剩下的問題都不能稱做問題了,其使用和CToolBar類似,可以通過http://msdn2.microsoft.com/zh-cn/library/wc9sxcw1(VS.80).aspx下載MSDN示例,當(dāng)然也可以在本機(jī)的MSDN搜索CDialogBar獲得。
文章來源:
http://www.cnblogs.com/duguguiyu/archive/2007/07/21/826819.html
posted @
2007-07-21 19:35 duguguiyu 閱讀(2524) |
評(píng)論 (0) |
編輯 收藏