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