love in C++, live on MFC

在關(guān)于printf的大部分參數(shù)祥解 (http://blog.vckbase.com/flyingleaf/archive/2004/12/27/2335.aspx)文章后面的評(píng)論中,看到了到目前為止我看到過的最全的printf參數(shù)意義表.
以前一直在msdn里查,都沒有這么詳細(xì)的.
其實(shí)它是gnu c的一個(gè)文檔,Formatted Output (http://www.gnu.org/software/libc/manual/html_node/Formatted-Output.html#Formatted-Output)

情況是這樣的，一個(gè)程序從ansi移植到了unicode，見把代碼移植成UNICODE （http://www.shnenglu.com/flyingxu/archive/2006/05/18/7356.html），之后產(chǎn)生了一個(gè)問題，之前文件保存的那些文件，unicode版本還能打開嗎？這真是個(gè)大問題，如果不能，就基本表示這個(gè)程序已經(jīng)半死不活了。

文件的保存基本用的序列化，比如
如果m_strName = _T("name");那么ansi情況下，保存的文件為:
04 6E 61 6D 65，一共5個(gè)字節(jié)。
然后用unicode版本保存時(shí)，是
FF FE FF 04 6E 00 61 00 6D 00 65 00,一共12個(gè)字節(jié)。

然后我發(fā)現(xiàn)，ansi版本的可以打開unicode版本的文件，unicode版本的也可以打開ansi版本的文件。

為什么？我覺得關(guān)鍵在于CString，我覺得CString功能比較強(qiáng)大。
CString的序列化函數(shù)

//?CString?serialization?code
//?String?format:
//??????UNICODE?strings?are?always?prefixed?by?0xff,?0xfffe
//??????if?<?0xff?chars:?len:BYTE,?TCHAR?chars
//??????if?>=?0xff?characters:?0xff,?len:WORD,?TCHAR?chars
//??????if?>=?0xfffe?characters:?0xff,?0xffff,?len:DWORD,?TCHARs

CArchive&?AFXAPI?operator<<(CArchive&?ar,?const?CString&?string)
{
????//?special?signature?to?recognize?unicode?strings
#ifdef?_UNICODE
????ar?<<?(BYTE)0xff;
????ar?<<?(WORD)0xfffe;
#endif

????if?(string.GetData()->nDataLength?<?255)
????{
????????ar?<<?(BYTE)string.GetData()->nDataLength;
????}
????else?if?(string.GetData()->nDataLength?<?0xfffe)
????{
????????ar?<<?(BYTE)0xff;
????????ar?<<?(WORD)string.GetData()->nDataLength;
????}
????else
????{
????????ar?<<?(BYTE)0xff;
????????ar?<<?(WORD)0xffff;
????????ar?<<?(DWORD)string.GetData()->nDataLength;
????}
????ar.Write(string.m_pchData,?string.GetData()->nDataLength*sizeof(TCHAR));
????return?ar;
}

它對(duì)unicode做了特別的支持
特別是當(dāng)它在讀序列化過程的時(shí)候
也就是說，不管你保存的文件是不是unicode，都可以讀進(jìn)來，轉(zhuǎn)換稱當(dāng)前unicode或者ansi版本

不過回到文章的標(biāo)題，這里只講了用CString序列化的保存。如果是其他保存方式，可以學(xué)著CString的做法，寫函數(shù)把文件總是能讀進(jìn)來。

MFC自己定義了一些字符串，在用戶自己定義字符串的時(shí)候，id不能重復(fù)。這個(gè)時(shí)候，用戶自定義id的范圍是什么？
今天同事問我。

我還真不知道，但是我看了下AFXRES.RC 和AFXRES.H ，發(fā)現(xiàn)MFC用的ID都是0xE000以上的。所以，用戶自己用的，從0－>0xCFFFF？不過不確定。呵呵，查了一下，正確的可以見TN020:http://msdn2.microsoft.com/en-us/library/t2zechd4.aspx


但是在我的印象中，重復(fù)的字符串id在編譯的時(shí)候，就會(huì)出錯(cuò)的。但是http://support.microsoft.com/kb/q194299/上說，實(shí)際上，選static link mfc才會(huì)在編譯的時(shí)候發(fā)現(xiàn)，否則發(fā)現(xiàn)不了。

另外：http://www.vckbase.com/article/misc/0022.htm中說，在一個(gè)rc文件中，可以同時(shí)有幾種語言的資源，呵呵，我發(fā)現(xiàn)我傻了，每次把不同語言的資源發(fā)在不同的rc中，搞得現(xiàn)在好幾個(gè)rc文件，每次拷貝切換煩的要死

有兩個(gè)工程,w.exe和c.dll;開始的時(shí)候,如果exe是release版本用debug版本的dll時(shí),函數(shù)調(diào)用會(huì)出錯(cuò),我覺得也可以理解,沒有多想.
今天遇到一個(gè)問題更奇怪,都是debug版本,但是exe和dll的optimizations設(shè)置不一樣,都會(huì)出莫名的錯(cuò)誤,出錯(cuò)行更搞笑,是
m_ComboBox.AddString(_T("") )
怎么查也查不出問題,把優(yōu)化選項(xiàng)改成一致問題就沒有了,搞不懂

http://www.developingprogrammers.com/

"About DevelopingProgrammers??

編譯好了,運(yùn)行一個(gè)程序,試圖打開一個(gè)對(duì)話框時(shí),對(duì)話框出不來,反倒是出來一個(gè)錯(cuò)誤提示:
"An unsupported operation was attempted"
搜了一下:
http://www.experts-exchange.com/Programming/Programming_Languages/MFC/Q_21023191.html里面有回答,的確是那樣的,是resource id的問題.

錯(cuò)誤原因:
開始,給一個(gè)radio映射了一個(gè)變量:
后來發(fā)現(xiàn)IDC_RADIO1這個(gè)id不好,改為?DDX_Radio(pDX, IDC_RADIO_BIT, m_nFindType);
編譯當(dāng)然不會(huì)出錯(cuò),運(yùn)行時(shí),就出現(xiàn)異常了.如果在上面的代碼上設(shè)個(gè)斷點(diǎn),然后跟蹤進(jìn)去,看的非常清楚.

在重載CSplitterWnd中，重載了OnPaint()，
默認(rèn)的代碼如下：
wizard添加的代碼居然有這樣一行：//?Do?not?call?CSplitterWnd::OnPaint()?for?painting?messages，后面有個(gè)猜測(cè)。
然后我繼續(xù)寫我的函數(shù)：

void?CHideSplitterWnd::OnPaint()?
{
????CPaintDC?dc(this);?//?device?context?for?painting
????
????//?調(diào)用基類，先
????CSplitterWnd::OnPaint();
????
?????//利用dc畫一些別的東西，但是實(shí)際上，它們永遠(yuǎn)不會(huì)被畫出來
???//除非不調(diào)用基類的OnPaint()
????m_rectButton.DrawButton(&dc);
}

結(jié)果我添加的東西怎么也不會(huì)被畫出來，為什么會(huì)這樣？

看了CSplitterWnd::OnPaint()的代碼，發(fā)現(xiàn)它也用了一個(gè)CPaintDC，而且也是個(gè)臨時(shí)變量

void?CSplitterWnd::OnPaint()
{
????ASSERT_VALID(this);
????CPaintDC?dc(this);

而關(guān)鍵的地方就在CPaintDC的ctor和dtor中了：在CPaintDC的ctor中調(diào)用了

::BeginPaint(m_hWnd?=?pWnd->m_hWnd,?&m_ps)

而在CPaintDC的dtor中調(diào)用了

::EndPaint(m_hWnd,?&m_ps);

而：BeginPaint是開始根據(jù)當(dāng)前的cliprect來畫，EndPaint則會(huì)清空當(dāng)前的cliprect。

所以，前面調(diào)用基類的OnPaint的過程結(jié)束后，當(dāng)前的cliprect為NULL，所以，第二個(gè)CPaintDC在視圖畫點(diǎn)什么時(shí)，cliprect已經(jīng)為NULL，當(dāng)然什么也畫不上去了 ：）

如果我一定想再用CPaintDC畫點(diǎn)什么，怎么辦？再次調(diào)用InvalidateRect，使得cliprect不為空。
所以，我猜測(cè)，所有用了CPaintDC的地方，MFC都會(huì)加一句：不要調(diào)用基類的函數(shù)啦～

呵呵，不知道我講清楚沒有

動(dòng)機(jī) : 在沒有裝中文字體的機(jī)器上顯示中文

如果不是unicode,某些中文字符會(huì)在不同的codepage上出現(xiàn)亂碼;如果當(dāng)前codepage為韓文時(shí),某些中文字會(huì)變成韓文的樣子,奇怪.

Step1: define _UNICODE, undefine _MBCS

宏定義UNICODE, _UNICODE定義兩個(gè)也可以,定義一個(gè)也可以,windows的頭文件會(huì)保證兩個(gè)都會(huì)被定義.

?

Step2: 更改變量類型

比如 char -> TCHAR

但是 ,并不是說所有的char類型都不能用了.如果需要用,并且函數(shù)的參數(shù)/返回值什么的都不沖突,char類型還是可以用的.

Step3: 更改常量字符串形式

" abc " -> _T(" abc ")

因?yàn)殚_始寫程序時(shí)沒有注意 ,造成這樣的常量字符串形式非常多,一個(gè)個(gè)改起來很煩,我寫了個(gè)小插件,可以講 ” abc ” 選中后點(diǎn)一下 button就能變成_T( “ abc ” ),有點(diǎn)用,代碼也非常的短.

Step4: 替換某些函數(shù)

比如atoi -> _ttoi

在這里遇到一個(gè)問題,就是atof的替換.

按照msdn, atof應(yīng)該被_ttof替換

TCHAR.H routine	_UNICODE & _MBCS not defined	_MBCS defined	_UNICODE defined
_tstof	atof	atof	_wtof

但是奇怪的是,VC6里面不認(rèn)識(shí)_tstof這個(gè)函數(shù),VC.net 2003就可以.

有兩個(gè)解決的辦法:

1)????? 因?yàn)?/span>atof只是替換為浮點(diǎn)數(shù),所以這里用WideCharToMultiByte轉(zhuǎn)化一下之后再調(diào)用atof也是可行的

2)????? 呵呵,用strtod的替換函數(shù)_tcstod,哈哈,當(dāng)然參數(shù)要變一下,我覺得這個(gè)方法不錯(cuò),不要被msdn限制死了

Step5: 檢查一下調(diào)用其他 dll 的接口函數(shù)

因?yàn)轫?xiàng)目還用了另外一個(gè)dll,其中有些接口需要char*參數(shù),這個(gè)時(shí)候就必須用WideCharToMultiByte轉(zhuǎn)換一下了.

VC里面的設(shè)置:
1) 等把所有的編譯error改完了之后一編譯,除了個(gè)link錯(cuò)誤,不過msdn有解釋:
If you are using Unicode and MFC, you will get an unresolved external on _WinMain@16 if you don’t create an entrypoint to wWinMainCRTStartup. Use the /ENTRY option or type this value in the Project Settings dialog box. (To find this option in the development environment, click Settings on the Project menu, then click the Link tab, and click Output in the Category box.)

2)終于編譯成功了,調(diào)試的時(shí)候卻發(fā)現(xiàn)CString的值不能在QuickWatch窗口中顯示了
tools->option->
in the debug tab u can find a check box Labeled "Display unicode strings"
Check it.

問題 : 直接用 ANSI 的 dll 中的 CString

在使用dll的時(shí)候,需要直接使用dll中的一個(gè)變量,是CString類型,因?yàn)檫@個(gè)dll還沒有改為unicode,所以在直接使用其變量時(shí)有點(diǎn)問題,使得值不對(duì).(是不是這個(gè)原因還沒有完全驗(yàn)證,應(yīng)該是的)

到這里 , 宣布移植失敗 !

/*補(bǔ)充：
結(jié)果是失敗，但是基本移植代碼的所有步驟都有了。而且，也指出了如果需要調(diào)用的dll不是unicode，每次調(diào)用/傳遞參數(shù)時(shí)，都要轉(zhuǎn)換，很煩。
后來我把dll的代碼也移植了下，現(xiàn)在運(yùn)行的很好，韓文、中文都可以顯示，不管你當(dāng)前語言是什么。
*/

還有一篇講移植步驟的,更全面,適合更復(fù)雜的情況:
Cheat Sheet:Unicode-enabling Microsoft C/C++ Source Code (http://www.i18nguy.com/unicode/c-unicode.html)

?

在寫函數(shù)的時(shí)候,很多函數(shù)只是設(shè)置某個(gè)變量然后做一些其他的相應(yīng)的處理,比如:
這樣的函數(shù),返回類型為void順理成章.

但是,隨著程序繼續(xù)往下寫,需要處理的情況越來越復(fù)雜,這個(gè)時(shí)候,發(fā)現(xiàn)SetName這個(gè)函數(shù),返回void已經(jīng)不夠用了,因?yàn)榭梢孕枰繱etName這個(gè)函數(shù)調(diào)用有沒有成功,因?yàn)榭赡軅魅氲膕trName不一定是合法的,如果調(diào)用SetName函數(shù)沒有成功,可能要繼續(xù)調(diào)用別的函數(shù),這個(gè)時(shí)候,可能就要講返回類型改為BOOL.

而后來繼續(xù)想,一個(gè)函數(shù)的返回值,應(yīng)該更加充分的利用,調(diào)用一個(gè)函數(shù)時(shí),就該充分的利用它的返回值;而在寫一個(gè)函數(shù)時(shí),也應(yīng)該注意到這一點(diǎn).如果實(shí)在沒有什么值好返回,就返回TRUE

所以,對(duì)于函數(shù),如果在設(shè)計(jì)時(shí)準(zhǔn)備把返回類型定為void,其實(shí)可以改為BOOL
1)最初可能沒有用,但情況會(huì)越來越復(fù)雜
2)充分利用函數(shù)的返回值

資源中的屬性,是指寫MFC程序時(shí)VC IDE的resource編輯器中可以設(shè)定的各種屬性,比如WS_EX_TRANSPARENT或者LVS_REPORT.
而這些屬性,都是可以用代碼在程序初始化后加上去的,比如在OnInitDialog() 或者OnCreate()函數(shù)中.

從方便性來說,肯定是在資源中設(shè)置這些屬性更加方便,但是..
我遇到一種情況,在我的程序中,有兩個(gè)rc文件,分別是中文和英文,這個(gè)時(shí)候,就發(fā)生了在英文資源中設(shè)置了屬性修正了一個(gè)bug但是在中文版的資源中忘記設(shè)置,bug依然存在.而如果是在在代碼中加上類似的代碼:
資源文件不用改變,而且修正了所有的問題.

所以,我覺得,應(yīng)該盡量用幾行代碼來替代在資源中的設(shè)定屬性