简介《精通MFC》光盘配套源代码是学习MFC与Windows C编程的实用参考包。资源按原书第116章组织内容覆盖非常系统从面向对象与UML基础到窗口消息机制、MFC应用框架、消息映射与处理、对话框含通用对话框和HTML对话框、文档/视图结构、GDI/GDI绘图、进程与线程、动态链接库、COM组件编程以及.NET托管扩展。每个章节均配有可直接编译运行的示例工程读者可对照书本逐章调试观察MFC类库内部如何完成窗口创建、消息分发、序列化、绘图和组件聚合等关键机制特别适合有一定C基础、正在系统学习Windows程序设计的开发者。压缩包共1114个文件以h/cpp源代码、vcproj/sln工程文件、rc资源文件为主其中的头文件和实现文件对应各章示例代码工程文件用于Visual Studio打开和编译RC/RC2定义了界面资源配合ico、bmp等图标位图完整还原原书配套开发环境。整体仅8.01MB目录结构清晰便于按章节索引。目前已有513人学习下载是一份经典MFC教材的配套实战资料。1. 项目概述这套MFC源代码到底是什么“精通MFC光盘源代码”这个标题看起来就像你从某个旧书摊或者网盘里翻出来的压缩包。拆开之后里面是一整套VC工程文件对应的是《精通MFC》那本书随书光盘里的源码。书是很多年前出的但代码本身并没有过时——MFC作为Windows桌面开发的老牌框架至今仍然在工业软件、工控上位机、内部工具等场景里大量存活着。这套源代码的价值不在于“它有多新”而在于它几乎涵盖了MFC从入门到进阶的经典案例对话框程序、文档视图架构、控件自定义、GDI绘图、数据库访问、多线程、Socket通信、ActiveX控件等等。换句话说你拿到的不只是几个demo而是一套可以按图索骥的学习路径。适合谁看两类人。第一类是刚接触Windows C开发、想搞清楚“MFC项目到底怎么组织”的同学第二类是工作中突然接手老项目、需要快速理解MFC工程结构的人。我自己属于后者当年接手一个十几年前的工控上位机项目靠的就是把这种随书源码翻了个底朝天。有一点先说清楚所谓“精通”在实际代码里并不会给你什么黑魔法它更像是一个结构良好的代码仓库里面每个示例都在演示某个具体功能点的实现方式。用这本书配套源码学习最大的好处是——所有代码都能直接编译运行你不用像看零散博客那样猜头文件、猜宏定义。只要你装一个Visual StudioVS2013以上都行VS2015/2017/2019处理老工程的兼容性更好打开.sln文件基本都能直接跑起来。接下来我会从工程结构、核心原理、实操流程、坑点排查这几个维度把这套代码彻底吃透。不管你是要拿它学习还是想借鉴里面的代码去改造自己的项目这篇文章都能给你省下大量摸索时间。2. 工程整体设计与代码结构拆解2.1 随书光盘里的典型目录组织拿到这套源代码后你第一眼看到的往往是十几个文件夹每个文件夹对应书里的一个章节或一个完整例子。典型的目录结构大概是这样的Chapter02_DialogDemo Chapter03_ControlDemo Chapter04_DocumentView Chapter05_GDIDraw Chapter06_Database Chapter07_Thread Chapter08_Socket Chapter09_ActiveX ... Common这里面的Common文件夹很关键它存放的是多个示例公用的头文件和辅助类。为什么要单拆一个Common出来因为MFC项目里很多东西是可以复用的比如一个自定义的消息映射宏、一个通用的日志类、一个统一的文件路径处理函数。把公用代码抽出来每个示例只保留自己的核心逻辑整个代码仓库就会非常清爽。这也是老一代C工程师的习惯——他们写代码非常讲究模块复用几乎不会在一个项目里复制粘贴大段代码。每个章节内的工程通常是一个完整的Visual Studio解决方案文件.sln加一个项目文件夹。项目文件夹里常见的文件包括.dspVS6的工程文件、.dswVS6的工作区文件如果是高版本的VS还会有.vcxproj和.vcxproj.filters。这套源代码的年代跨度比较大从VC6到VS2010都有所以兼容性处理是学习过程中绕不开的一个话题。2.2 为什么用MFC而不直接用Win32 APIMFC本质上是对Windows API的一个C封装。它做的事情是把CreateWindow、RegisterClass、消息循环、窗口过程这些繁琐的原生API封装成了类和方法。你写Win32程序的时候要自己维护一个WndProc回调函数用switch-case处理各种WM_COMMAND、WM_PAINT消息而在MFC里你只需要继承一个CWinApp和CFrameWnd然后在消息映射宏里声明自己的处理函数即可。从这套源代码里你能明显感受到MFC设计的两个核心思路第一消息映射机制替代了传统的window procedure。MFC利用一组宏BEGIN_MESSAGE_MAP、ON_COMMAND、ON_BN_CLICKED等在编译阶段把消息和成员函数绑定起来。这样你不需要自己写switch-case也不需要手动维护函数指针表代码在视觉上清爽很多。第二文档/视图架构解决了数据与显示的分离问题。在Chapter04_DocumentView这类例子里你会看到CDocument负责数据读写CView负责界面显示。这种做法在数据量较大、视图类型多样比如同一个数据既要用表格显示又要用图表显示的场景下特别有优势。但注意MFC不是万能的。它的问题也很明显继承层级深、封装过度、调试困难。这套代码里的类很多光看类名就能绕晕人。我的建议是初学阶段不要试图理解每一个类的每一个方法先抓住消息流这条主线——窗口如何创建、消息如何分发、数据如何更新——把这条线理顺了其他的都是细枝末节。2.3 构建系统与编译环境的适配老工程源码最让人头疼的就是编译环境。这套代码里有一部分是VC6时代写的用的是老式的WIN32_LEAN_AND_MEAN、没有stdafx.h这种预编译头的概念VC6也有但命名习惯和现在不太一样。在新版Visual Studio里打开通常会遇到两类报错一是平台工具集不匹配。VS2019默认使用v142工具集VS6代码期望的是v60工具集。解决方法是选中项目右键→属性→常规→平台工具集改成Visual Studio 2015 (v140)或者Visual Studio 2017 (v141)或者干脆安装“VS2015工具集”兼容包。二是Unicode与ANSI编码冲突。老代码大量使用char*字符串而新版VS默认字符集是Unicode。你会看到一大堆cannot convert from const char * to LPCTSTR之类的报错。处理方法有两种要么在项目属性里把字符集改为“使用多字节字符集”要么老老实实把代码里的字符串和API都改成宽字符版本。前者快但不利于通用性后者工程量大但一劳永逸。我自己的经验是能改字符集就改字符集因为这套代码主要拿来学习和参考不是生产系统没必要花大量时间去适配Unicode。如果你确实需要在一个生产级项目里使用老MFC代码那就耐心做Unicode改造。3. 核心细节解析与实操要点3.1 消息映射宏的底层原理MFC消息映射是理解整套源代码的钥匙。你打开任何一个源文件几乎都能看到这样的结构BEGIN_MESSAGE_MAP(CMyDialog, CDialogEx) ON_WM_PAINT() ON_BN_CLICKED(IDC_BUTTON_OK, CMyDialog::OnBnClickedButtonOk) ON_COMMAND(ID_FILE_OPEN, CMyDialog::OnFileOpen) END_MESSAGE_MAP()这段代码到底干了什么本质上它在编译阶段被展开为一个静态数组数组里存放着消息编号、控件ID和成员函数指针的关系表。当操作系统把一个消息发给窗口时MFC会根据窗口类中的消息映射表查找到对应的处理函数然后调用它。相比传统的switch-case这种做法的好处是不同控件、不同命令各归其位代码扩展性更好。比如你新增一个菜单项只需要加一个ON_COMMAND宏和对应的成员函数编译器会帮你把一切连接好而不需要去动大的窗口过程函数。这里面有个容易踩的坑消息映射宏的顺序不是无关紧要的。MFC在查找消息处理时是按数组顺序逐个匹配的。一般来说ON_MESSAGE这种自定义消息处理宏和ON_BN_CLICKED放在一起没有问题但千万不要把两个能同时匹配同一消息的宏写重复或者前后顺序颠倒否则容易出现“消息被前面的宏截胡”的现象程序行为会变得诡异。3.2 控件的创建与自定义按钮的实现这套源代码里很多人最感兴趣的就是MFC自定义按钮的实现。MFC提供的CButton类本身就能显示按钮文本和处理点击消息但它长得太原生——没有圆角、没有渐变色、没有图标。要实现一个好看的自定义按钮通常有两条路自绘Owner-Draw和子类化Subclassing。自绘的思路是重写CButton的DrawItem函数把按钮的每一帧状态正常、悬停、按下、禁用都自己画出来。流程分几步在对话框上放一个普通Button设置它的Owner Draw属性。从CButton派生一个类CMyButton重写DrawItem。在DrawItem里根据按钮状态用CDC绘制填充背景、边框、文字甚至加载位图作为底图。子类化的思路是不改变按钮的绘制逻辑而是给按钮绑定一个新的窗口过程拦截它的WM_PAINT、WM_MOUSEMOVE等消息在原有绘制基础上叠加新效果。从这套源代码里你可以学到的是具体的GDI绘制API调用细节。比如void CMyButton::DrawItem(LPDRAWITEMSTRUCT lpDrawItemStruct) { CDC* pDC CDC::FromHandle(lpDrawItemStruct-hDC); CRect rect(lpDrawItemStruct-rcItem); UINT state lpDrawItemStruct-itemState; // 根据状态选择背景色 if (state ODS_SELECTED) pDC-FillSolidRect(rect, RGB(200, 200, 200)); else pDC-FillSolidRect(rect, RGB(240, 240, 240)); // 画文字 CString strText; GetWindowText(strText); pDC-SetTextColor(RGB(0, 0, 0)); pDC-SetBkMode(TRANSPARENT); pDC-DrawText(strText, rect, DT_CENTER | DT_VCENTER | DT_SINGLELINE); }这套代码的价值就在这些细节里FillSolidRect怎么用、DrawText的对齐标志怎么组合、ODS_SELECTED状态是从哪来的书里讲得清清楚楚。你照着改颜色、改边框样式就能做出自己品牌风格的自定义按钮。3.3 GDI绘图与OpenGL集成热词里出现了“基于mfc绘制一个彩色正方形”、“mfc opengl”这两个需求在源代码里都能找到参考。MFC里GDI绘图的核心是设备上下文DC所有画图都通过CDC类来完成。画一个彩色正方形核心代码无非是CBrush brush(RGB(255, 0, 0)); CPen pen(PS_SOLID, 2, RGB(0, 0, 255)); CClientDC dc(this); dc.SelectObject(brush); dc.SelectObject(pen); dc.Rectangle(50, 50, 200, 200); dc.SelectObject(brush); // 恢复原对象 dc.SelectObject(pen);这里有个必须注意的点选入DC的对象用完之后一定要恢复原状否则会资源泄漏。这套源代码里几乎每个绘图示例都遵守了这个规矩。至于MFC和OpenGL的结合思想也很清晰。你需要在一个MFC窗口上创建OpenGL渲染上下文HGLRC思路是在窗口的OnCreate里设置窗口样式为WS_CLIPCHILDREN | WS_CLIPSIBLINGS并调用SetPixelFormat和wglCreateContext。在OnPaint或者专门的渲染循环里用wglMakeCurrent切换到当前线程的OpenGL上下文。调用OpenGL函数绘制场景后用SwapBuffers交换缓冲区。在OnDestroy里释放DC和RC资源。这套源代码里如果没有任何OpenGL示例你也可以参考它的GDI例子自行延伸出OpenGL的初始化代码。基本思路是相通的——MFC只负责窗口外壳和消息管理底层绘图可以完全交给OpenGL。3.4 数据库、多线程与Socket等扩展模块这套源代码覆盖了MFC的很多扩展应用其中数据库、多线程、Socket是最常被问到的三个方向。数据库这块老书中通常用CRecordset类配合ODBC驱动连接Access或者SQL Server。代码模式是CDatabase db; db.OpenEx(_T(DSNMyDSN;UIDsa;PWD123;), CDatabase::openReadOnly); CRecordset rs(db); rs.Open(CRecordset::forwardOnly, _T(SELECT * FROM users)); while (!rs.IsEOF()) { CString name; rs.GetFieldValue(_T(name), name); ... rs.MoveNext(); }多线程这块MFC的CWinThread类和AfxBeginThread函数是老牌做法。注意关键点是在工作线程里不能直接操作UI控件必须通过PostMessage把数据传回主线程再由主线程的消息处理函数去更新控件。Socket这块CAsyncSocket类封装了异步网络通信在Windows消息循环里自动处理网络事件。对于简单的局域网通信或上位机与下位机通信来说这种模型比用原始Winsock更直观。这套源代码的价值在于把每个模块都做成了一个能编译运行的独立demo你在实际项目中遇到哪块需求直接去对应章节抄代码改成自己的业务逻辑即可。4. 实操过程与核心环节实现4.1 用VS2019完整跑通一套老工程下面以我的实际操作经历为例讲一下怎么把一个VC6时代的MFC工程搬到VS2019上编译运行。这套源码的“Chapter02_DialogDemo”就是典型的VC6工程。第一步用VS2019打开.dsp文件。VS会弹出一个转换向导提示你是否将其转换为新的.vcxproj格式。点击“确定”等待转换完成。第二步修改项目属性。右键项目→属性重点修改几个地方常规→平台工具集我选的是Visual Studio 2017 (v141)兼容性比v142更好。常规→字符集改为使用多字节字符集免得字符串报错。C/C→预处理器→预处理定义检查是否需要添加WIN32_LEAN_AND_MEAN、_AFXDLL等宏。链接器→输入→附加依赖项老代码可能会用到Winmm.lib之类的库如果报链接错误就手动添加。第三步生成解决方案。这时候大概率会报一堆错误最常见的包括fatal error C1189: #error: Building MFC application with /MD[d] (CRT dll version) requires MFC shared dll version. Please define _AFXDLL or do not use /MD[d]这个错误在项目属性→配置属性→C/C→代码生成→运行库里把多线程调试 (/MTd)改成多线程调试DLL (/MDd)。一堆cannot convert from const char * to LPCWSTR这是字符集问题先确认是不是改到了多字节字符集。链接错误unresolved external symbol通常是因为缺少某个库或者某个函数在新版本SDK里改名了。需要逐个排查。第四步如果转换失败或者报错太多还有一个曲线救国的办法——直接新建一个MFC对话框工程把源码里的.h和.cpp文件拷贝进去替代自动生成的那些文件。这是我在处理极度老旧代码时的常用手段比硬啃转换要快得多。4.2 模拟一个日志记录功能模块既然命名为“精通”我们就从基础实操开始实现一个日志模块。这个模块在源代码里可能不完整但完全可以自己扩展。实现思路是封装一个CLog类提供WriteLog静态方法把文本追加写入指定日志文件。class CLog { public: static void WriteLog(const CString strLog) { CString strPath GetLogFilePath(); CStdioFile file; if (file.Open(strPath, CFile::modeCreate | CFile::modeNoTruncate | CFile::modeWrite)) { file.SeekToEnd(); file.WriteString(strLog _T(\r\n)); file.Close(); } } static CString GetLogFilePath() { CString strPath; GetModuleFileName(NULL, strPath.GetBuffer(MAX_PATH), MAX_PATH); strPath.ReleaseBuffer(); int nPos strPath.ReverseFind(_T(\\)); if (nPos 0) strPath strPath.Left(nPos 1) _T(app.log); return strPath; } };使用时直接调用CLog::WriteLog(_T(用户点击了登录按钮))。日志文件会生成在exe同目录下的app.log中。这个模块虽小但它展示了一个重要思想公共基础模块要从业务模块中解耦出来。在整套源代码的Common文件夹里这种思想贯穿始终。4.3 实战MFC对话框程序怎么打包发布热词里有一个很实际的问题——“mfc项目如何打包”。很多人在Debug模式下跑通了程序但把exe拷到别的电脑上一打开就报“缺少dll”。这是因为MFC程序依赖了MFC运行库和C运行库。推荐两种打包方式。第一种是在项目属性里选择“在静态库中使用MFC”使用 MFC 静态库这样MFC运行库会被直接静态链接进exe目标机器不需要安装任何运行库。缺点是可执行文件体积会变大通常多出几MB但对于内部工具来说完全没问题。第二种方式是打包安装程序常用工具是Inno Setup或者NSIS。在编译Release版本时确保项目属性→常规→MFC的使用选为“在共享DLL中使用MFC”然后在打包脚本里加上C:\Windows\System32\mfc140u.dll、msvcp140.dll、vcruntime140.dll等运行库文件。我自己做内部工具时更倾向静态链接因为简单直接——拷贝一个exe就能用不依赖目标机器环境。但要记住使用静态MFC后程序的安装包会变大启动速度可能略慢具体取舍还是要看使用场景。4.4 控件自适应屏幕分辨率“mfc 控件自适应屏幕分辨率”这个问题常被提到因为MFC对话框默认是固定尺寸的但高DPI显示器和不同分辨率会打乱布局。简单靠谱的方案是在对话框的OnSize里等比缩放所有控件。实现思路记录初始对话框尺寸和每个控件的初始位置。重写OnSize根据当前尺寸和初始尺寸的比例遍历控件并调整位置和大小。保存初始位置时用GetWindowRect拿到屏幕坐标再ScreenToClient转换成窗口客户区坐标。核心代码类似void CMyDialog::OnSize(UINT nType, int cx, int cy) { CDialogEx::OnSize(nType, cx, cy); if (m_bInitialized m_nOldCx ! 0) { double fRatioX (double)cx / m_nOldCx; double fRatioY (double)cy / m_nOldCy; CRect rect; CWnd* pWnd GetDlgItem(IDC_BUTTON_OK); if (pWnd) { pWnd-GetWindowRect(rect); ScreenToClient(rect); rect.left (int)(rect.left * fRatioX); rect.top (int)(rect.top * fRatioY); rect.right (int)(rect.right * fRatioX); rect.bottom (int)(rect.bottom * fRatioY); pWnd-MoveWindow(rect); } } }这种方法虽然简单但不适合非常复杂的界面。如果界面控件特别多建议采用布局管理的方式或者手动设计缩放规则否则会出现控件重叠、比例失调等问题。5. 常见问题与排查技巧实录5.1 编译报错对症速查表我在跑这套源代码的过程中遇到过的典型编译错误和解决办法整理成了一张速查表报错信息原因解决办法fatal error C1189: #error : Building MFC application with /MD[d] ...运行库设置与MFC使用方式不匹配运行库选择多线程调试DLL (/MDd)或多线程 (/MD)同时确认项目属性里是共享MFCcannot convert from const char * to LPCWSTR字符集是Unicode代码使用ANSI字符串项目属性改字符集为多字节或代码统一改为TCHAR、L...unresolved external symbol缺少链接库或函数名不匹配在属性→链接器→输入里补库检查#pragma comment(lib, ...)fatal error C1083: Cannot open include file: afxwin.h项目类型不是MFC工程或MFC头文件路径未配置确认项目使用MFC支持安装VS的MFC组件VS Installer里勾选“适用于最新v142生成工具的C MFC(x86/x64)”)error C3861: GetBuffer: identifier not found使用了VS6的旧API或被宏覆盖查文档替换为新API提示VS2019/2022安装时默认不会装MFC组件需要打开Visual Studio Installer在“单个组件”里勾选MFC相关的包。很多人第一次打开MFC工程直接报找不到afxwin.h就是这个原因。5.2 程序运行崩溃的常见原因编译通过了不代表能运行MFC程序运行期崩溃最常见的原因有几个。一是没有调用初始化函数。比如创建窗口前忘了AfxOleInit()或者对话框初始化资源时忘了AfxEnableControlContainer()都会导致控件或OLE功能崩溃。二是控件ID不存在。代码里用了GetDlgItem(IDC_MY_BUTTON)但对话框资源文件.rc里根本没有这个ID。这种问题在旧代码里最常见——.rc文件是文本格式如果之前有人手工编辑过IDC宏和控件ID对不上运行时就会返回空指针继续操作就崩溃了。三是窗口句柄失效。MFC中控件对象比如CButton变量绑定的HWND在窗口重建后可能变成无效状态。需要用SubclassDlgItem重新绑定或者每次都通过GetDlgItem获取新句柄。四是线程操作UI。工作线程里直接调用SetDlgItemText这在MFC里是禁忌。正确做法是用PostMessage发送自定义消息让主线程去更新UI。5.3 老代码Incompatible Data的坑有时候你打开一个老工程会看到sln文件显示不兼容版本警告“此项目需要MSVC xxx工具集但是当前已安装”。这种问题往往不是代码问题而是IDE版本导致的。我的处理方式是不要打开原始的.dsp而是用VS的“打开项目”里选择“打开旧工程转换”的选项让它生成一个新的.vcxproj。转换之后原始工程仍然保留你可以在新旧之间对比差异。如果转换过程报“项目文件格式不受支持”那说明这个工程太老了VS6以前。那就老老实实新建工程然后用“添加现有文件”的方式把代码全部加入。虽然麻烦一点但能避开所有工程文件格式兼容性问题。5.4 一个实际踩坑案例字符集引发的数据库乱码我印象最深的一次是接手一个老MFC程序与MySQL数据库对接的模块。代码里用的全是char*字符串和CString数据库接口返回的数据也是char*。程序在我本机跑得好好的换到一台默认环境是Unicode字符集的项目机器上乱码。排查过程先看数据库驱动的字符集设置没问题再看代码初始化的mysql_options设置也没问题。最后发现问题出在MFC工程属性里的“字符集”选项——那个机器上的工程被某人改成了Unicode导致CString内部是宽字符而数据库API用的是UTF-8字节流。两边不匹配自然乱码。解决方法是用WideCharToMultiByte和MultiByteToWideChar做显式转换或者统一把所有字符串接口都用std::string和std::wstring做一次封装从根上避免依赖CString的隐式转换。这个问题后来固化成了一个原则只要MFC程序要和非MFC库打交道一律在边界处做显式的字符编码转换不要把转换交给系统默认行为。5.5 调试技巧用输出窗口定位崩溃点最后分享一个非常实用的调试技巧。MFC程序崩溃时光靠弹窗很难定位问题。我习惯在程序里加这样一个全局异常钩子把崩溃时的调用栈输出到调试窗口或者日志文件LONG WINAPI MyUnhandledFilter(struct _EXCEPTION_POINTERS* pExceptionInfo) { // 记录异常码和地址 CString strLog; strLog.Format(_T(Exception Code: 0x%08X\r\nException Address: 0x%p\r\n), pExceptionInfo-ExceptionRecord-ExceptionCode, pExceptionInfo-ExceptionRecord-ExceptionAddress); CLog::WriteLog(strLog); return EXCEPTION_EXECUTE_HANDLER; } // 在InitInstance里设置 SetUnhandledExceptionFilter(MyUnhandledFilter);这样程序崩溃时即使没有调试器附加也能留下日志便于后续分析。MFC程序结构的复杂度决定了善用日志和异常钩子比单步调试更高效尤其是线上反馈问题的时候。6. 回顾与扩展方向这套“精通MFC源代码”给我最大的感受是它的价值不只是教会你某个API怎么用而是展示了MFC项目从零到一的组织结构。你从中可以学到如何划分模块、如何组织消息映射、如何把GDI绘图、数据库、网络这些不同领域的代码组合进一个完整的应用程序里。这种整体架构能力恰恰是很多碎片化学习很难获得的。我个人在实际操作中的一个深刻体会是学MFC别死记硬背每一个函数先把“窗口创建→消息分发→资源管理→控件交互”这条主线吃透剩下的都是沿着主线延伸的分支。我最初花了两周看不明白的消息映射在真正理解了“宏展开成一个函数指针数组”这个本质之后瞬间通透。如果你手头正好有这套源代码我的建议是别着急把每个例子都编译一遍而是挑三个典型项目好好研究一个对话框程序掌握控件交互、一个文档视图程序掌握数据与界面分离、一个带数据库或者Socket通信的程序掌握如何集成外部库。把这三个吃透你再去看MFC项目基本不会慌。后续还可以沿着这套代码做扩展比如给它增加自定义控件皮肤、接入OpenGL渲染、把数据库模块换成MySQL驱动——每一步改动都是在把“精通MFC”从口号变成真本事。最后再分享一个小技巧如果代码里某个类看不懂直接用VS的类视图ClassView看整个继承关系图。MFC的类层级虽然深但把继承关系列出来之后很多行为都变得清晰了。至少要清楚地知道CWinApp、CDialog、CView各自动态创建和初始化发生在哪个环节排查问题时你会感谢这个习惯。本文还有配套的精品资源点击获取
MFC源代码实战：工程结构、消息映射与编译排坑指南
简介《精通MFC》光盘配套源代码是学习MFC与Windows C编程的实用参考包。资源按原书第116章组织内容覆盖非常系统从面向对象与UML基础到窗口消息机制、MFC应用框架、消息映射与处理、对话框含通用对话框和HTML对话框、文档/视图结构、GDI/GDI绘图、进程与线程、动态链接库、COM组件编程以及.NET托管扩展。每个章节均配有可直接编译运行的示例工程读者可对照书本逐章调试观察MFC类库内部如何完成窗口创建、消息分发、序列化、绘图和组件聚合等关键机制特别适合有一定C基础、正在系统学习Windows程序设计的开发者。压缩包共1114个文件以h/cpp源代码、vcproj/sln工程文件、rc资源文件为主其中的头文件和实现文件对应各章示例代码工程文件用于Visual Studio打开和编译RC/RC2定义了界面资源配合ico、bmp等图标位图完整还原原书配套开发环境。整体仅8.01MB目录结构清晰便于按章节索引。目前已有513人学习下载是一份经典MFC教材的配套实战资料。1. 项目概述这套MFC源代码到底是什么“精通MFC光盘源代码”这个标题看起来就像你从某个旧书摊或者网盘里翻出来的压缩包。拆开之后里面是一整套VC工程文件对应的是《精通MFC》那本书随书光盘里的源码。书是很多年前出的但代码本身并没有过时——MFC作为Windows桌面开发的老牌框架至今仍然在工业软件、工控上位机、内部工具等场景里大量存活着。这套源代码的价值不在于“它有多新”而在于它几乎涵盖了MFC从入门到进阶的经典案例对话框程序、文档视图架构、控件自定义、GDI绘图、数据库访问、多线程、Socket通信、ActiveX控件等等。换句话说你拿到的不只是几个demo而是一套可以按图索骥的学习路径。适合谁看两类人。第一类是刚接触Windows C开发、想搞清楚“MFC项目到底怎么组织”的同学第二类是工作中突然接手老项目、需要快速理解MFC工程结构的人。我自己属于后者当年接手一个十几年前的工控上位机项目靠的就是把这种随书源码翻了个底朝天。有一点先说清楚所谓“精通”在实际代码里并不会给你什么黑魔法它更像是一个结构良好的代码仓库里面每个示例都在演示某个具体功能点的实现方式。用这本书配套源码学习最大的好处是——所有代码都能直接编译运行你不用像看零散博客那样猜头文件、猜宏定义。只要你装一个Visual StudioVS2013以上都行VS2015/2017/2019处理老工程的兼容性更好打开.sln文件基本都能直接跑起来。接下来我会从工程结构、核心原理、实操流程、坑点排查这几个维度把这套代码彻底吃透。不管你是要拿它学习还是想借鉴里面的代码去改造自己的项目这篇文章都能给你省下大量摸索时间。2. 工程整体设计与代码结构拆解2.1 随书光盘里的典型目录组织拿到这套源代码后你第一眼看到的往往是十几个文件夹每个文件夹对应书里的一个章节或一个完整例子。典型的目录结构大概是这样的Chapter02_DialogDemo Chapter03_ControlDemo Chapter04_DocumentView Chapter05_GDIDraw Chapter06_Database Chapter07_Thread Chapter08_Socket Chapter09_ActiveX ... Common这里面的Common文件夹很关键它存放的是多个示例公用的头文件和辅助类。为什么要单拆一个Common出来因为MFC项目里很多东西是可以复用的比如一个自定义的消息映射宏、一个通用的日志类、一个统一的文件路径处理函数。把公用代码抽出来每个示例只保留自己的核心逻辑整个代码仓库就会非常清爽。这也是老一代C工程师的习惯——他们写代码非常讲究模块复用几乎不会在一个项目里复制粘贴大段代码。每个章节内的工程通常是一个完整的Visual Studio解决方案文件.sln加一个项目文件夹。项目文件夹里常见的文件包括.dspVS6的工程文件、.dswVS6的工作区文件如果是高版本的VS还会有.vcxproj和.vcxproj.filters。这套源代码的年代跨度比较大从VC6到VS2010都有所以兼容性处理是学习过程中绕不开的一个话题。2.2 为什么用MFC而不直接用Win32 APIMFC本质上是对Windows API的一个C封装。它做的事情是把CreateWindow、RegisterClass、消息循环、窗口过程这些繁琐的原生API封装成了类和方法。你写Win32程序的时候要自己维护一个WndProc回调函数用switch-case处理各种WM_COMMAND、WM_PAINT消息而在MFC里你只需要继承一个CWinApp和CFrameWnd然后在消息映射宏里声明自己的处理函数即可。从这套源代码里你能明显感受到MFC设计的两个核心思路第一消息映射机制替代了传统的window procedure。MFC利用一组宏BEGIN_MESSAGE_MAP、ON_COMMAND、ON_BN_CLICKED等在编译阶段把消息和成员函数绑定起来。这样你不需要自己写switch-case也不需要手动维护函数指针表代码在视觉上清爽很多。第二文档/视图架构解决了数据与显示的分离问题。在Chapter04_DocumentView这类例子里你会看到CDocument负责数据读写CView负责界面显示。这种做法在数据量较大、视图类型多样比如同一个数据既要用表格显示又要用图表显示的场景下特别有优势。但注意MFC不是万能的。它的问题也很明显继承层级深、封装过度、调试困难。这套代码里的类很多光看类名就能绕晕人。我的建议是初学阶段不要试图理解每一个类的每一个方法先抓住消息流这条主线——窗口如何创建、消息如何分发、数据如何更新——把这条线理顺了其他的都是细枝末节。2.3 构建系统与编译环境的适配老工程源码最让人头疼的就是编译环境。这套代码里有一部分是VC6时代写的用的是老式的WIN32_LEAN_AND_MEAN、没有stdafx.h这种预编译头的概念VC6也有但命名习惯和现在不太一样。在新版Visual Studio里打开通常会遇到两类报错一是平台工具集不匹配。VS2019默认使用v142工具集VS6代码期望的是v60工具集。解决方法是选中项目右键→属性→常规→平台工具集改成Visual Studio 2015 (v140)或者Visual Studio 2017 (v141)或者干脆安装“VS2015工具集”兼容包。二是Unicode与ANSI编码冲突。老代码大量使用char*字符串而新版VS默认字符集是Unicode。你会看到一大堆cannot convert from const char * to LPCTSTR之类的报错。处理方法有两种要么在项目属性里把字符集改为“使用多字节字符集”要么老老实实把代码里的字符串和API都改成宽字符版本。前者快但不利于通用性后者工程量大但一劳永逸。我自己的经验是能改字符集就改字符集因为这套代码主要拿来学习和参考不是生产系统没必要花大量时间去适配Unicode。如果你确实需要在一个生产级项目里使用老MFC代码那就耐心做Unicode改造。3. 核心细节解析与实操要点3.1 消息映射宏的底层原理MFC消息映射是理解整套源代码的钥匙。你打开任何一个源文件几乎都能看到这样的结构BEGIN_MESSAGE_MAP(CMyDialog, CDialogEx) ON_WM_PAINT() ON_BN_CLICKED(IDC_BUTTON_OK, CMyDialog::OnBnClickedButtonOk) ON_COMMAND(ID_FILE_OPEN, CMyDialog::OnFileOpen) END_MESSAGE_MAP()这段代码到底干了什么本质上它在编译阶段被展开为一个静态数组数组里存放着消息编号、控件ID和成员函数指针的关系表。当操作系统把一个消息发给窗口时MFC会根据窗口类中的消息映射表查找到对应的处理函数然后调用它。相比传统的switch-case这种做法的好处是不同控件、不同命令各归其位代码扩展性更好。比如你新增一个菜单项只需要加一个ON_COMMAND宏和对应的成员函数编译器会帮你把一切连接好而不需要去动大的窗口过程函数。这里面有个容易踩的坑消息映射宏的顺序不是无关紧要的。MFC在查找消息处理时是按数组顺序逐个匹配的。一般来说ON_MESSAGE这种自定义消息处理宏和ON_BN_CLICKED放在一起没有问题但千万不要把两个能同时匹配同一消息的宏写重复或者前后顺序颠倒否则容易出现“消息被前面的宏截胡”的现象程序行为会变得诡异。3.2 控件的创建与自定义按钮的实现这套源代码里很多人最感兴趣的就是MFC自定义按钮的实现。MFC提供的CButton类本身就能显示按钮文本和处理点击消息但它长得太原生——没有圆角、没有渐变色、没有图标。要实现一个好看的自定义按钮通常有两条路自绘Owner-Draw和子类化Subclassing。自绘的思路是重写CButton的DrawItem函数把按钮的每一帧状态正常、悬停、按下、禁用都自己画出来。流程分几步在对话框上放一个普通Button设置它的Owner Draw属性。从CButton派生一个类CMyButton重写DrawItem。在DrawItem里根据按钮状态用CDC绘制填充背景、边框、文字甚至加载位图作为底图。子类化的思路是不改变按钮的绘制逻辑而是给按钮绑定一个新的窗口过程拦截它的WM_PAINT、WM_MOUSEMOVE等消息在原有绘制基础上叠加新效果。从这套源代码里你可以学到的是具体的GDI绘制API调用细节。比如void CMyButton::DrawItem(LPDRAWITEMSTRUCT lpDrawItemStruct) { CDC* pDC CDC::FromHandle(lpDrawItemStruct-hDC); CRect rect(lpDrawItemStruct-rcItem); UINT state lpDrawItemStruct-itemState; // 根据状态选择背景色 if (state ODS_SELECTED) pDC-FillSolidRect(rect, RGB(200, 200, 200)); else pDC-FillSolidRect(rect, RGB(240, 240, 240)); // 画文字 CString strText; GetWindowText(strText); pDC-SetTextColor(RGB(0, 0, 0)); pDC-SetBkMode(TRANSPARENT); pDC-DrawText(strText, rect, DT_CENTER | DT_VCENTER | DT_SINGLELINE); }这套代码的价值就在这些细节里FillSolidRect怎么用、DrawText的对齐标志怎么组合、ODS_SELECTED状态是从哪来的书里讲得清清楚楚。你照着改颜色、改边框样式就能做出自己品牌风格的自定义按钮。3.3 GDI绘图与OpenGL集成热词里出现了“基于mfc绘制一个彩色正方形”、“mfc opengl”这两个需求在源代码里都能找到参考。MFC里GDI绘图的核心是设备上下文DC所有画图都通过CDC类来完成。画一个彩色正方形核心代码无非是CBrush brush(RGB(255, 0, 0)); CPen pen(PS_SOLID, 2, RGB(0, 0, 255)); CClientDC dc(this); dc.SelectObject(brush); dc.SelectObject(pen); dc.Rectangle(50, 50, 200, 200); dc.SelectObject(brush); // 恢复原对象 dc.SelectObject(pen);这里有个必须注意的点选入DC的对象用完之后一定要恢复原状否则会资源泄漏。这套源代码里几乎每个绘图示例都遵守了这个规矩。至于MFC和OpenGL的结合思想也很清晰。你需要在一个MFC窗口上创建OpenGL渲染上下文HGLRC思路是在窗口的OnCreate里设置窗口样式为WS_CLIPCHILDREN | WS_CLIPSIBLINGS并调用SetPixelFormat和wglCreateContext。在OnPaint或者专门的渲染循环里用wglMakeCurrent切换到当前线程的OpenGL上下文。调用OpenGL函数绘制场景后用SwapBuffers交换缓冲区。在OnDestroy里释放DC和RC资源。这套源代码里如果没有任何OpenGL示例你也可以参考它的GDI例子自行延伸出OpenGL的初始化代码。基本思路是相通的——MFC只负责窗口外壳和消息管理底层绘图可以完全交给OpenGL。3.4 数据库、多线程与Socket等扩展模块这套源代码覆盖了MFC的很多扩展应用其中数据库、多线程、Socket是最常被问到的三个方向。数据库这块老书中通常用CRecordset类配合ODBC驱动连接Access或者SQL Server。代码模式是CDatabase db; db.OpenEx(_T(DSNMyDSN;UIDsa;PWD123;), CDatabase::openReadOnly); CRecordset rs(db); rs.Open(CRecordset::forwardOnly, _T(SELECT * FROM users)); while (!rs.IsEOF()) { CString name; rs.GetFieldValue(_T(name), name); ... rs.MoveNext(); }多线程这块MFC的CWinThread类和AfxBeginThread函数是老牌做法。注意关键点是在工作线程里不能直接操作UI控件必须通过PostMessage把数据传回主线程再由主线程的消息处理函数去更新控件。Socket这块CAsyncSocket类封装了异步网络通信在Windows消息循环里自动处理网络事件。对于简单的局域网通信或上位机与下位机通信来说这种模型比用原始Winsock更直观。这套源代码的价值在于把每个模块都做成了一个能编译运行的独立demo你在实际项目中遇到哪块需求直接去对应章节抄代码改成自己的业务逻辑即可。4. 实操过程与核心环节实现4.1 用VS2019完整跑通一套老工程下面以我的实际操作经历为例讲一下怎么把一个VC6时代的MFC工程搬到VS2019上编译运行。这套源码的“Chapter02_DialogDemo”就是典型的VC6工程。第一步用VS2019打开.dsp文件。VS会弹出一个转换向导提示你是否将其转换为新的.vcxproj格式。点击“确定”等待转换完成。第二步修改项目属性。右键项目→属性重点修改几个地方常规→平台工具集我选的是Visual Studio 2017 (v141)兼容性比v142更好。常规→字符集改为使用多字节字符集免得字符串报错。C/C→预处理器→预处理定义检查是否需要添加WIN32_LEAN_AND_MEAN、_AFXDLL等宏。链接器→输入→附加依赖项老代码可能会用到Winmm.lib之类的库如果报链接错误就手动添加。第三步生成解决方案。这时候大概率会报一堆错误最常见的包括fatal error C1189: #error: Building MFC application with /MD[d] (CRT dll version) requires MFC shared dll version. Please define _AFXDLL or do not use /MD[d]这个错误在项目属性→配置属性→C/C→代码生成→运行库里把多线程调试 (/MTd)改成多线程调试DLL (/MDd)。一堆cannot convert from const char * to LPCWSTR这是字符集问题先确认是不是改到了多字节字符集。链接错误unresolved external symbol通常是因为缺少某个库或者某个函数在新版本SDK里改名了。需要逐个排查。第四步如果转换失败或者报错太多还有一个曲线救国的办法——直接新建一个MFC对话框工程把源码里的.h和.cpp文件拷贝进去替代自动生成的那些文件。这是我在处理极度老旧代码时的常用手段比硬啃转换要快得多。4.2 模拟一个日志记录功能模块既然命名为“精通”我们就从基础实操开始实现一个日志模块。这个模块在源代码里可能不完整但完全可以自己扩展。实现思路是封装一个CLog类提供WriteLog静态方法把文本追加写入指定日志文件。class CLog { public: static void WriteLog(const CString strLog) { CString strPath GetLogFilePath(); CStdioFile file; if (file.Open(strPath, CFile::modeCreate | CFile::modeNoTruncate | CFile::modeWrite)) { file.SeekToEnd(); file.WriteString(strLog _T(\r\n)); file.Close(); } } static CString GetLogFilePath() { CString strPath; GetModuleFileName(NULL, strPath.GetBuffer(MAX_PATH), MAX_PATH); strPath.ReleaseBuffer(); int nPos strPath.ReverseFind(_T(\\)); if (nPos 0) strPath strPath.Left(nPos 1) _T(app.log); return strPath; } };使用时直接调用CLog::WriteLog(_T(用户点击了登录按钮))。日志文件会生成在exe同目录下的app.log中。这个模块虽小但它展示了一个重要思想公共基础模块要从业务模块中解耦出来。在整套源代码的Common文件夹里这种思想贯穿始终。4.3 实战MFC对话框程序怎么打包发布热词里有一个很实际的问题——“mfc项目如何打包”。很多人在Debug模式下跑通了程序但把exe拷到别的电脑上一打开就报“缺少dll”。这是因为MFC程序依赖了MFC运行库和C运行库。推荐两种打包方式。第一种是在项目属性里选择“在静态库中使用MFC”使用 MFC 静态库这样MFC运行库会被直接静态链接进exe目标机器不需要安装任何运行库。缺点是可执行文件体积会变大通常多出几MB但对于内部工具来说完全没问题。第二种方式是打包安装程序常用工具是Inno Setup或者NSIS。在编译Release版本时确保项目属性→常规→MFC的使用选为“在共享DLL中使用MFC”然后在打包脚本里加上C:\Windows\System32\mfc140u.dll、msvcp140.dll、vcruntime140.dll等运行库文件。我自己做内部工具时更倾向静态链接因为简单直接——拷贝一个exe就能用不依赖目标机器环境。但要记住使用静态MFC后程序的安装包会变大启动速度可能略慢具体取舍还是要看使用场景。4.4 控件自适应屏幕分辨率“mfc 控件自适应屏幕分辨率”这个问题常被提到因为MFC对话框默认是固定尺寸的但高DPI显示器和不同分辨率会打乱布局。简单靠谱的方案是在对话框的OnSize里等比缩放所有控件。实现思路记录初始对话框尺寸和每个控件的初始位置。重写OnSize根据当前尺寸和初始尺寸的比例遍历控件并调整位置和大小。保存初始位置时用GetWindowRect拿到屏幕坐标再ScreenToClient转换成窗口客户区坐标。核心代码类似void CMyDialog::OnSize(UINT nType, int cx, int cy) { CDialogEx::OnSize(nType, cx, cy); if (m_bInitialized m_nOldCx ! 0) { double fRatioX (double)cx / m_nOldCx; double fRatioY (double)cy / m_nOldCy; CRect rect; CWnd* pWnd GetDlgItem(IDC_BUTTON_OK); if (pWnd) { pWnd-GetWindowRect(rect); ScreenToClient(rect); rect.left (int)(rect.left * fRatioX); rect.top (int)(rect.top * fRatioY); rect.right (int)(rect.right * fRatioX); rect.bottom (int)(rect.bottom * fRatioY); pWnd-MoveWindow(rect); } } }这种方法虽然简单但不适合非常复杂的界面。如果界面控件特别多建议采用布局管理的方式或者手动设计缩放规则否则会出现控件重叠、比例失调等问题。5. 常见问题与排查技巧实录5.1 编译报错对症速查表我在跑这套源代码的过程中遇到过的典型编译错误和解决办法整理成了一张速查表报错信息原因解决办法fatal error C1189: #error : Building MFC application with /MD[d] ...运行库设置与MFC使用方式不匹配运行库选择多线程调试DLL (/MDd)或多线程 (/MD)同时确认项目属性里是共享MFCcannot convert from const char * to LPCWSTR字符集是Unicode代码使用ANSI字符串项目属性改字符集为多字节或代码统一改为TCHAR、L...unresolved external symbol缺少链接库或函数名不匹配在属性→链接器→输入里补库检查#pragma comment(lib, ...)fatal error C1083: Cannot open include file: afxwin.h项目类型不是MFC工程或MFC头文件路径未配置确认项目使用MFC支持安装VS的MFC组件VS Installer里勾选“适用于最新v142生成工具的C MFC(x86/x64)”)error C3861: GetBuffer: identifier not found使用了VS6的旧API或被宏覆盖查文档替换为新API提示VS2019/2022安装时默认不会装MFC组件需要打开Visual Studio Installer在“单个组件”里勾选MFC相关的包。很多人第一次打开MFC工程直接报找不到afxwin.h就是这个原因。5.2 程序运行崩溃的常见原因编译通过了不代表能运行MFC程序运行期崩溃最常见的原因有几个。一是没有调用初始化函数。比如创建窗口前忘了AfxOleInit()或者对话框初始化资源时忘了AfxEnableControlContainer()都会导致控件或OLE功能崩溃。二是控件ID不存在。代码里用了GetDlgItem(IDC_MY_BUTTON)但对话框资源文件.rc里根本没有这个ID。这种问题在旧代码里最常见——.rc文件是文本格式如果之前有人手工编辑过IDC宏和控件ID对不上运行时就会返回空指针继续操作就崩溃了。三是窗口句柄失效。MFC中控件对象比如CButton变量绑定的HWND在窗口重建后可能变成无效状态。需要用SubclassDlgItem重新绑定或者每次都通过GetDlgItem获取新句柄。四是线程操作UI。工作线程里直接调用SetDlgItemText这在MFC里是禁忌。正确做法是用PostMessage发送自定义消息让主线程去更新UI。5.3 老代码Incompatible Data的坑有时候你打开一个老工程会看到sln文件显示不兼容版本警告“此项目需要MSVC xxx工具集但是当前已安装”。这种问题往往不是代码问题而是IDE版本导致的。我的处理方式是不要打开原始的.dsp而是用VS的“打开项目”里选择“打开旧工程转换”的选项让它生成一个新的.vcxproj。转换之后原始工程仍然保留你可以在新旧之间对比差异。如果转换过程报“项目文件格式不受支持”那说明这个工程太老了VS6以前。那就老老实实新建工程然后用“添加现有文件”的方式把代码全部加入。虽然麻烦一点但能避开所有工程文件格式兼容性问题。5.4 一个实际踩坑案例字符集引发的数据库乱码我印象最深的一次是接手一个老MFC程序与MySQL数据库对接的模块。代码里用的全是char*字符串和CString数据库接口返回的数据也是char*。程序在我本机跑得好好的换到一台默认环境是Unicode字符集的项目机器上乱码。排查过程先看数据库驱动的字符集设置没问题再看代码初始化的mysql_options设置也没问题。最后发现问题出在MFC工程属性里的“字符集”选项——那个机器上的工程被某人改成了Unicode导致CString内部是宽字符而数据库API用的是UTF-8字节流。两边不匹配自然乱码。解决方法是用WideCharToMultiByte和MultiByteToWideChar做显式转换或者统一把所有字符串接口都用std::string和std::wstring做一次封装从根上避免依赖CString的隐式转换。这个问题后来固化成了一个原则只要MFC程序要和非MFC库打交道一律在边界处做显式的字符编码转换不要把转换交给系统默认行为。5.5 调试技巧用输出窗口定位崩溃点最后分享一个非常实用的调试技巧。MFC程序崩溃时光靠弹窗很难定位问题。我习惯在程序里加这样一个全局异常钩子把崩溃时的调用栈输出到调试窗口或者日志文件LONG WINAPI MyUnhandledFilter(struct _EXCEPTION_POINTERS* pExceptionInfo) { // 记录异常码和地址 CString strLog; strLog.Format(_T(Exception Code: 0x%08X\r\nException Address: 0x%p\r\n), pExceptionInfo-ExceptionRecord-ExceptionCode, pExceptionInfo-ExceptionRecord-ExceptionAddress); CLog::WriteLog(strLog); return EXCEPTION_EXECUTE_HANDLER; } // 在InitInstance里设置 SetUnhandledExceptionFilter(MyUnhandledFilter);这样程序崩溃时即使没有调试器附加也能留下日志便于后续分析。MFC程序结构的复杂度决定了善用日志和异常钩子比单步调试更高效尤其是线上反馈问题的时候。6. 回顾与扩展方向这套“精通MFC源代码”给我最大的感受是它的价值不只是教会你某个API怎么用而是展示了MFC项目从零到一的组织结构。你从中可以学到如何划分模块、如何组织消息映射、如何把GDI绘图、数据库、网络这些不同领域的代码组合进一个完整的应用程序里。这种整体架构能力恰恰是很多碎片化学习很难获得的。我个人在实际操作中的一个深刻体会是学MFC别死记硬背每一个函数先把“窗口创建→消息分发→资源管理→控件交互”这条主线吃透剩下的都是沿着主线延伸的分支。我最初花了两周看不明白的消息映射在真正理解了“宏展开成一个函数指针数组”这个本质之后瞬间通透。如果你手头正好有这套源代码我的建议是别着急把每个例子都编译一遍而是挑三个典型项目好好研究一个对话框程序掌握控件交互、一个文档视图程序掌握数据与界面分离、一个带数据库或者Socket通信的程序掌握如何集成外部库。把这三个吃透你再去看MFC项目基本不会慌。后续还可以沿着这套代码做扩展比如给它增加自定义控件皮肤、接入OpenGL渲染、把数据库模块换成MySQL驱动——每一步改动都是在把“精通MFC”从口号变成真本事。最后再分享一个小技巧如果代码里某个类看不懂直接用VS的类视图ClassView看整个继承关系图。MFC的类层级虽然深但把继承关系列出来之后很多行为都变得清晰了。至少要清楚地知道CWinApp、CDialog、CView各自动态创建和初始化发生在哪个环节排查问题时你会感谢这个习惯。本文还有配套的精品资源点击获取
到《DOOM 64》恶搞Mod：AI安全风险如何变成一场游戏)
