简介：这份资源面向学习 C++ 与 MFC 的初学者及课程设计需求者，提供一套基于对话框的 VC++6.0 计算器完整工程，用于解决 Windows 桌面编程入门时缺少可运行范例的问题。压缩包共 32 个文件、约 3.66MB，包含 4 个 h 头文件与 3 个 cpp 源文件承载界面与逻辑代码，另有 dsp、dsw 工程配置、rc 资源脚本与 ico 图标、exe 可执行程序及 Debug 目录下的 obj、pdb 等编译中间文件，可直接打开工程编译调试。功能上覆盖加减乘除四则运算、带括号的表达式求值、对数与幂函数、三角函数及反三角函数，并支持 8、16、10、2 进制相互转换，读者可借此理解对话框控件绑定、消息响应与运算逻辑分层组织。目前已有 1892 人学习下载，适合对照源码拆解 MFC 工程结构、完成课程作业或二次扩展。

1. 一个老掉牙的 VC++6.0 计算器，为什么还值得拆

上周有个做工业上位机的朋友发来一个压缩包，说客户现场一台老设备只认 VC++6.0 编译出来的程序，新版本工具链跑不起来，问我能不能把里面的 MFC 计算器逻辑理清楚再改。我打开一看，典型的课程设计产物：一个对话框程序，按钮排成九宫格，编辑框显示结果，代码量不大，但把 MFC 的消息映射、控件操作、字符串转换这几件事全串起来了。这类资源在网上流传很广，名字通常就叫「VC++6.0开发MFC简单计算器.rar」，解压后是一个 .dsw 工程加若干 .cpp/.h 文件。

它解决的不是「算 1+1」的问题，而是让你在一个真实可编译的 MFC 对话框工程里，看清按钮点击怎么走到响应函数、编辑框内容怎么读写、CString 和 double 怎么互转。适合两类人：一是要维护老工控项目、被迫回到 VC++6.0 的从业者；二是刚接触 MFC、需要一个小而完整工程练手的开发者。下面按「工程结构 → 消息映射 → 运算逻辑 → 踩坑」的顺序拆，能直接照着复现。

2. 工程结构与消息映射：按钮点下去之后发生了什么

2.1 解压后先认文件，别急着编译

拿到压缩包，解压出来一般能看到这些文件，先对照一遍再动手：

VC++6.0 的工程文件是文本格式，用记事本打开 .dsp 能看到SOURCE=和HEADER=行。如果解压后路径变了导致编译报「找不到文件」，不用重建工程，直接改 .dsp 里的相对路径，或者把整个目录放到不含中文和空格的路径下——这一点很关键，VC++6.0 对中文路径的兼容性差，血泪经验是路径里只要有空格或汉字，编译中途就可能报一堆莫名其妙的错。

打开 .dsw 后，左侧 FileView 里能看到 Source Files、Header Files、Resource Files 三组。双击 .rc 进入资源编辑器，能看到对话框上排着按钮和编辑框。每个控件在 Resource.h 里有一个#define IDC_XXX 1000这样的宏，这个 ID 就是后面消息映射的钥匙。

2.2 消息映射表：MFC 和 Win32 的分水岭

MFC 不像 Win32 那样在 WndProc 里写一个大 switch，而是用消息映射宏把「控件 ID + 通知码」映射到成员函数。在 CalcDlg.h 的类声明里能看到：

// CalcDlg.h 片段 protected: // 生成的消息映射函数 afx_msg void OnButtonDigit(); // 数字键 0-9 共用 afx_msg void OnButtonOperator(); // + - * / 共用 afx_msg void OnButtonEqual(); // = afx_msg void OnButtonClear(); // C DECLARE_MESSAGE_MAP()

对应的 .cpp 里是这张表：

// CalcDlg.cpp 片段 BEGIN_MESSAGE_MAP(CCalcDlg, CDialog) ON_BN_CLICKED(IDC_BTN_0, OnButtonDigit) ON_BN_CLICKED(IDC_BTN_1, OnButtonDigit) // ... 2-9 同理 ON_BN_CLICKED(IDC_BTN_ADD, OnButtonOperator) ON_BN_CLICKED(IDC_BTN_SUB, OnButtonOperator) ON_BN_CLICKED(IDC_BTN_MUL, OnButtonOperator) ON_BN_CLICKED(IDC_BTN_DIV, OnButtonOperator) ON_BN_CLICKED(IDC_BTN_EQ, OnButtonEqual) ON_BN_CLICKED(IDC_BTN_CLR, OnButtonClear) END_MESSAGE_MAP()

ON_BN_CLICKED的第一个参数是控件 ID，第二个是响应函数名。多个按钮映射到同一个函数是允许的，函数里用GetCurrentMessage()或GetFocus()反查是哪个按钮触发的。这里有个容易翻车的点：如果资源编辑器里改了按钮 ID，但消息映射表没同步改，编译能过，运行时点按钮毫无反应——因为消息发出来找不到接收者，MFC 直接忽略。排查方法是在响应函数第一行下断点，点按钮看断不断得住，断不住就是映射没对上。

2.3 控件 ID 与响应函数的绑定验证

改完映射后，建议做一次最小验证：在OnButtonDigit里加一行AfxMessageBox(_T("hit"));，编译运行，点任意数字键看弹不弹框。弹了说明映射通了，再把弹框删掉写真实逻辑。这个习惯能省掉大量「到底是映射错了还是逻辑错了」的扯皮。VC++6.0 的调试器虽然老，但 F9 下断点、F5 启动调试、Alt+5 看变量窗口这套流程是完整的，够用。

3. 运算逻辑落地：CString 与 double 的来回转换

3.1 编辑框读写与状态机设计

计算器的核心不是四则运算本身，而是「当前输入到哪一步」的状态管理。常见做法是用三个成员变量：CString m_strInput存当前输入串，double m_dOperand存上一个操作数，TCHAR m_cPendingOp存待执行的运算符。编辑框通过DDX_Text或手动GetDlgItemText读写。

// 数字键响应：追加到当前输入串 void CCalcDlg::OnButtonDigit() { // 反查是哪个按钮触发的 UINT nID = GetCurrentMessage()->wParam; CString strDigit; strDigit.Format(_T("%d"), nID - IDC_BTN_0); // ID 连续时可直接算 // 若当前显示为 0 且不是输入小数点，先清掉 if (m_strInput == _T("0")) m_strInput = strDigit; else m_strInput += strDigit; SetDlgItemText(IDC_EDIT_DISPLAY, m_strInput); }

这段的关键在nID - IDC_BTN_0：前提是资源里 0-9 十个按钮的 ID 是连续分配的。如果 ID 不连续，就得写 switch 或者查表。参数说明：GetCurrentMessage()->wParam在 BN_CLICKED 通知下就是控件 ID，这是 MFC 的约定，不是玄学。SetDlgItemText直接刷新编辑框，不走 DDX，适合这种高频更新场景。

3.2 运算符与等号：把字符串转成数值

运算符响应要做三件事：把当前输入串转成 double 存进m_dOperand，记下运算符，清空输入准备接收下一个数。等号响应则把第二个操作数转出来，按m_cPendingOp分派计算。

// 等号响应：执行运算并显示结果 void CCalcDlg::OnButtonEqual() { double dSecond = _ttof(m_strInput); // CString -> double double dResult = 0.0; switch (m_cPendingOp) { case _T('+'): dResult = m_dOperand + dSecond; break; case _T('-'): dResult = m_dOperand - dSecond; break; case _T('*'): dResult = m_dOperand * dSecond; break; case _T('/'): if (dSecond == 0.0) // 除零必须拦 { AfxMessageBox(_T("除数不能为零")); return; } dResult = m_dOperand / dSecond; break; default: return; // 没有待执行运算符，直接返回 } m_strInput.Format(_T("%g"), dResult); // double -> CString SetDlgItemText(IDC_EDIT_DISPLAY, m_strInput); m_dOperand = dResult; // 支持连续运算 m_cPendingOp = 0; }

_ttof是 TCHAR 版本的字符串转浮点，对应atof的宽字符版。用%g而不是%f是为了去掉多余的尾零，否则 3.0 会显示成 3.000000，观感很差。除零判断必须放在除法之前，浮点除零在 C++ 里不抛异常，会得到 inf 或 nan，直接显示到编辑框里用户会以为程序坏了。m_dOperand = dResult这一行让等号之后可以接着按运算符继续算，是连续运算的关键，漏了它就只能算一步。

3.3 清空与边界：小数点、负号、重复按等号

清空键把三个状态变量全部复位，编辑框显示 0。小数点要单独处理：如果当前输入串里已经有.，再按就忽略，否则会出现1.2.3这种非法串，_ttof转换时只认前面一段，结果静默出错。负号的处理有两种做法，一种是在输入阶段允许前导-，另一种是提供正负号切换按钮，后者更稳，因为_ttof对-开头的串支持没问题，但用户连按两个负号就乱了。

重复按等号的行为也要定：常见做法是重复上一次运算，即m_dOperand保持为结果、m_cPendingOp不清零。如果按上面的代码清了m_cPendingOp，再按等号会走 default 分支直接返回，表现为「按了没反应」。两种行为都有人用，但要在代码里明确选一种，别让用户猜。

4. 避坑与排查：VC++6.0 上最容易翻车的五件事

4.1 编译报一堆语法错，但代码看着没问题

现象：打开工程直接 F7 编译，报几十个错，指向标准头文件。原因：VC++6.0 默认的包含路径和库路径可能被系统里其他版本的 SDK 污染，或者工程是从别的机器拷来的，路径写死。解决：Tools → Options → Directories 里检查 Include files 和 Library files，把 VC98 自带的路径放最前面；工程设置里 Project → Settings → C/C++ 的 Preprocessor 也确认没有残留的绝对路径。最省事的办法是新建一个空工程，把 .cpp/.h/.rc 加进去，绕开旧工程配置。

4.2 按钮点了没反应

现象：程序能跑，界面正常，点按钮编辑框不变。原因：消息映射表里的 ID 和资源里的 ID 对不上，或者响应函数忘了在 .h 里声明afx_msg。解决：对照 Resource.h 里的#define和BEGIN_MESSAGE_MAP里的宏，逐个核对；在响应函数首行下断点验证是否进入。注意afx_msg前缀漏写时，VC++6.0 有时不报错但映射失效，属于黑匣子级别的坑。

4.3 中文显示成乱码

现象：AfxMessageBox或编辑框里的中文变成问号或方块。原因：VC++6.0 默认按多字节字符集编译，源文件如果存成 UTF-8，中文字符串会被错误解析。解决：源文件另存为 ANSI 编码，或者在 Project → Settings → C/C++ 的 Preprocessor 里加_MBCS，字符串统一用_T("...")包裹。别在 VC++6.0 里用 UTF-8 源文件，这是反复踩的坑。

4.4 浮点结果显示一长串小数

现象：算 0.1+0.2 显示 0.30000000000000004。原因：%f默认六位小数加上 double 的二进制表示误差。解决：显示用%g或%.10g，按有效数字截断；如果业务要求精确到分，运算前先乘 100 转整数算完再除回去，别指望浮点直接相等比较。

4.5 换台机器就编译不过

现象：本机好好的，拷到客户现场或同事机器上报错。原因：工程里引用了本机绝对路径的头文件，或者依赖了某个没随包带的库。解决：把工程目录整体拷贝，检查 .dsp 里所有路径是否为相对路径；用「全部重建」而不是「增量编译」验证一遍。VC++6.0 的增量编译在文件时间戳异常时会跳过该编的文件，导致行为诡异，全部重建能排除这类干扰。

5. 进阶：把这个 Demo 改成能用的工程计算器

拆完基础逻辑，真正让它「能用」还差几步。第一是把单步运算改成带优先级的表达式求值，简单做法是引入两个栈（操作数栈、运算符栈），按优先级弹栈计算，代码量大概多一百行，但能正确处理2+3*4。第二是加键盘支持，重写PreTranslateMessage拦截数字键和回车，让用户不用鼠标也能算，工控场景里这个需求很实际。

// 键盘支持：在对话框类里重写 BOOL CCalcDlg::PreTranslateMessage(MSG* pMsg) { if (pMsg->message == WM_KEYDOWN) { if (pMsg->wParam >= '0' && pMsg->wParam <= '9') { OnButtonDigit(); // 复用已有逻辑 return TRUE; // 吞掉消息，不再分发 } if (pMsg->wParam == VK_RETURN) { OnButtonEqual(); return TRUE; } } return CDialog::PreTranslateMessage(pMsg); }

return TRUE表示消息已处理，不再往下传，漏了它会导致按键被处理两次。第三是结果精度和溢出，工业场景里经常要算大数，double 的有效位是 15-16 位，超过就得换long double或者定点数方案，这一点在改之前就要和需求方确认清楚，别等上线了才发现精度不够。

验证方法很简单：准备一组边界用例——除零、连续运算、小数点重复输入、超长数字、负数乘除——逐条跑一遍，每条都对照预期结果。我一般会在改完后把这几条写成注释贴在OnButtonEqual上方，下次维护的人一眼能看到边界在哪。从那以后我每次接手这类老工程，都强制先把消息映射和边界用例走一遍再动业务代码，省下来的返工时间远比这一步多。希望帮到你。

本文还有配套的精品资源，点击获取