简介这份《精通MFC光盘源代码》配套资源面向具备C基础、希望系统掌握Windows平台MFC框架的开发者与在校学生可用于课程实验、项目开发参考与框架原理自学。压缩包共收录1114个文件以h头文件与cpp源文件为主体辅以vcproj、sln等工程文件、rc与rc2资源脚本、ico与bmp图像素材及manifest清单整体约8.01MB可直接用Visual Studio打开编译运行。内容按16章组织覆盖面向对象与UML建模、窗口与消息机制、CObject运行时信息与序列化、消息映射与处理、对话框与属性表、文档视图结构、GDI与GDI绘图、进程线程、动态链接库、COM组件编程以及.NET托管扩展等主题每章均配有可运行的示例工程。已有513人学习下载适合按章节对照源码调试理解MFC内部实现与消息流转过程也可作为二次开发时的代码模板与排错参考。1. 精通MFC光盘源代码从一张光盘到一套可复现的调试环境很多人第一次接触“精通MFC光盘源代码”这类资源是在旧书摊、师兄的移动硬盘或者某个技术论坛的附件里。光盘里通常塞满了按章节分目录的示例工程每个工程都能单独编译但真正打开时才发现VC6 的 dsw 文件、缺少的 lib、乱码的 rc 资源、以及一堆#include afxwin.h之后找不到头文件的报错。这个标题真正指向的不是让你把光盘里每个例子都跑一遍而是借这套源码建立一套能长期复用的 MFC 调试与改造环境——知道每个示例对应哪个技术点知道怎么把它从旧工具链迁移到 Visual Studio 2022/2026知道消息映射、文档视图、GDI 绘图这些“四大类”骨架在源码里长什么样。适合已经能写 C、但对 Windows 桌面开发还停留在“能拖控件”阶段的人也适合需要维护老 MFC 项目、想从示例里抄一段可靠实现的工程师。光盘只是入口真正的价值在于把源码变成你自己的参考实现库。2. 光盘源码的目录结构与工程类型识别先分清哪类工程值得跑2.1 按章节编号还是按技术点分目录拿到一张“精通MFC”配套光盘第一件事不是双击 sln而是先看目录命名。常见做法是Chapter03、Chapter07这种按书章节切分也有MsgMap、DocView、GDI、Dialog这种按技术点切分。前者适合跟着书顺序读后者适合按需检索。我一般会先建一个索引表把每个目录对应的技术点、工程类型、依赖的库记下来避免后面反复翻。目录特征典型工程类型是否值得优先跑含dsw/dsp且无slnVC6 单文档/对话框先转 VS 再跑含sln且目标版本为 v100 以下VS2010 以前升级工具集后跑目录名含DLL、Lib动态库/静态库示例先编译库再编译调用方目录名含ActiveX、COM控件或组件示例需要注册后才可运行目录名含Skin、UI界面美化示例依赖第三方库最后跑这张表不是绝对的但能帮你快速排除那些“跑起来收益低”的工程。比如一个依赖已停止维护的皮肤库的示例花两小时修编译错误不如直接看它的消息处理逻辑。2.2 用批处理快速统计工程文件与依赖光盘里动辄几十个工程手动一个个打开太慢。我一般写一个简单的 Python 脚本扫描所有.dsp、.vcxproj、.sln把工程名、工具集版本、用到的外部库列出来。这样能一眼看出哪些工程是“自包含”的哪些需要额外配置。import os import re root rD:\MFC_Source # 光盘拷贝到本地的根目录 report [] for dirpath, dirnames, filenames in os.walk(root): for f in filenames: if f.endswith((.dsp, .vcxproj)): full os.path.join(dirpath, f) with open(full, r, errorsignore) as fp: content fp.read() # 提取工具集版本vcxproj 里常见 toolset re.findall(rPlatformToolset([^]), content) # 提取外部依赖库粗略匹配 .lib libs re.findall(r([A-Za-z0-9_]\.lib), content) report.append({ project: f, path: dirpath, toolset: toolset[0] if toolset else v60/v100?, libs: sorted(set(libs)) }) for r in report: print(f{r[project]:30s} toolset{r[toolset]:10s} libs{r[libs]})这段脚本的逻辑很直接遍历目录找到工程文件用正则抓工具集和 lib 引用。参数上root换成你实际拷贝的路径errorsignore是为了兼容旧文件里可能出现的非 UTF-8 字符。输出里如果某个工程libs列表很长说明它依赖外部库多优先跑那些libs为空的。注意.dsp文件里工具集信息不明显所以脚本对旧工程会显示v60/v100?这没关系后面用 VS 打开时会提示升级。2.3 从“四大类”看哪些源码必须精读MFC 的“四大类”通常指CWinApp、CFrameWnd、CView、CDocument对应应用程序、主框架、视图、文档。光盘里如果有一个完整的单文档工程它的App、MainFrm、Doc、View四个派生类就是骨架。精读顺序建议是先看InitInstance里怎么创建主框架和文档模板再看OnDraw里怎么拿到CDC指针最后看消息映射表里ON_COMMAND、ON_UPDATE_COMMAND_UI怎么配对。很多示例的“技巧”其实就藏在这四个类的交互里比如在View里保存数据、在Doc里序列化、在MainFrm里控制工具栏状态。把这一套跑通再看对话框、控件、GDI 绘图会顺很多。3. 把 VC6 工程迁移到 Visual Studio 2022/2026最小命令与必调参数3.1 用命令行完成工程升级与工具集切换直接双击旧.dsw会让 VS 弹一堆迁移向导点多了容易漏掉关键设置。我一般用devenv命令行做静默升级再手动改工具集。前提是你已经安装了“使用 C 的桌面开发”工作负载并且勾选了 MFC 组件VS 安装器里叫“适用于最新 v143 生成工具的 C MFC”。:: 进入 VS 开发者命令提示符 devenv D:\MFC_Source\Chapter03\MyApp.dsw /upgrade :: 升级完成后用 msbuild 编译指定平台和配置 msbuild D:\MFC_Source\Chapter03\MyApp.sln /p:ConfigurationDebug /p:PlatformWin32 /m第一行/upgrade会把 dsw 转成 sln 和 vcxproj并保留备份。第二行用 msbuild 编译/m表示多核并行。如果报错MSB8020: 找不到 v60 的生成工具说明工具集没切过来需要手动改 vcxproj 里的PlatformToolset。常见做法是改成v143VS2022或v144VS2026 预览同时把WindowsTargetPlatformVersion改成10.0。注意不要直接删掉旧配置保留一份Win32的 Debug 和 Release后面排查兼容问题时有用。3.2 字符集与 MFC 库链接的必调参数旧光盘源码很多是 MBCS多字节字符集工程而 VS 默认新工程用 Unicode。迁移时如果报无法解析的外部符号 _main或一堆CString转换错误先检查两个地方项目属性 → 高级 → 字符集以及 MFC 的使用方式。属性页位置参数名旧工程常见值迁移后建议值C/C → 预处理器_MBCS/_UNICODE_MBCS保持_MBCS或改_UNICODE链接器 → 输入附加依赖项mfc42.lib删除由 VS 自动链接常规 → MFC 的使用使用 MFC未设置在共享 DLL 中使用 MFCC/C → 代码生成运行库多线程 DLL (/MD)多线程调试 DLL (/MDd)我一般会先保持_MBCS不动只把 MFC 使用方式设为“在共享 DLL 中使用 MFC”这样能避开大部分CString的LPCWSTR转换错误。如果源码里大量用了sprintf、strcpy强行改 Unicode 会引入一堆_s版本问题不如先跑通再逐步替换。链接器里的mfc42.lib这类旧库名一定要删掉否则会和当前版本的 MFC 库冲突报重复定义。3.3 资源视图乱码与 rc 文件编码修复旧光盘的.rc文件经常是 GB2312 编码VS 打开后中文变成乱码对话框标题、菜单项全花了。修复方法不是用记事本另存为 UTF-8那样会破坏资源编译器对代码页的识别。正确做法是在 rc 文件开头加一行#pragma code_page(936)然后用 VS 的资源编辑器重新保存。// 在 .rc 文件顶部所有 #include 之前加入 #pragma code_page(936) #include afxres.h #include verrsrc.h936是简体中文代码页。加完后关闭资源视图再重新打开乱码一般会恢复。如果个别字符串还是乱检查String Table里的内容是否被截断必要时手动补全。注意改完 rc 后要清理解决方案再重新生成否则资源编译器可能用缓存。4. 从源码里抄一段可靠实现消息映射、文件存在判断与列表列数获取4.1 消息映射表的正确写法与常见漏项MFC 的消息映射是“声明 实现 表”三件套光盘源码里经常能看到只写了表、忘了在头文件里声明afx_msg的工程编译时报error C2065: OnMyCommand : undeclared identifier。正确的写法如下。// MyView.h class CMyView : public CView { protected: afx_msg void OnFileCheck(); afx_msg void OnUpdateFileCheck(CCmdUI* pCmdUI); DECLARE_MESSAGE_MAP() }; // MyView.cpp BEGIN_MESSAGE_MAP(CMyView, CView) ON_COMMAND(ID_FILE_CHECK, CMyView::OnFileCheck) ON_UPDATE_COMMAND_UI(ID_FILE_CHECK, CMyView::OnUpdateFileCheck) END_MESSAGE_MAP() void CMyView::OnFileCheck() { CString path _T(D:\\test.txt); if (PathFileExists(path)) // 需要包含 shlwapi.h 并链接 shlwapi.lib { AfxMessageBox(_T(文件存在)); } else { AfxMessageBox(_T(文件不存在)); } } void CMyView::OnUpdateFileCheck(CCmdUI* pCmdUI) { pCmdUI-Enable(TRUE); // 控制菜单项是否可用 }这里ON_COMMAND绑定命令处理ON_UPDATE_COMMAND_UI控制菜单状态。PathFileExists是shlwapi里的函数比CFile::GetStatus更直接。参数上ID_FILE_CHECK是资源里定义的命令 ID必须和菜单项一致。如果编译报PathFileExists未定义在stdafx.h里加#include shlwapi.h和#pragma comment(lib, shlwapi.lib)。注意OnUpdateFileCheck里不要做耗时操作否则菜单会卡。4.2 获取列表控件总列数的两种方式与内存泄漏点热词里“mfc 获取列表总列数”是个高频问题。CListCtrl没有直接的GetColumnCount常见做法是用GetHeaderCtrl()-GetItemCount()。但这里有个坑GetHeaderCtrl返回的CHeaderCtrl*是临时对象不要保存它否则可能内存泄漏。int GetColumnCount(CListCtrl list) { CHeaderCtrl* pHeader list.GetHeaderCtrl(); if (pHeader nullptr) return 0; return pHeader-GetItemCount(); } // 调用示例 void CMyDialog::OnGetColCount() { int n GetColumnCount(m_List); CString msg; msg.Format(_T(列数%d), n); AfxMessageBox(msg); }逻辑上GetHeaderCtrl返回的是列表头控件的指针GetItemCount返回列数。参数上传入的list必须是已经创建好的CListCtrl对象如果列表还没InsertColumn返回 0。注意不要用list.GetHeaderCtrl()-GetItemCount()这种链式调用后还去delete指针那会直接崩溃。如果列表是动态创建的确保在OnInitDialog里先InsertColumn再调用这个函数。4.3 字符串内存泄漏的排查习惯热词里“mfc字符串内存泄漏”通常不是CString本身的问题而是GetBuffer后忘了ReleaseBuffer或者new了char*没delete[]。我一般会在 Debug 配置下打开_CRTDBG_MAP_ALLOC让泄漏报告带行号。// 在 stdafx.h 或主 cpp 顶部加入 #define _CRTDBG_MAP_ALLOC #include stdlib.h #include crtdbg.h // 在 App 的 InitInstance 开头加入 _CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF); // 如果已知某个分配编号泄漏可以设置断点 // _CrtSetBreakAlloc(123);这样程序退出时输出窗口会打印泄漏的分配编号和文件行号。参数上_CRTDBG_ALLOC_MEM_DF启用分配检查_CRTDBG_LEAK_CHECK_DF在退出时自动检查。注意MFC 内部有些全局对象也会被报告先看那些带自己源码文件名的条目。如果泄漏来自CString::GetBuffer检查是否在ReleaseBuffer之前就return了。5. 避坑与排查光盘源码在现代化环境里的五个翻车现场5.1 现象编译报fatal error C1083: 无法打开包括文件: afxwin.h原因VS 安装时没有勾选 MFC 组件或者工程属性里“使用 MFC”被设成了“使用标准 Windows 库”。解决打开 VS 安装器修改“使用 C 的桌面开发”在右侧“可选”里勾选“适用于最新 v143 生成工具的 C MFC”。然后在项目属性 → 常规 → 使用 MFC改为“在共享 DLL 中使用 MFC”。如果还是找不到检查VC 目录里的包含目录是否被旧工程的绝对路径覆盖了。5.2 现象程序运行后界面是英文或者菜单项灰色不可点原因资源文件里的语言设置不对或者ON_UPDATE_COMMAND_UI没写。解决在资源视图里右键项目 → 属性 → 资源 → 语言改成“中文简体中国”。菜单灰色则检查对应的ON_UPDATE_COMMAND_UI处理函数是否调用了pCmdUI-Enable(TRUE)默认状态可能是FALSE。5.3 现象CListCtrl插入列后调用GetHeaderCtrl()-GetItemCount()返回 0原因列表控件还没有创建窗口句柄或者InsertColumn失败。解决确保在OnInitDialog或OnCreate之后调用并且InsertColumn的返回值不是 -1。如果列表是动态创建的先调用Create再插入列。另外GetHeaderCtrl在列表为空时可能返回nullptr加一层判断。5.4 现象迁移后CString赋值给const char*报错原因工程从 MBCS 改成了 UnicodeCString变成CStringW不能隐式转const char*。解决要么把字符集改回 MBCS要么用CStringA做转换例如CStringA tmp(cs); const char* p tmp;。注意tmp是局部变量不要返回它的指针。5.5 现象Debug 下退出时报一堆内存泄漏但代码里没new原因MFC 的_CrtSetDbgFlag会报告所有未释放的分配包括一些第三方库或 MFC 内部缓存。解决先看泄漏报告里带自己源码文件名的条目忽略afxwin1.inl之类的内部文件。如果确实是自己代码检查GetBuffer/ReleaseBuffer配对以及new和delete是否匹配。实在找不到用_CrtSetBreakAlloc在指定分配编号处断下看调用栈。6. 把光盘源码变成自己的参考库一个可复用的调试技巧光盘里的示例跑通之后真正有价值的是把它们变成“可检索的参考实现”。我自己的习惯是在本地建一个MFC_Snippets目录按技术点分文件夹每个文件夹里放一个最小可编译的工程外加一个README.md记录这个示例解决了什么问题、关键函数在哪、参数怎么调。比如FileExists、GetColumnCount、MsgMap各一个工程。这样下次遇到类似需求直接打开对应工程复制代码块而不是去翻光盘里几十个章节。具体做法是先用前面提到的 Python 脚本扫描所有工程把每个工程的技术点标签提取出来然后手动筛选出 10 到 15 个最常用的用 VS 的“导出模板”功能存成项目模板。导出时注意把PlatformToolset固定为v143字符集固定为_MBCS这样新建工程时不用再改配置。模板文件默认在Documents\Visual Studio 2022\My Exported Templates可以拷贝到团队共享目录。验证这套参考库是否可靠我一般会做一次“冷启动测试”关掉所有 VS 实例清空%TEMP%然后从模板新建一个工程只写业务逻辑看能不能在 5 分钟内编译运行。如果超过 5 分钟说明模板里还有隐藏依赖没清理干净。这个习惯帮我省了很多重复配置的时间也让我对 MFC 的消息流、资源加载顺序有了更具体的感知。希望帮到你。本文还有配套的精品资源点击获取 精通MFC光盘源码：从VC6迁移到VS2022的调试环境搭建与避坑指南
简介这份《精通MFC光盘源代码》配套资源面向具备C基础、希望系统掌握Windows平台MFC框架的开发者与在校学生可用于课程实验、项目开发参考与框架原理自学。压缩包共收录1114个文件以h头文件与cpp源文件为主体辅以vcproj、sln等工程文件、rc与rc2资源脚本、ico与bmp图像素材及manifest清单整体约8.01MB可直接用Visual Studio打开编译运行。内容按16章组织覆盖面向对象与UML建模、窗口与消息机制、CObject运行时信息与序列化、消息映射与处理、对话框与属性表、文档视图结构、GDI与GDI绘图、进程线程、动态链接库、COM组件编程以及.NET托管扩展等主题每章均配有可运行的示例工程。已有513人学习下载适合按章节对照源码调试理解MFC内部实现与消息流转过程也可作为二次开发时的代码模板与排错参考。1. 精通MFC光盘源代码从一张光盘到一套可复现的调试环境很多人第一次接触“精通MFC光盘源代码”这类资源是在旧书摊、师兄的移动硬盘或者某个技术论坛的附件里。光盘里通常塞满了按章节分目录的示例工程每个工程都能单独编译但真正打开时才发现VC6 的 dsw 文件、缺少的 lib、乱码的 rc 资源、以及一堆#include afxwin.h之后找不到头文件的报错。这个标题真正指向的不是让你把光盘里每个例子都跑一遍而是借这套源码建立一套能长期复用的 MFC 调试与改造环境——知道每个示例对应哪个技术点知道怎么把它从旧工具链迁移到 Visual Studio 2022/2026知道消息映射、文档视图、GDI 绘图这些“四大类”骨架在源码里长什么样。适合已经能写 C、但对 Windows 桌面开发还停留在“能拖控件”阶段的人也适合需要维护老 MFC 项目、想从示例里抄一段可靠实现的工程师。光盘只是入口真正的价值在于把源码变成你自己的参考实现库。2. 光盘源码的目录结构与工程类型识别先分清哪类工程值得跑2.1 按章节编号还是按技术点分目录拿到一张“精通MFC”配套光盘第一件事不是双击 sln而是先看目录命名。常见做法是Chapter03、Chapter07这种按书章节切分也有MsgMap、DocView、GDI、Dialog这种按技术点切分。前者适合跟着书顺序读后者适合按需检索。我一般会先建一个索引表把每个目录对应的技术点、工程类型、依赖的库记下来避免后面反复翻。目录特征典型工程类型是否值得优先跑含dsw/dsp且无slnVC6 单文档/对话框先转 VS 再跑含sln且目标版本为 v100 以下VS2010 以前升级工具集后跑目录名含DLL、Lib动态库/静态库示例先编译库再编译调用方目录名含ActiveX、COM控件或组件示例需要注册后才可运行目录名含Skin、UI界面美化示例依赖第三方库最后跑这张表不是绝对的但能帮你快速排除那些“跑起来收益低”的工程。比如一个依赖已停止维护的皮肤库的示例花两小时修编译错误不如直接看它的消息处理逻辑。2.2 用批处理快速统计工程文件与依赖光盘里动辄几十个工程手动一个个打开太慢。我一般写一个简单的 Python 脚本扫描所有.dsp、.vcxproj、.sln把工程名、工具集版本、用到的外部库列出来。这样能一眼看出哪些工程是“自包含”的哪些需要额外配置。import os import re root rD:\MFC_Source # 光盘拷贝到本地的根目录 report [] for dirpath, dirnames, filenames in os.walk(root): for f in filenames: if f.endswith((.dsp, .vcxproj)): full os.path.join(dirpath, f) with open(full, r, errorsignore) as fp: content fp.read() # 提取工具集版本vcxproj 里常见 toolset re.findall(rPlatformToolset([^]), content) # 提取外部依赖库粗略匹配 .lib libs re.findall(r([A-Za-z0-9_]\.lib), content) report.append({ project: f, path: dirpath, toolset: toolset[0] if toolset else v60/v100?, libs: sorted(set(libs)) }) for r in report: print(f{r[project]:30s} toolset{r[toolset]:10s} libs{r[libs]})这段脚本的逻辑很直接遍历目录找到工程文件用正则抓工具集和 lib 引用。参数上root换成你实际拷贝的路径errorsignore是为了兼容旧文件里可能出现的非 UTF-8 字符。输出里如果某个工程libs列表很长说明它依赖外部库多优先跑那些libs为空的。注意.dsp文件里工具集信息不明显所以脚本对旧工程会显示v60/v100?这没关系后面用 VS 打开时会提示升级。2.3 从“四大类”看哪些源码必须精读MFC 的“四大类”通常指CWinApp、CFrameWnd、CView、CDocument对应应用程序、主框架、视图、文档。光盘里如果有一个完整的单文档工程它的App、MainFrm、Doc、View四个派生类就是骨架。精读顺序建议是先看InitInstance里怎么创建主框架和文档模板再看OnDraw里怎么拿到CDC指针最后看消息映射表里ON_COMMAND、ON_UPDATE_COMMAND_UI怎么配对。很多示例的“技巧”其实就藏在这四个类的交互里比如在View里保存数据、在Doc里序列化、在MainFrm里控制工具栏状态。把这一套跑通再看对话框、控件、GDI 绘图会顺很多。3. 把 VC6 工程迁移到 Visual Studio 2022/2026最小命令与必调参数3.1 用命令行完成工程升级与工具集切换直接双击旧.dsw会让 VS 弹一堆迁移向导点多了容易漏掉关键设置。我一般用devenv命令行做静默升级再手动改工具集。前提是你已经安装了“使用 C 的桌面开发”工作负载并且勾选了 MFC 组件VS 安装器里叫“适用于最新 v143 生成工具的 C MFC”。:: 进入 VS 开发者命令提示符 devenv D:\MFC_Source\Chapter03\MyApp.dsw /upgrade :: 升级完成后用 msbuild 编译指定平台和配置 msbuild D:\MFC_Source\Chapter03\MyApp.sln /p:ConfigurationDebug /p:PlatformWin32 /m第一行/upgrade会把 dsw 转成 sln 和 vcxproj并保留备份。第二行用 msbuild 编译/m表示多核并行。如果报错MSB8020: 找不到 v60 的生成工具说明工具集没切过来需要手动改 vcxproj 里的PlatformToolset。常见做法是改成v143VS2022或v144VS2026 预览同时把WindowsTargetPlatformVersion改成10.0。注意不要直接删掉旧配置保留一份Win32的 Debug 和 Release后面排查兼容问题时有用。3.2 字符集与 MFC 库链接的必调参数旧光盘源码很多是 MBCS多字节字符集工程而 VS 默认新工程用 Unicode。迁移时如果报无法解析的外部符号 _main或一堆CString转换错误先检查两个地方项目属性 → 高级 → 字符集以及 MFC 的使用方式。属性页位置参数名旧工程常见值迁移后建议值C/C → 预处理器_MBCS/_UNICODE_MBCS保持_MBCS或改_UNICODE链接器 → 输入附加依赖项mfc42.lib删除由 VS 自动链接常规 → MFC 的使用使用 MFC未设置在共享 DLL 中使用 MFCC/C → 代码生成运行库多线程 DLL (/MD)多线程调试 DLL (/MDd)我一般会先保持_MBCS不动只把 MFC 使用方式设为“在共享 DLL 中使用 MFC”这样能避开大部分CString的LPCWSTR转换错误。如果源码里大量用了sprintf、strcpy强行改 Unicode 会引入一堆_s版本问题不如先跑通再逐步替换。链接器里的mfc42.lib这类旧库名一定要删掉否则会和当前版本的 MFC 库冲突报重复定义。3.3 资源视图乱码与 rc 文件编码修复旧光盘的.rc文件经常是 GB2312 编码VS 打开后中文变成乱码对话框标题、菜单项全花了。修复方法不是用记事本另存为 UTF-8那样会破坏资源编译器对代码页的识别。正确做法是在 rc 文件开头加一行#pragma code_page(936)然后用 VS 的资源编辑器重新保存。// 在 .rc 文件顶部所有 #include 之前加入 #pragma code_page(936) #include afxres.h #include verrsrc.h936是简体中文代码页。加完后关闭资源视图再重新打开乱码一般会恢复。如果个别字符串还是乱检查String Table里的内容是否被截断必要时手动补全。注意改完 rc 后要清理解决方案再重新生成否则资源编译器可能用缓存。4. 从源码里抄一段可靠实现消息映射、文件存在判断与列表列数获取4.1 消息映射表的正确写法与常见漏项MFC 的消息映射是“声明 实现 表”三件套光盘源码里经常能看到只写了表、忘了在头文件里声明afx_msg的工程编译时报error C2065: OnMyCommand : undeclared identifier。正确的写法如下。// MyView.h class CMyView : public CView { protected: afx_msg void OnFileCheck(); afx_msg void OnUpdateFileCheck(CCmdUI* pCmdUI); DECLARE_MESSAGE_MAP() }; // MyView.cpp BEGIN_MESSAGE_MAP(CMyView, CView) ON_COMMAND(ID_FILE_CHECK, CMyView::OnFileCheck) ON_UPDATE_COMMAND_UI(ID_FILE_CHECK, CMyView::OnUpdateFileCheck) END_MESSAGE_MAP() void CMyView::OnFileCheck() { CString path _T(D:\\test.txt); if (PathFileExists(path)) // 需要包含 shlwapi.h 并链接 shlwapi.lib { AfxMessageBox(_T(文件存在)); } else { AfxMessageBox(_T(文件不存在)); } } void CMyView::OnUpdateFileCheck(CCmdUI* pCmdUI) { pCmdUI-Enable(TRUE); // 控制菜单项是否可用 }这里ON_COMMAND绑定命令处理ON_UPDATE_COMMAND_UI控制菜单状态。PathFileExists是shlwapi里的函数比CFile::GetStatus更直接。参数上ID_FILE_CHECK是资源里定义的命令 ID必须和菜单项一致。如果编译报PathFileExists未定义在stdafx.h里加#include shlwapi.h和#pragma comment(lib, shlwapi.lib)。注意OnUpdateFileCheck里不要做耗时操作否则菜单会卡。4.2 获取列表控件总列数的两种方式与内存泄漏点热词里“mfc 获取列表总列数”是个高频问题。CListCtrl没有直接的GetColumnCount常见做法是用GetHeaderCtrl()-GetItemCount()。但这里有个坑GetHeaderCtrl返回的CHeaderCtrl*是临时对象不要保存它否则可能内存泄漏。int GetColumnCount(CListCtrl list) { CHeaderCtrl* pHeader list.GetHeaderCtrl(); if (pHeader nullptr) return 0; return pHeader-GetItemCount(); } // 调用示例 void CMyDialog::OnGetColCount() { int n GetColumnCount(m_List); CString msg; msg.Format(_T(列数%d), n); AfxMessageBox(msg); }逻辑上GetHeaderCtrl返回的是列表头控件的指针GetItemCount返回列数。参数上传入的list必须是已经创建好的CListCtrl对象如果列表还没InsertColumn返回 0。注意不要用list.GetHeaderCtrl()-GetItemCount()这种链式调用后还去delete指针那会直接崩溃。如果列表是动态创建的确保在OnInitDialog里先InsertColumn再调用这个函数。4.3 字符串内存泄漏的排查习惯热词里“mfc字符串内存泄漏”通常不是CString本身的问题而是GetBuffer后忘了ReleaseBuffer或者new了char*没delete[]。我一般会在 Debug 配置下打开_CRTDBG_MAP_ALLOC让泄漏报告带行号。// 在 stdafx.h 或主 cpp 顶部加入 #define _CRTDBG_MAP_ALLOC #include stdlib.h #include crtdbg.h // 在 App 的 InitInstance 开头加入 _CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF); // 如果已知某个分配编号泄漏可以设置断点 // _CrtSetBreakAlloc(123);这样程序退出时输出窗口会打印泄漏的分配编号和文件行号。参数上_CRTDBG_ALLOC_MEM_DF启用分配检查_CRTDBG_LEAK_CHECK_DF在退出时自动检查。注意MFC 内部有些全局对象也会被报告先看那些带自己源码文件名的条目。如果泄漏来自CString::GetBuffer检查是否在ReleaseBuffer之前就return了。5. 避坑与排查光盘源码在现代化环境里的五个翻车现场5.1 现象编译报fatal error C1083: 无法打开包括文件: afxwin.h原因VS 安装时没有勾选 MFC 组件或者工程属性里“使用 MFC”被设成了“使用标准 Windows 库”。解决打开 VS 安装器修改“使用 C 的桌面开发”在右侧“可选”里勾选“适用于最新 v143 生成工具的 C MFC”。然后在项目属性 → 常规 → 使用 MFC改为“在共享 DLL 中使用 MFC”。如果还是找不到检查VC 目录里的包含目录是否被旧工程的绝对路径覆盖了。5.2 现象程序运行后界面是英文或者菜单项灰色不可点原因资源文件里的语言设置不对或者ON_UPDATE_COMMAND_UI没写。解决在资源视图里右键项目 → 属性 → 资源 → 语言改成“中文简体中国”。菜单灰色则检查对应的ON_UPDATE_COMMAND_UI处理函数是否调用了pCmdUI-Enable(TRUE)默认状态可能是FALSE。5.3 现象CListCtrl插入列后调用GetHeaderCtrl()-GetItemCount()返回 0原因列表控件还没有创建窗口句柄或者InsertColumn失败。解决确保在OnInitDialog或OnCreate之后调用并且InsertColumn的返回值不是 -1。如果列表是动态创建的先调用Create再插入列。另外GetHeaderCtrl在列表为空时可能返回nullptr加一层判断。5.4 现象迁移后CString赋值给const char*报错原因工程从 MBCS 改成了 UnicodeCString变成CStringW不能隐式转const char*。解决要么把字符集改回 MBCS要么用CStringA做转换例如CStringA tmp(cs); const char* p tmp;。注意tmp是局部变量不要返回它的指针。5.5 现象Debug 下退出时报一堆内存泄漏但代码里没new原因MFC 的_CrtSetDbgFlag会报告所有未释放的分配包括一些第三方库或 MFC 内部缓存。解决先看泄漏报告里带自己源码文件名的条目忽略afxwin1.inl之类的内部文件。如果确实是自己代码检查GetBuffer/ReleaseBuffer配对以及new和delete是否匹配。实在找不到用_CrtSetBreakAlloc在指定分配编号处断下看调用栈。6. 把光盘源码变成自己的参考库一个可复用的调试技巧光盘里的示例跑通之后真正有价值的是把它们变成“可检索的参考实现”。我自己的习惯是在本地建一个MFC_Snippets目录按技术点分文件夹每个文件夹里放一个最小可编译的工程外加一个README.md记录这个示例解决了什么问题、关键函数在哪、参数怎么调。比如FileExists、GetColumnCount、MsgMap各一个工程。这样下次遇到类似需求直接打开对应工程复制代码块而不是去翻光盘里几十个章节。具体做法是先用前面提到的 Python 脚本扫描所有工程把每个工程的技术点标签提取出来然后手动筛选出 10 到 15 个最常用的用 VS 的“导出模板”功能存成项目模板。导出时注意把PlatformToolset固定为v143字符集固定为_MBCS这样新建工程时不用再改配置。模板文件默认在Documents\Visual Studio 2022\My Exported Templates可以拷贝到团队共享目录。验证这套参考库是否可靠我一般会做一次“冷启动测试”关掉所有 VS 实例清空%TEMP%然后从模板新建一个工程只写业务逻辑看能不能在 5 分钟内编译运行。如果超过 5 分钟说明模板里还有隐藏依赖没清理干净。这个习惯帮我省了很多重复配置的时间也让我对 MFC 的消息流、资源加载顺序有了更具体的感知。希望帮到你。本文还有配套的精品资源点击获取