簡(jiǎn)介這套源碼包是《MFC Windows應(yīng)用程序設(shè)計(jì)第3版》任哲編著的配套示例面向在Visual Studio 2017環(huán)境下學(xué)習(xí)MFC的初學(xué)者、高校師生及需要快速查閱工程結(jié)構(gòu)的開(kāi)發(fā)者。壓縮包共2000個(gè)文件大小約12.73MB其中cpp與h源文件是學(xué)習(xí)核心配合vcxproj、sln工程文件rc、res資源文件以及ico、bmp圖標(biāo)素材另有tlog、log等編譯記錄整體按教材章節(jié)組織為大量示例便于逐章對(duì)照練習(xí)。目前已有800人學(xué)習(xí)下載源碼覆蓋CWinApp程序入口、CFrameWnd主框架、文檔視圖結(jié)構(gòu)、對(duì)話框與控件、消息映射、動(dòng)態(tài)鏈接庫(kù)、資源管理和異常處理等MFC關(guān)鍵知識(shí)點(diǎn)。每個(gè)示例文件均配有完整工程可在VS2017中直接編譯運(yùn)行通過(guò)斷點(diǎn)調(diào)試觀察窗口創(chuàng)建與消息傳遞過(guò)程也適合改寫(xiě)為課程作業(yè)或小型項(xiàng)目的基礎(chǔ)框架。從簡(jiǎn)單的單文檔程序到多視圖、對(duì)話框、DLL插件和資源自定義這套源碼能幫助開(kāi)發(fā)者由淺入深掌握MFC的封裝邏輯與Windows應(yīng)用設(shè)計(jì)方法。1. 拿到《MFC Windows應(yīng)用程序設(shè)計(jì)(第3版)》任哲老師配套的vs2017源碼包先別急著雙擊解壓不少學(xué)MFC的朋友在網(wǎng)盤(pán)或QQ群里拿到《MFC Windows應(yīng)用程序設(shè)計(jì)(第3版)》任哲老師配套的vs2017源碼包第一反應(yīng)是右鍵解壓、雙擊.sln緊接著就被一整屏紅色錯(cuò)誤勸退。這個(gè)RAR里的東西并不神秘它是教材按章節(jié)排好的MFC工程集合源碼在VS2017環(huán)境下組織價(jià)值是讓你在最短時(shí)間內(nèi)對(duì)照界面看清楚消息響應(yīng)、控件和GDI畫(huà)圖怎么串起來(lái)。不過(guò)別指望解壓后一次成功線下跑過(guò)這套源碼的同學(xué)至少三分之一卡在沒(méi)裝MFC組件要么就是Debug和Release配置混著踩坑。下面的內(nèi)容把解壓、編譯到調(diào)試的鏈路講清楚新手照著走能落地熟手可以直接跳到第5章看避坑清單。2. 把 RAR 源碼包變成可編譯的 VS2017 工程解壓路徑與 SDK 配置是第一步2.1 解壓路徑的玄學(xué)中文目錄、空格與安全軟件隔離造成的怪錯(cuò)從網(wǎng)盤(pán)或?qū)W生群里下載的RAR默認(rèn)文件名經(jīng)常是“新建文件夾(2)”或者直接放在“下載”目錄。VS2017的IDE本身能處理中文路徑但要不要跟源碼去賭這個(gè)兼容性我的建議是一律放到純英文、無(wú)空格、無(wú)括號(hào)的目錄。大概率不是UI翻車(chē)而是舊版的Resource Compilerrc.exe和批處理腳本對(duì)非ASCII路徑支持不好。尤其包里如果帶預(yù)編譯好的.rc、.aps文件路徑里有中文或空格時(shí)RC編譯器經(jīng)常報(bào)一個(gè)找不到Include的錯(cuò)實(shí)際原因是路徑分隔符和代碼頁(yè)串了。安全軟件也要留意RAR解壓后如果殺軟把生成的exe或DLL隔離掉你會(huì)看到“應(yīng)用程序無(wú)法正常啟動(dòng)0xc000007b”這一類(lèi)的假象以為是代碼有問(wèn)題。我慣用 7-Zip 的命令行工具解壓避免圖形界面在解壓過(guò)程中偷偷釋放臨時(shí)文件、也方便在腳本里固定參數(shù)# 7z x 執(zhí)行解壓-o 指定輸出目錄-y 跳過(guò)所有確認(rèn) 7z x MFC WINDOWS應(yīng)用程序設(shè)計(jì)(第3版)_任哲_vs2017源碼.rar -oD:\MFCBookSource -y參數(shù)很簡(jiǎn)單但有兩個(gè)習(xí)慣要養(yǎng)成第一-o后面不能帶空格直接連著寫(xiě)輸出路徑第二解壓完先確認(rèn)沒(méi)有多套一層同名目錄。如果出現(xiàn)“D:\MFCBookSource\MFC windows應(yīng)用程序設(shè)計(jì)(第3版)...”這種嵌套把內(nèi)層目錄整體往上挪一層否則后面用VS打開(kāi)項(xiàng)目時(shí)相對(duì)路徑會(huì)找錯(cuò)資源文件。2.2 VS2017 的 MFC 編譯環(huán)境勾選缺少的工作負(fù)載與單獨(dú)組件很多人解壓之后打開(kāi)項(xiàng)目報(bào)錯(cuò)第一行就是“無(wú)法打開(kāi)包括文件:afxwin.h”。這個(gè)錯(cuò)九成不是因?yàn)樵创a有問(wèn)題而是Visual Studio安裝時(shí)根本沒(méi)有裝MFC。VS2017安裝器默認(rèn)的“使用C的桌面開(kāi)發(fā)”工作負(fù)載只帶編譯器、標(biāo)準(zhǔn)庫(kù)和Windows SDKMFC屬于額外組件需要單獨(dú)勾選。正確做法打開(kāi)Visual Studio Installer點(diǎn)本機(jī)VS2017的“修改”。在工作負(fù)載頁(yè)勾選“使用C的桌面開(kāi)發(fā)”然后切到“單個(gè)組件”頁(yè)搜索“MFC”并勾上“適用于v141構(gòu)建工具的MFC和ATL支持x86和x64”。如果你還要編譯老的x86工程確保同時(shí)勾選了“Windows 10 SDK”和“v141工具集”。這步做完大概要多占用2GB左右磁盤(pán)別省。驗(yàn)證是否裝好可以直接在命令行看目錄是否存在# 檢查 MFC 頭文件是否已經(jīng)隨 VS2017 安裝 dir C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\atlmfc\include\afxwin.hVS2017不同更新補(bǔ)丁的MSVC版本號(hào)不一樣如果這條命令報(bào)找不到不要死摳具體版本號(hào)用通配符再列一次dir C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\*\atlmfc\include\afxwin.h能看到afxwin.h存在就說(shuō)明MFC開(kāi)發(fā)組件已經(jīng)就位。如果圖省事裝了VS2019或VS2022來(lái)打開(kāi)這套源碼同樣要在安裝器里找“適用于最新v142/v143構(gòu)建工具的MFC”注意工具集版本不同MFC庫(kù)的命名和頭文件路徑也不一樣編譯結(jié)果不完全等價(jià)。2.3 打開(kāi) .sln 前先看三處配置平臺(tái)工具集、字符集、Windows SDK 版本RAR里的項(xiàng)目如果是VS2017時(shí)代生成工程文件里一般能看到PlatformToolset為v141如果作者有時(shí)用VS2015做過(guò)驗(yàn)證也可能是v140。VS2017打開(kāi)v140項(xiàng)目會(huì)在啟動(dòng)時(shí)彈“平臺(tái)工具集需要更新”的提示我建議直接更新到v141別保留舊的后面STL和MFC頭文件混著用容易出符號(hào)沖突。不想在對(duì)話框里點(diǎn)也可以用文本編輯器直接打開(kāi).vcxproj檢查Configuration屬性組里的三個(gè)關(guān)鍵標(biāo)簽PropertyGroup LabelConfiguration PlatformToolsetv141/PlatformToolset CharacterSetUnicode/CharacterSet UseOfMfcDynamic/UseOfMfc /PropertyGroup三個(gè)值分別決定了編譯器工具集版本、字符集宏UNICODE還是_MBCS、以及MFC庫(kù)的鏈接方式。CharacterSet用Unicode是VS2017默認(rèn)但書(shū)中示例代碼如果寫(xiě)滿(mǎn)了char*和CStringA編譯階段會(huì)看到成片C2664和C4996錯(cuò)誤這時(shí)把CharacterSet臨時(shí)改成“使用多字節(jié)字符集”能讓舊代碼少改很多。UseOfMfc一般用Dynamic調(diào)試省事部署時(shí)再把運(yùn)行庫(kù)拷齊或用靜態(tài)鏈接。還有一個(gè)常被忽略的WindowsTargetPlatformVersion。VS2017默認(rèn)會(huì)選安裝目錄里最新的Windows 10 SDK版本如果項(xiàng)目里寫(xiě)死了某個(gè)舊SDK版本而你機(jī)器裝的比他新就可能出現(xiàn)“Windows SDK版本10.0.x不存在”的警告。處理方式很簡(jiǎn)單在vcxproj里找到WindowsTargetPlatformVersion要么去掉讓它默認(rèn)要么改成你已安裝的版本。第3版源碼包里的項(xiàng)目通常不會(huì)每個(gè)都配置得一樣先統(tǒng)一檢查一遍能省后面逐個(gè)編譯的時(shí)間。3. 按目錄和文件類(lèi)型讀懂這本書(shū)的源碼包別一個(gè)項(xiàng)目一個(gè)項(xiàng)目亂點(diǎn)3.1 項(xiàng)目命名方式從項(xiàng)目名字反推它對(duì)應(yīng)哪個(gè)知識(shí)點(diǎn)這本教材的源碼包并不是一個(gè)大而全的解決方案而是一堆按章節(jié)組織的小工程。幾十個(gè).sln雖然排序未必完全對(duì)應(yīng)目錄頁(yè)碼但項(xiàng)目名一般都有線索。最常見(jiàn)的命名習(xí)慣包括包含Dlg或者Dialog字樣的多半是對(duì)話框和控件示例重點(diǎn)看資源視圖里的.rc和OnInitDialog帶View或者Doc的是文檔視圖框架示例重點(diǎn)看CView派生類(lèi)里的OnDraw帶Draw、GDI、Paint字樣的基本是畫(huà)圖或雙緩沖示例重點(diǎn)在OnPaint和CPaintDC帶Thread的是多線程示例會(huì)用到AfxBeginThread或CMfcThread。你可以用下面這個(gè)表來(lái)快速?zèng)Q定先看哪個(gè)文件命名特征大概率對(duì)應(yīng)主題建議優(yōu)先讀的文件Dlg / Dialog對(duì)話框、控件交互.rc、Dlg類(lèi)的OnInitDialogDoc / View文檔視圖架構(gòu)、菜單命令視圖類(lèi)的OnDraw、OnUpdateDraw / GDI / PaintGDI繪圖、位圖操作OnPaint、CPaintDC相關(guān)代碼Thread / Timer多線程、定時(shí)器AfxBeginThread調(diào)用處不用逐個(gè)項(xiàng)目雙擊打開(kāi)。先用RAR預(yù)覽或解壓后看一眼文件夾列表按這個(gè)規(guī)則把項(xiàng)目分組再挑和你當(dāng)前學(xué)習(xí)話題最接近的工程打開(kāi)效率會(huì)高很多。如果某個(gè)文件夾里只有一個(gè).sln卻帶十幾個(gè).vcxproj那多半是作者把多章示例合并進(jìn)了一個(gè)解決方案你可以在解決方案資源管理器里只勾選想編譯的項(xiàng)目右鍵→“設(shè)為啟動(dòng)項(xiàng)目”省掉一次編譯整個(gè)解決方案浪費(fèi)時(shí)間。3.2 MFC程序從WinMain到CWinApp一條不會(huì)印在書(shū)首頁(yè)的啟動(dòng)鏈路剛看這本書(shū)的人常被一個(gè)問(wèn)題卡住MFC程序的入口到底在哪里答案是被MFC框架藏起來(lái)了。你看到的CMyApp是CWinApp的派生類(lèi)它必須有一個(gè)全局對(duì)象MFC的WinMain會(huì)通過(guò)這個(gè)全局對(duì)象啟動(dòng)你的應(yīng)用程序。下面是最小框架#include afxwin.h class CMyApp : public CWinApp { public: virtual BOOL InitInstance(); // 程序初始化 }; CMyApp theApp; // 全局對(duì)象在WinMain之前完成構(gòu)造 BOOL CMyApp::InitInstance() { CWinApp::InitInstance(); // 基類(lèi)做命令行、文檔模板等初始化 // 這里常見(jiàn)寫(xiě)法是 new 一個(gè)主窗口或調(diào)用對(duì)話框的 DoModal() // 如果省略程序往往沒(méi)有可見(jiàn)窗口就退出了 return TRUE; }注意CMyApp theApp這一行。這個(gè)全局對(duì)象在WinMain被調(diào)用之前就完成了構(gòu)造函數(shù)MFC拿它的指針去驅(qū)動(dòng)消息循環(huán)。所以在源碼包里找入口時(shí)不需要去找WinMain只需要看InitInstance里有沒(méi)有創(chuàng)建主窗口。若打開(kāi)一個(gè)示例發(fā)現(xiàn)程序“秒退”第一步就應(yīng)該在InitInstance第一行下斷點(diǎn)看看程序往哪個(gè)分支走了。文檔視圖架構(gòu)的示例還會(huì)多一個(gè)CWinDoc派生類(lèi)模板通過(guò)AddDocTemplate把Doc、Frame、View三者的類(lèi)和資源ID綁在一起這里出的問(wèn)題多半在資源ID不匹配上。3.3 文件結(jié)構(gòu).sln、.vcxproj、.rc、.aps 的分工與備份原則RAR解壓后一個(gè)MFC工程文件夾里常常躺著好幾類(lèi)文件。.sln是解決方案雙擊它就能跨項(xiàng)目導(dǎo)航.vcxproj是VS2017的項(xiàng)目文件里面記錄了工具集、字符集、依賴(lài)路徑.rc是資源腳本對(duì)話框模板、菜單、字符串表、圖標(biāo)全部用文本形式描述.aps則是RC編譯器生成的中間緩存每次編譯資源都會(huì)自動(dòng)重建。如果你用文本編輯器改了.rc而VS里還殘留著舊.aps有時(shí)會(huì)出現(xiàn)你改了半天界面卻不變的情況。我實(shí)操時(shí)習(xí)慣先把整個(gè)RAR復(fù)制一份放到獨(dú)立backup目錄再在副本上打開(kāi).sln。因?yàn)樵创a包里這些教材示例很可能被多個(gè)同學(xué)改過(guò).rc和resource.h一旦錯(cuò)位恢復(fù)起來(lái)很麻煩。.aps文件完全可以刪掉VS會(huì)在編譯時(shí)重新生成真正不能丟的是.rc和resource.h前者保存界面模板后者保存控件ID符號(hào)。記住這個(gè)邊界后面復(fù)制代碼時(shí)才不會(huì)把一堆沒(méi)用的中間文件帶進(jìn)自己的項(xiàng)目。4. 在 VS2017 里完成第一次編譯三分鐘定位 MFC 源碼包里的編譯錯(cuò)誤4.1 編譯錯(cuò)誤無(wú)法打開(kāi)包括文件:afxwin.h先分清是組件缺失還是路徑問(wèn)題這一章開(kāi)始正式編譯。選好Debug和Win32或者x64之后最經(jīng)典的錯(cuò)誤是“fatal error C1083: 無(wú)法打開(kāi)包括文件:afxwin.h”。前面已經(jīng)講過(guò)首先要檢查MFC組件是否安裝。但如果確認(rèn)裝了還是打不開(kāi)第二個(gè)原因就是項(xiàng)目里的Include目錄配置被改過(guò)。打開(kāi)項(xiàng)目屬性→VC目錄→包含目錄確認(rèn)里面有$(VC_IncludePath)和$(WindowsSDK_IncludePath)以及MFC的atlmfc\include路徑。如果拿VS2017以后版本VS2019/VS2022打開(kāi)這套源碼編譯器默認(rèn)包含目錄可能是新工具集的路徑而MFC頭文件在舊工具集下于是找不到頭文件。遇到這種情況直接在解決方案管理器里右鍵項(xiàng)目→“重定向項(xiàng)目”讓IDE重新選擇工具集更省事。重定向動(dòng)作不只是改PlatformToolset它同時(shí)會(huì)調(diào)整Windows SDK版本和MFC庫(kù)路徑對(duì)初學(xué)MFC的人是最快路徑# 重定向后再用命令行編譯驗(yàn)證錯(cuò)誤信息比IDE折疊后的列表更完整 msbuild MFCDemo.vcxproj /t:Build /p:ConfigurationDebug /p:Platformx64 /v:minimal命令行的好處是能看到完整C1083、C2664、LNK2019逐條上下文錯(cuò)誤列表窗口經(jīng)常把真正有用的上下文折疊掉了。檢查順序報(bào)C1083先看頭文件路徑報(bào)C2664先看字符集報(bào)LNK系列再看鏈接器輸入。4.2 編譯報(bào)錯(cuò) C4996、C2664VS2017 的 Unicode 字符集與舊代碼的沖突第3版教材示例寫(xiě)作年代較早作者默認(rèn)字符集多半是MBCS。VS2017默認(rèn)工程字符集是Unicode于是很多使用char*、CString和CStringA混搭的代碼會(huì)報(bào)C4996“此函數(shù)或變量可能不安全”以及C2664“無(wú)法將參數(shù)從char[]轉(zhuǎn)換為L(zhǎng)PCTSTR”。典型的一段問(wèn)題代碼char szBuf[64]; CString strMsg; strMsg.Format(%s, szBuf); // C4996: Format的%s可能與寬字符集不匹配 SetWindowText(m_hWnd, strMsg); // C2664: char數(shù)組無(wú)法直接轉(zhuǎn)換成LPCTSTR最簡(jiǎn)單的做法是項(xiàng)目屬性→常規(guī)→字符集改成“使用多字節(jié)字符集”。注意VS2017仍然支持MBCS所以圖書(shū)源碼跑起來(lái)很少改代碼。但如果你要長(zhǎng)期使用Unicode就全局搜索char數(shù)組改成TCHAR字符串字面量外面套_T()// 推薦改法用TCHAR和宏統(tǒng)一寬窄字符編譯期自動(dòng)適應(yīng) TCHAR szBuf[64]; CString strMsg; strMsg.Format(_T(%s), szBuf); SetWindowText(m_hWnd, strMsg);順帶提醒VS2019開(kāi)始MBCS被標(biāo)記為棄用如果你手邊是新裝的VS2022最好直接用Unicode方案而不是退回多字節(jié)。VS2017下這條捷徑很好用但別養(yǎng)成永遠(yuǎn)依賴(lài)MBCS的習(xí)慣。4.3 鏈接錯(cuò)誤 LNK2019/LNK2001MFC 源碼包最容易踩到的三種原因編譯過(guò)了、鏈接報(bào)LNK2019是我見(jiàn)得太多的下一關(guān)。三個(gè)高發(fā)原因值得單獨(dú)記住。第一種是類(lèi)只寫(xiě)了聲明沒(méi)寫(xiě)實(shí)現(xiàn)。在.h里聲明了CMyClass::DoSomething()但.cpp里卻忘了定義鏈接時(shí)任何調(diào)用點(diǎn)都會(huì)報(bào)LNK2019。第二種是預(yù)編譯頭配置不對(duì)。.cpp文件第一行的#include stdafx.h被刪了而工程開(kāi)著“使用預(yù)編譯頭”編譯會(huì)跳過(guò)預(yù)編譯頭并產(chǎn)生一批奇奇怪怪的外部符號(hào)錯(cuò)誤。VS2017的新建項(xiàng)目模板已經(jīng)改用pch.h但這本書(shū)源碼里大概率還是stdafx.h統(tǒng)一處理好這個(gè)頭文件能省掉很多無(wú)意義的報(bào)錯(cuò)。第三種更隱蔽源碼中的代碼依賴(lài)了某個(gè)外部庫(kù)但項(xiàng)目沒(méi)有把它加進(jìn)鏈接器。MFC本身會(huì)隱式鏈接user32、gdi32這些核心庫(kù)但如果作者在某章用到了Shell接口或COM調(diào)用而你打開(kāi)的是獨(dú)立工程就可能在鏈接階段掉鏈子。這種情況下直接在相關(guān).cpp頂部顯式加庫(kù)依賴(lài)// 顯式鏈接解決兩個(gè) Win32 API 相關(guān)的 LNK2019 #pragma comment(lib, user32.lib) #pragma comment(lib, gdi32.lib) #pragma comment(lib, shell32.lib)用#pragma comment(lib)寫(xiě)進(jìn).cpp里比在項(xiàng)目屬性里配更直觀也方便隨源碼一起移動(dòng)。如果錯(cuò)誤信息是LNK2001而不是LNK2019通常是符號(hào)聲明了但沒(méi)定義或者定義在了錯(cuò)誤模塊里優(yōu)先檢查類(lèi)和函數(shù)的作用域。5. MFC 源碼調(diào)試避坑現(xiàn)象、原因與解決的5條血淚經(jīng)驗(yàn)5.1 現(xiàn)象編譯通過(guò)但運(yùn)行不到三秒就消失這本書(shū)的示例大多以對(duì)話框和簡(jiǎn)單框架為主最普遍的現(xiàn)象是F5運(yùn)行后一個(gè)黑窗或程序一閃而過(guò)。原因有兩個(gè)一是InitInstance返回了FALSEMFC認(rèn)為初始化失敗直接退出二是對(duì)話框程序里沒(méi)有調(diào)用DoModal或者單文檔框架里沒(méi)有正確設(shè)置文檔模板。解決方法是先在InitInstance開(kāi)頭斷點(diǎn)一步步看程序走到哪里返回。對(duì)話框版本檢查對(duì)話框類(lèi)構(gòu)造時(shí)有沒(méi)有把模板ID傳給基類(lèi)構(gòu)造函數(shù)文檔視圖版本則看ProcessShellCommand的返回值FALSE基本就是模板注冊(cè)失敗?？催@段常見(jiàn)代碼BOOL CMyApp::InitInstance() { CWinApp::InitInstance(); CMyDialog dlg; // 對(duì)話框?qū)ο?dlg.DoModal(); // 模態(tài)循環(huán)啟動(dòng)會(huì)阻塞到窗口關(guān)閉 return FALSE; // 對(duì)話框結(jié)束后退出 }DoModal之前要確認(rèn)對(duì)話框資源ID存在、對(duì)話框類(lèi)有沒(méi)有正確繼承CDialogEx。如果模板ID寫(xiě)錯(cuò)DoModal會(huì)返回-1或IDABORT程序不會(huì)彈窗就直接往下走看起來(lái)就跟“閃退”一樣。5.2 現(xiàn)象對(duì)話框上的按鈕點(diǎn)了沒(méi)反應(yīng)MFC的按鈕點(diǎn)擊靠消息映射不是按鈕自己帶行為。ON_BN_CLICKED宏必須寫(xiě)成“控件ID 處理函數(shù)”的組合兩邊任何一個(gè)拼寫(xiě)錯(cuò)誤都會(huì)讓點(diǎn)擊事件靜默失效。典型錯(cuò)誤是復(fù)制代碼時(shí)把宏放在BEGIN_MESSAGE_MAP外面或者漏掉了END_MESSAGE_MAP。正確寫(xiě)法BEGIN_MESSAGE_MAP(CMyDialog, CDialogEx) ON_BN_CLICKED(IDC_BTN_START, CMyDialog::OnBnClickedBtnStart) END_MESSAGE_MAP()IDC_BTN_START要能在resource.h中找到且按鈕的ID和它一致。如果resource.h和.rc不同步IDE里明明看到按鈕但編譯出來(lái)的ID是另一個(gè)數(shù)字點(diǎn)擊就完全沒(méi)反應(yīng)。這種時(shí)候在資源視圖里選中按鈕看屬性窗口里的ID再和代碼中宏里用到的ID對(duì)照一遍問(wèn)題通常立刻暴露。還有一種不是查詢(xún)而是UI狀態(tài)的問(wèn)題按鈕在窗口里被某個(gè)控件遮擋或EnableWindow被設(shè)成了FALSE現(xiàn)象也是“點(diǎn)了沒(méi)反應(yīng)”斷點(diǎn)不會(huì)命中。5.3 現(xiàn)象Debug版正常Release版崩潰——字符緩沖區(qū)與CString混用的經(jīng)典現(xiàn)場(chǎng)Debug下跑得歡切到Release就崩是MFC老代碼最經(jīng)典的“玄學(xué)”本質(zhì)上是緩沖區(qū)越界和初始化順序問(wèn)題。例如下面的寫(xiě)法在Debug下可能因?yàn)槎研ｒ?yàn)恰好沒(méi)觸發(fā)Release下直接寫(xiě)壞相鄰內(nèi)存char szBuf[8]; strcpy(szBuf, ABCDEFGHIJKLMN); // 必然越界 CString str; str szBuf;Debug版CRT會(huì)在分配塊周?chē)胖谜{(diào)試頭越界后多半先彈斷言Release版沒(méi)有這些保護(hù)數(shù)據(jù)直接覆蓋了堆管理結(jié)構(gòu)表現(xiàn)成“偶爾崩”或“換臺(tái)機(jī)器就崩”。解決方式是不要用strcpy這類(lèi)舊函數(shù)換安全版本#include strsafe.h TCHAR szBuf[8]; StringCchCopy(szBuf, _countof(szBuf), _T(ABCDE)); // 安全截?cái)嚅L(zhǎng)度由目標(biāo)緩沖控制另一個(gè)常見(jiàn)點(diǎn)是CString的GetBuffer拿了指針當(dāng)char*用忘記ReleaseBuffer?？创a時(shí)要養(yǎng)成習(xí)慣GetBuffer之后必須成對(duì)出現(xiàn)ReleaseBuffer否則CString內(nèi)部計(jì)數(shù)是臟的Release析構(gòu)時(shí)會(huì)報(bào)錯(cuò)。調(diào)試這類(lèi)問(wèn)題直接在Release配置下打開(kāi)“啟用運(yùn)行時(shí)檢查”和“/RTC1”不現(xiàn)實(shí)更有效的做法是用Application Verifier跑一遍崩潰點(diǎn)。5.4 現(xiàn)象Win10高DPI下整個(gè)界面模糊/控件錯(cuò)位VS2017時(shí)代創(chuàng)建的MFC程序默認(rèn)不聲明DPI感知在Win10高分屏下Windows會(huì)進(jìn)行位圖拉伸表現(xiàn)是文字發(fā)糊、控件稍微錯(cuò)位。這跟源碼本身關(guān)系不大純粹是環(huán)境配置翻車(chē)。要讓界面清晰在程序最前面調(diào)用SetProcessDpiAwarenessContextWindows 10 1703以后可用或者使用清單文件。VS2017中簡(jiǎn)便做法// 在 CMyApp::InitInstance 最前面調(diào)用 ::SetProcessDpiAwarenessContext(DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2);注意這個(gè)接口只在較新的SDK里聲明如果編譯報(bào)錯(cuò)需要去項(xiàng)目屬性→鏈接器→清單文件→生成DPI感知清單設(shè)為“每監(jiān)視器高DPI感知”。不同分辨率顯示器切換時(shí)MFC的CDialogEx有自適應(yīng)布局但純自繪控件Owner Draw仍要自己處理WM_DPICHANGED消息否則會(huì)有一小塊區(qū)域拉伸模糊。5.5 現(xiàn)象狀態(tài)欄空白不顯示文本——mfc狀態(tài)欄怎么顯示的經(jīng)典問(wèn)題很多學(xué)這本書(shū)的人會(huì)在框架窗體里加狀態(tài)欄得到的是底部一條灰白色區(qū)域但沒(méi)有任何文字。原因是狀態(tài)欄本身由三個(gè)部分組成狀態(tài)欄對(duì)象、Indicator數(shù)組、字符串表里的ID。只Create了狀態(tài)欄卻不調(diào)用SetIndicators它就不知道要顯示哪些固定窗格。static UINT indicators[] { ID_SEPARATOR, // 信息窗格 ID_INDICATOR_CAPS, // Caps Lock狀態(tài) ID_INDICATOR_NUM, // Num Lock狀態(tài) }; // 在 CMainFrame::OnCreate 中調(diào)用 if (!m_wndStatusBar.Create(this) || !m_wndStatusBar.SetIndicators(indicators, sizeof(indicators)/sizeof(UINT))) { return -1; } // 設(shè)置動(dòng)態(tài)文本時(shí)不要用SetWindowText要用SetPaneText m_wndStatusBar.SetPaneText(0, _T(當(dāng)前狀態(tài)));ID_INDICATOR_CAPS和ID_INDICATOR_NUM必須在.rc的字符串表里存在字符串表里每個(gè)ID對(duì)應(yīng)一個(gè)字符串字面量例如“Caps Lock”。如果狀態(tài)欄空白先查resource.h里的三個(gè)ID是否與數(shù)組對(duì)應(yīng)如果編譯報(bào)ID未定義就說(shuō)明.rc和resource.h版本不一致這時(shí)建議用資源視圖里的“查看資源符號(hào)”重新生成而不是手動(dòng)改數(shù)字。6. 從書(shū)里的源碼到自己的程序三個(gè)驗(yàn)證動(dòng)作煉出可復(fù)用代碼6.1 只拷貝.cpp不拷貝.rc自己項(xiàng)目里出現(xiàn)“IDD_xxx未定義”的根本原因從這套源碼里提煉代碼不是把.cpp拖進(jìn)新項(xiàng)目那么簡(jiǎn)單。對(duì)話框類(lèi)依賴(lài)對(duì)話框資源對(duì)話框資源在.rc中控件ID又定義在resource.h中只拿.cpp到新項(xiàng)目就會(huì)遭遇“IDD_MYDIALOG 未定義”或“IDC_BTN_START 未聲明”。復(fù)制代碼時(shí)最保險(xiǎn)的是先看這個(gè)工程一共改過(guò)哪些文件再按這張表決定哪些帶過(guò)去文件類(lèi)型要不要復(fù)制原因.h / .cpp必須類(lèi)聲明與實(shí)現(xiàn).rc必須對(duì)話框模板和菜單資源resource.h必須控件ID符號(hào).aps不用可重新生成.vs文件夾不用IDE本地緩存帶過(guò)去之后在資源編輯器里確認(rèn)對(duì)話框模板的ID和類(lèi)構(gòu)造函數(shù)里傳給CDialog的ID一致。如果類(lèi)里用的是IDD_MY_DIALOG而.rc里叫IDD_OTHER立刻會(huì)有一個(gè)“找不到模板”或?qū)υ捒蚩瞻椎膯?wèn)題出現(xiàn)。6.2 用調(diào)用堆棧驗(yàn)證消息流向而不是靠MessageBox打斷執(zhí)行流很多初學(xué)者源碼里到處放MessageBox這在中大型示例里會(huì)嚴(yán)重干擾消息循環(huán)。更穩(wěn)的方法是使用OutputDebugString寫(xiě)調(diào)試輸出配合VS的“輸出”窗口觀察斷點(diǎn)配合調(diào)用堆棧看消息分發(fā)路徑。下面是能隨時(shí)加進(jìn)代碼的一個(gè)輸出宏#ifdef _DEBUG #define DEBUG_TRACE(s) OutputDebugString(s) #else #define DEBUG_TRACE(s) #endif在OnPaint、OnTimer、OnSetCursor等函數(shù)里各加一行運(yùn)行后在輸出窗口里按來(lái)源篩選“DEBUG_TRACE”就能建立起消息到達(dá)順序的概念。用這套方法驗(yàn)證一個(gè)GDI繪圖程序比一遍遍F10高效得多尤其是在MFC這類(lèi)框架把大量動(dòng)作藏在基類(lèi)里時(shí)調(diào)用堆棧能直接告訴你OnPaint是被Invalidate觸發(fā)的還是窗口創(chuàng)建時(shí)系統(tǒng)消息觸發(fā)的。我自己翻這本書(shū)的源碼這些年收獲最大的一課不是某一個(gè)控件用法而是“資源文件才是一個(gè)MFC示例的靈魂”。界面上每個(gè)按鈕和文本框背后都有一串ID在編譯階段就已經(jīng)綁定到消息映射。養(yǎng)成不改壞資源文件的習(xí)慣后面的學(xué)習(xí)會(huì)少走很多彎路希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取