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

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

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

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

為什么？我覺得關(guān)鍵在于CString，我覺得CString功能比較強大。
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;
}

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

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

MFC自己定義了一些字符串，在用戶自己定義字符串的時候，id不能重復(fù)。這個時候，用戶自定義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在編譯的時候，就會出錯的。但是http://support.microsoft.com/kb/q194299/上說，實際上，選static link mfc才會在編譯的時候發(fā)現(xiàn)，否則發(fā)現(xiàn)不了。

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

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

http://www.developingprogrammers.com/

"About DevelopingProgrammers??

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

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

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

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

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

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

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則會清空當(dāng)前的cliprect。

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

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

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

動機 : 在沒有裝中文字體的機器上顯示中文

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

Step1: define _UNICODE, undefine _MBCS

宏定義UNICODE, _UNICODE定義兩個也可以,定義一個也可以,windows的頭文件會保證兩個都會被定義.

?

Step2: 更改變量類型

比如 char -> TCHAR

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

Step3: 更改常量字符串形式

" abc " -> _T(" abc ")

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

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

比如atoi -> _ttoi

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

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

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

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

有兩個解決的辦法:

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

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

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

因為項目還用了另外一個dll,其中有些接口需要char*參數(shù),這個時候就必須用WideCharToMultiByte轉(zhuǎn)換一下了.

VC里面的設(shè)置:
1) 等把所有的編譯error改完了之后一編譯,除了個link錯誤,不過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)試的時候卻發(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的時候,需要直接使用dll中的一個變量,是CString類型,因為這個dll還沒有改為unicode,所以在直接使用其變量時有點問題,使得值不對.(是不是這個原因還沒有完全驗證,應(yīng)該是的)

到這里 , 宣布移植失敗 !

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

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

?

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

但是,隨著程序繼續(xù)往下寫,需要處理的情況越來越復(fù)雜,這個時候,發(fā)現(xiàn)SetName這個函數(shù),返回void已經(jīng)不夠用了,因為可以需要知道SetName這個函數(shù)調(diào)用有沒有成功,因為可能傳入的strName不一定是合法的,如果調(diào)用SetName函數(shù)沒有成功,可能要繼續(xù)調(diào)用別的函數(shù),這個時候,可能就要講返回類型改為BOOL.

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

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

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

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

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