企业官网建设流程全解析

1. MFC对话框到底是什么：先把概念和场景理清楚

聊MFC对话框这个话题，我总觉得得先泼一盆冷水——现在新项目基本没人从零开始用MFC了，但只要你还在维护老代码、还在给工控设备写上位机、还在做实验室里那些跑了好多年的数据采集软件，那对话框这块就绕不过去。我自己这几年经手的几个项目，全是基于MFC的存量代码，对话框数量动辄几十个，改起来是真的能让人加班到凌晨。所以这篇东西不是写给新手的入门课，而是把我这些年踩过的坑、总结出来的套路一次性倒出来，谁在维护MFC代码谁就能直接抄。

先把概念说清楚。MFC里的对话框，本质就是一个从CDialog（新版一般是CDialogEx）派生出来的窗口类，它有两种形态：模态对话框和非模态对话框。模态对话框弹出之后，用户必须先关掉它才能操作主窗口，典型场景就是"关于"对话框、登录框、参数设置框；非模态对话框则可以和主窗口并存，边看边改，典型场景是查找替换面板、工具选项板、调试信息窗口。这个区分不是象牙塔里的术语游戏，它直接决定了你后面代码怎么写、内存怎么管、销毁怎么处理。

对话框在MFC程序里承担的角色，说白了就是人机交互的载体，它负责把用户输入收集起来，交给业务逻辑处理。一个设计良好的对话框，你看一眼资源视图里的控件ID就能大致猜到它是干嘛的；而一个设计糟糕的对话框，控件堆得像菜市场，ID全是IDC_STATIC2、IDC_BUTTON17这种，接手的人得一处处diff才能理清逻辑。这两种极端我都见过，所以后面我会专门讲命名规范这块，别看它不起眼，能省掉后期大量的沟通成本。

适合谁来读这篇？如果你正面对一个老工程，需要往里面加对话框、改对话框逻辑，或者你想搞清楚DDX、消息映射这些机制背后的逻辑，那正好对味。如果你是完全没接触过Windows编程的纯新手，前面的概念部分也能看懂，但实操部分建议你先建个空白工程跟着敲一遍，光看是看不出问题的。

2. 工程与资源准备：动手前的那些固定动作

2.1 建立基于对话框的工程骨架

很多人一上来就纠结Visual Studio的版本，我用过VS2010、VS2015、VS2019、VS2022，结论是：只要你的工程是标准的MFC工程，版本差异对对话框本身的影响有限，主要差别在MFC库版本和C++标准支持上。不过有个现实问题得提醒你，VS2019之后新建MFC项目的向导把MFC库的勾选项做得很隐蔽，你得在"高级功能"里把MFC的使用改成"在共享DLL中使用MFC"或者"在静态库中使用MFC"，否则编出来的程序在没装运行库的机器上直接起不来。

新建向导里有个关键选择：应用程序类型选"基于对话框"。这会给你生成一个带App类和主对话框类的骨架。但这个骨架只是起点，真正的项目里主对话框往往只做壳，功能对话框都是后来一个个加进去的。我个人的习惯是，不管项目多小，都会先规划好对话框的父子层级，避免后面出现"子对话框找不到父窗口"这种低级问题。

这里插一句关于静态库链接和共享DLL链接的选择。共享DLL出来的EXE小，但目标机得装MFC运行库；静态库出来的EXE大，但可以直接拷走用。给现场设备做上位机的时候我一律选静态库，因为现场那台电脑你根本不知道装了什么，少一个依赖就少一个技术支持电话。这个取舍在项目初期就要定，后期想改的话整个工程的编译选项、依赖库路径都得跟着动，很麻烦。

2.2 资源编辑器里加控件与命名规范

资源视图（Resource View）里的Dialog Editor是加控件的主战场。工具箱拖一个Button进去，默认ID是IDC_BUTTON1，Caption是"Button1"。我强烈建议你养成两个习惯：第一，改ID为有语义的名字；第二，Caption用中文或明确的英文。比如一个"开始采集"按钮，ID写成IDC_BTN_START_ACQ，Caption写成"开始采集"，半年后你自己回来改代码，一眼就知道这按钮干嘛的。

命名我一般遵循这套前缀规则，你可以直接拿去用：按钮用IDC_BTN_，编辑框用IDC_EDIT_，静态文本用IDC_STATIC_（如果不需要引用可以直接保持IDC_STATIC），组合框用IDC_CMB_，列表控件用IDC_LIST_，树控件用IDC_TREE_。至于对话框本身的ID，统一用IDD_前缀加功能名，比如IDD_DLG_SERIAL_CFG。这套规则在MFC圈子里算是个不成文的共识，接手的人基本不用猜。

提示：静态文本控件如果不需要在代码里引用，ID可以保持默认的IDC_STATIC，这样多个静态文本可以共用同一个ID。但一旦你需要动态改它的文字，比如显示状态，就必须给它一个唯一ID。

还有个小细节，资源编辑器里Tab键顺序默认是按你添加控件的顺序排的，往往跟视觉顺序不一致。运行起来用户按Tab跳来跳去，焦点乱飞，体验很差。可以在编辑器里按Ctrl+D进入Tab顺序编辑模式，用鼠标一个个点过去重新排，或者先在属性里调整。这个动作花不了两分钟，但能避免用户吐槽"这软件没法用键盘操作"。

2.3 控件ID与Tab顺序这些容易忽略的细节

除了ID和Tab顺序，还有几个属性值得在动手写代码前就设好。Group属性用于把一组单选按钮（Radio Button）归为一组，一组里的第一个按钮勾上Group，后面的不勾，这样MFC才知道这几个是互斥的。如果不设，可能出现两个单选按钮同时被选中的诡异现象。Visible和Disabled属性则提供了一种"懒"做法——把暂时用不到的控件隐藏而不是动态创建，代码写得快，代价是资源占用多一点。小规模界面无所谓，控件上百个的复杂对话框还是老老实实动态创建吧。

关于控件尺寸和字体，资源编辑器里默认用的是系统字体，在高DPI显示器上会出现对话框显示不全的情况——这也是为什么网上总有人问"扫描软件保存完对话框显示不全"。根源通常有两个：一是对话框模板本身没考虑缩放，二是程序没有声明DPI感知。MFC老工程很多都是按96 DPI设计的，在缩放150%的屏幕上，硬编码的像素尺寸就装不下内容了。解决办法要么在清单文件里声明DPI感知并做布局适配，要么把对话框属性设为可调整大小，让用户自己拖大一点。这块后面第5章还会细说。

3. 对话框类的三根支柱：生命周期、消息映射、数据交换

3.1 CDialog派生类的结构与生命周期

一个对话框类，去掉向导生成的那些样板代码，核心就三样东西：构造函数、DoDataExchange、消息映射。构造函数里通常什么都不做，或者只初始化一些非控件的成员变量。真正干活的是OnInitDialog，它在对话框创建后、显示前被调用，是你初始化控件内容的地方。

生命周期这块，模态和非模态差别很大，必须拎清楚。模态对话框调用DoModal()，这个函数会阻塞，直到对话框关闭才返回一个IDOK或IDCANCEL，意味着对话框对象的生命周期由调用栈自动管理，你在栈上创建一个对象然后DoModal就行。非模态对话框调用Create()，它立即返回，不阻塞，这就意味着对象必须用new分配在堆上，否则函数一返回对象就析构了，窗口还在但背后已经没有有效的C++对象，接下来的操作全是未定义行为。

// 模态：可以栈上创建 CSerialCfgDlg dlg; if (dlg.DoModal() == IDOK) { // 对话框关闭，数据已经通过UpdateData拿到成员变量里 int baud = dlg.m_nBaudRate; } // 非模态：必须堆上创建 CSerialCfgDlg* pDlg = new CSerialCfgDlg(this); pDlg->Create(IDD_DLG_SERIAL_CFG, this); pDlg->ShowWindow(SW_SHOW); // 注意：这里不要delete，delete的地方在PostNcDestroy

我见过太多人在非模态场景里，主窗口析构时忘了清理那些堆上的对话框，结果程序退出时一堆内存泄漏报告。也有反过来的，手动delete了非模态对话框对象，但用户还没关窗口，一点就崩。所以非模态对话框的销毁，标准做法是重写OnCancel和PostNcDestroy，在PostNcDestroy里delete this，让窗口的销毁和对象的销毁绑定在一起。

void CSerialCfgDlg::OnCancel() { DestroyWindow(); // 非模态对话框用DestroyWindow而不是EndDialog } void CSerialCfgDlg::PostNcDestroy() { CDialogEx::PostNcDestroy(); delete this; // 对象自删除，控制权还给调用方 }

这三行代码看着简单，但它是非模态对话框不崩不泄漏的关键。记住一个原则：非模态对话框里绝不能用EndDialog，EndDialog是专门为模态准备的，它只结束模态消息循环，用在非模态上会出各种莫名其妙的问题。

3.2 消息映射：把点击和代码连起来

MFC的消息映射是一套宏，长这样：

BEGIN_MESSAGE_MAP(CSerialCfgDlg, CDialogEx) ON_WM_SYSCOMMAND() ON_WM_PAINT() ON_WM_QUERYDRAGICON() ON_BN_CLICKED(IDC_BTN_TEST, &CSerialCfgDlg::OnBnClickedBtnTest) ON_CBN_SELCHANGE(IDC_CMB_PORT, &CSerialCfgDlg::OnCbnSelchangeCmbPort) ON_EN_CHANGE(IDC_EDIT_IP, &CSerialCfgDlg::OnEnChangeEditIp) END_MESSAGE_MAP()

这套宏的本质是把消息号和成员函数指针关联起来，MFC在消息循环里查表派发。你手动写也行，但更常见的做法是在资源编辑器里双击控件，VS自动帮你生成ON_BN_CLICKED这一行和对应的函数骨架。这个自动生成有时候会出问题，比如你改了控件ID但没同步改消息映射里的宏，编译就报错说找不到IDC_BTN_XXX，这时候反过来检查ID是否一致即可。

不同控件对应的消息宏不一样，搞混了函数根本不会触发。按钮是ON_BN_CLICKED，编辑框内容变化是ON_EN_CHANGE、失去焦点是ON_EN_KILLFOCUS，组合框选择变化是ON_CBN_SELCHANGE，列表控件选中变化是ON_NOTIFY的LVN_ITEMCHANGED。这些消息宏很容易记岔，尤其是编辑框的EN_CHANGE，很多人以为它会在每次按键后触发——确实会，但如果你在里面对编辑框内容做了修改，可能触发递归。所以EN_CHANGE里尽量只读不写，要改内容放到按钮点击或失去焦点事件里处理。

3.3 DDX/DDV：控件和变量怎么对上号

DDX（Dialog Data Exchange）是MFC里最漂亮也最容易翻车的一块设计。它让你把控件和成员变量绑定起来，通过一次UpdateData调用就能双向同步。绑定的代码写在DoDataExchange里：

void CSerialCfgDlg::DoDataExchange(CDataExchange* pDX) { CDialogEx::DoDataExchange(pDX); DDX_Control(pDX, IDC_CMB_PORT, m_cmbPort); // 控件对象绑定 DDX_CBString(pDX, IDC_CMB_PORT, m_strPort); // 组合框当前文本绑定到CString DDX_Text(pDX, IDC_EDIT_IP, m_strIp); // 编辑框绑定 DDV_MaxChars(pDX, m_strIp, 15); // 校验：最多15个字符 DDX_Text(pDX, IDC_EDIT_PORT, m_nPort); // 编辑框绑定到int DDV_MinMaxInt(pDX, m_nPort, 1, 65535); // 校验：1~65535 }

这里核心要理解的是数据流向。DDX_Text这类宏有两个方向：调用UpdateData(TRUE)时，数据从控件流向变量（读取）；调用UpdateData(FALSE)时，数据从变量流向控件（写入）。这个"TRUE读FALSE写"我背了好多年才形成肌肉记忆，你可以记成"TRUE=从界面拿数据，FALSE=把数据放界面"。

DDV是校验，它只在数据从控件流向变量时生效。DDV_MinMaxInt这类如果校验失败，会弹一个消息框提示用户，然后把焦点自动定位到出错的控件上，这是MFC帮你做好的。但有个坑：DDV校验失败后，UpdateData(TRUE)会返回FALSE，你在OnOK里必须判断返回值，否则用户填了非法数据照样被当成合法数据提交了。

void CSerialCfgDlg::OnOK() { if (!UpdateData(TRUE)) { // 校验没通过 return; // 直接返回，别调基类 } // 数据合法，继续业务逻辑 CDialogEx::OnOK(); }

还有一点，DDX_Control和DDX_Text绑定同一个控件是允许的，前者给你一个可操作的控件对象，后者给你一个数据变量。比如组合框，你既需要往里面AddString，又需要读当前选中的字符串，那就两个都绑。这种情况很常见，别觉得绑了两次是多余的。

4. 完整实操：手写一个串口配置对话框

4.1 界面布局与控件规划

光讲机制太空，我们直接做一个能用的串口配置对话框。资源模板上放这些控件：一个组合框下拉选串口号，一个组合框选波特率，一个编辑框填IP（假设是网络串口），一个编辑框填端口号，两个按钮——"测试连接"和"确定/取消"。布局上我习惯左边标签右边控件，或者标签在上控件在下，看对话框宽度定。做成上下结构的话，将来加东西方便，改成横向布局也不费劲。

控件的ID按前面说的规范来：IDC_CMB_PORT、IDC_CMB_BAUD、IDC_EDIT_IP、IDC_EDIT_PORT、IDC_BTN_TEST。对话框ID用IDD_DLG_SERIAL_CFG。组合框的Type属性很关键：选Drop List表示只能选不能输入，选Dropdown表示可输入可选择。串口号一般是设备枚举出来的，用Drop List更安全；IP和端口用编辑框手输。组合框的排序属性（Sort）建议关掉，因为串口COM10、COM11按字符串排序会让COM10排在COM2前面，看起来很奇怪，自己按数字排更符合直觉。

注意：如果组合框设成Drop List，它对应的DDX宏是DDX_CBString或DDX_CBIndex；如果是可编辑的Dropdown，DDX_CBString读的是编辑框里的文本，可能包含用户手动输入的非列表项。场景不同选不同宏，这里选错会导致数据读不对。

4.2 OnInitDialog里的初始化

OnInitDialog是初始化的主战场，标准流程是：先调用基类的OnInitDialog，然后做一些非控件相关的初始化，最后是控件内容的填充。顺序别搞反，基类不先调，某些控件可能还没完全创建好。

BOOL CSerialCfgDlg::OnInitDialog() { CDialogEx::OnInitDialog(); // 1. 枚举可用串口，填充下拉框 for (int i = 1; i <= 32; ++i) { CString strPort; strPort.Format(_T("COM%d"), i); m_cmbPort.AddString(strPort); } m_cmbPort.SetCurSel(0); // 默认选第一个 // 2. 填充波特率 const int bauds[] = { 9600, 19200, 38400, 57600, 115200, 230400 }; for (int i = 0; i < _countof(bauds); ++i) { CString strBaud; strBaud.Format(_T("%d"), bauds[i]); m_cmbBaud.AddString(strBaud); } m_cmbBaud.SetCurSel(4); // 默认115200 // 3. 恢复上次配置（从成员变量同步到控件） UpdateData(FALSE); return TRUE; }

这里有个值得说的点：枚举串口这件事，网上流传的很多代码都是直接循环COM1到COM32去试打开，能打开就认为是存在的。这种做法在没插设备的机器上会依次尝试打开32个不存在的端口，慢且不优雅。更靠谱的方式是查注册表HKLM\HARDWARE\DEVICEMAP\SERIALCOMM，或者用SetupAPI枚举，但这些都不在本文范围，你只要知道枚举这块别写得太粗暴就行。另外，如果串口超过COM9，某些老接口用"COM10:"这种带冒号的格式才认，具体看你的通信库要求。

4.3 数据校验与OnOK的处理

OnOK是点"确定"时的处理入口，也是校验和提交的地方。前面说过要判断UpdateData(TRUE)的返回值，除此之外，业务层面的校验也得在这里做。比如串口号不能为空、IP格式要合法等等。DDV只能做基础校验，复杂规则得自己写。

void CSerialCfgDlg::OnOK() { if (!UpdateData(TRUE)) { return; // 基础DDV没过，焦点已自动定位 } // 业务校验：串口必须选中 int idx = m_cmbPort.GetCurSel(); if (idx == LB_ERR) { MessageBox(_T("请选择一个串口"), _T("提示"), MB_ICONWARNING); m_cmbPort.SetFocus(); return; } // 取选中文本 m_cmbPort.GetLBText(idx, m_strPort); // IP格式粗略校验 if (m_strIp.IsEmpty()) { MessageBox(_T("IP不能为空"), _T("提示"), MB_ICONWARNING); return; } CDialogEx::OnOK(); // 走到这才真正关闭对话框 }

提示：每次校验失败后要return，别继续往下走。另外校验失败时手动SetFocus到出错的控件，配合MessageBox提示，比什么都不做只弹框要友好得多。

还有一个经验：MessageBox的标题别用"错误"这种干巴巴的词，用"参数检查"或者直接"提示"，语气缓和一些，用户不容易烦躁。这是个小细节，但在给现场工人用的软件上，措辞是会被人念叨的。

4.4 调用方：模态和非模态两种用法

对话框做完了，怎么调用它同样是门道。模态调用简单，创建对象、DoModal、判断返回值、取数据：

void CMainFrame::OnConfigSerial() { CSerialCfgDlg dlg(this); if (dlg.DoModal() == IDOK) { CString strPort = dlg.m_strPort; int nPort = dlg.m_nPort; // 应用配置到通信模块... } }

非模态调用则要维护一个成员指针，避免重复弹出，并且在OnClose里清理：

// 头文件里 CSerialCfgDlg* m_pSerialDlg = nullptr; // 调用处 void CMainFrame::OnConfigSerial() { if (m_pSerialDlg == nullptr) { m_pSerialDlg = new CSerialCfgDlg(this); m_pSerialDlg->Create(IDD_DLG_SERIAL_CFG, this); } m_pSerialDlg->ShowWindow(SW_SHOW); m_pSerialDlg->SetFocus(); }

这里有个细节很多人栽过：非模态对话框的父窗口是谁。Create的第一个参数传this（主窗口），那么对话框最小化、关闭都跟着父窗口走，生命周期可控。如果传NULL，它就是独立窗口，主窗口一关它还可能留着，那程序就退不干净了。所以非模态对话框的父窗口，默认传主窗口，除非你有特殊需求。

另外，非模态对话框如果需要跟主窗口交换数据，常见做法是在对话框里存一个主窗口指针，或者通过自定义消息通知主窗口。用SendMessage/PostMessage发个自定义消息最干净，主窗口收到消息再处理，避免了对话框直接操作主窗口成员带来的耦合。

5. 常见问题排查实录

5.1 控件显示与DPI缩放问题

"对话框显示不全"这个问题，我在实际项目里遇到过好几次，典型症状是：在开发机上看一切正常，换到客户的高分屏笔记本上，对话框底部的按钮被切掉了，或者文字重叠。根因基本是对话框模板按固定像素尺寸设计，而系统DPI不是100%。

排查思路是这样：先确认目标机的缩放比例，右键桌面显示设置能看到。如果是125%或150%，那基本就是这个原因。解决分两个层次。短期方案是让对话框可以调整大小，用户手动拖大，内容就露出来了。在对话框属性里把Border改成Resizing，再把System menu勾上，用户就能拖边框。长期方案是声明程序为DPI感知，并在OnInitDialog或OnSize里按当前DPI重新计算控件位置。

// 在OnInitDialog里获取DPI并调整布局 HDC hdc = ::GetDC(m_hWnd); int nDpiX = GetDeviceCaps(hdc, LOGPIXELSX); ::ReleaseDC(m_hWnd, hdc); // 96是100%时的基准DPI double fScale = nDpiX / 96.0; // 然后按fScale缩放各控件的位置和尺寸

注意：声明DPI感知要改工程的清单文件（manifest），加dpiAware相关节点，或者在程序启动早期调用SetProcessDpiAwareness。这一步不做，系统会帮你"拉伸"窗口，看起来模糊还错位。

顺便说个常见的列表控件列头对齐设置无效的问题，网上搜"MFC List控件第一行设置LVCFMT_LEFT无效果"的人不少。原因通常是第一列被当作带图标的列，它的对齐受LVS_EX属性影响，而且某些情况下Windows会强制第一列左对齐。如果你想让第一列居中或右对齐，一个变通做法是在LVCOLUMN里设置LVCFMT_LEFT但配合content对齐属性，或者干脆接受第一列左对齐。这个问题在不同Windows版本上表现还不一样，建议实际测试。

5.2 DDX绑定与UpdateData的坑

DDX出问题一般都表现为数据不生效：界面上改了值，变量里还是旧值；或者变量改了，界面没更新。这类问题的排查有固定套路。

第一步查DoDataExchange是否真的被调用过。它在对话框创建时和每次UpdateData时被调用，如果你在OnInitDialog里手动改了控件内容但没调UpdateData(FALSE)，界面和变量的初次同步就没完成。第二步查DDX宏和控件ID是否匹配，ID写错了会无声失败，编译不报错，运行时数据就是不对。第三步查变量类型和DDX宏是否对应：DDX_Text对应CString、int、UINT、double等，DDX_CBString对应组合框的CString，DDX_Check对应BOOL，DDX_Radio对应int。类型用错编译器一般会报错，但有些隐式转换会让你以为没问题。

我踩过最坑的一次是：编辑框绑定的是int，用户输入了空字符串，UpdateData(TRUE)直接弹了个系统提示框说"请输入整数"，但对话框走的是默认校验，用户一头雾水。后来我给int类型的编辑框都加了自定义校验，空值按0处理或者提前拦截。经验就是，凡是用户能输入的，都要假设他会输入任何东西。

5.3 非模态对话框的内存与销毁

非模态对话框的内存问题，本质就一句话：谁new的谁负责，或者让对话框自己负责。我推荐后者，也就是前面说的PostNcDestroy里delete this。这样调用方只管new和Create，销毁由对话框自己处理，职责清晰。但要注意一个连带问题：调用方持有的指针会变成野指针，所以对话框自删除后要通知调用方把指针置空。

// 对话框里，PostNcDestroy void CSerialCfgDlg::PostNcDestroy() { CDialogEx::PostNcDestroy(); if (m_pParent != nullptr) { m_pParent->m_pSerialDlg = nullptr; // 通知父窗口清零 } delete this; }

通过父窗口指针直接操作成员不太优雅，更好的做法是发一个自定义消息，父窗口收到后处理。但为了说明原理，这里就直接访问了。实际项目里我一般会在父窗口维护一个std::vector<CSerialCfgDlg*>或者用CList管理所有非模态对话框，统一在OnClose里判空清理。

还有个坑是非模态对话框里调用EndDialog。前面提过一次，这里强调：EndDialog会走模态的退出逻辑，非模态用它会破坏消息循环，轻则窗口关不掉，重则整个程序卡死。非模态关闭一律用DestroyWindow，重写OnCancel和OnOK，把里面的EndDialog换成DestroyWindow。

5.4 常见问题速查表

把上面遇到的高频问题整理成一张表，方便你直接对照排查：

表格里每一条我都在项目里实际撞过，尤其是非模态对话框退出泄漏这一条，当年一个后台采集程序跑了三天把内存吃满崩了，查了两天才定位到是某个图表对话框没删干净。这种问题不写出来，新手真是要反复踩。

6. 几个值得深挖的扩展方向

6.1 列表控件与树控件的常见配置

对话框里一旦涉及大量数据展示，就会用到CListCtrl和CTreeCtrl。列表控件的经典写法是：在OnInitDialog里设置扩展样式（LVS_EX_FULLROWSELECT、LVS_EX_GRIDLINES），然后InsertColumn插入列，InsertItem插入行，SetItemText填单元格。列宽可以用LVSCW_AUTOSIZE自适应，但数据多的时候自适应会卡，建议设个合理固定宽度。

树控件则注意节点数据的挂载，通常用SetItemData或者自定义的节点结构，配合TVN_SELCHANGED消息响应选中变化。MFC里这些控件的接口挺冗长的，熟练之后你会发现大部分都是模板化操作，值得封装一层自己的辅助类，减少重复代码。我自己的工程里就有一个CTreeHelper，把常用的插入、查找、展开合并成几个函数，用起来顺手很多。

6.2 让控制台程序也用上MFC对话框

有个挺实用的需求：一个控制台程序，偶尔需要弹个对话框让用户选个路径或者确认一下。这完全可以做到。核心是控制台程序也要链接MFC，并且在使用对话框前初始化MFC环境。简单做法是在main开头调用AfxWinInit(::GetModuleHandle(NULL), NULL, ::GetCommandLine(), 0)，然后就能创建并DoModal一个对话框了。注意控制台程序没有CWinApp实例，所以别依赖App类的那些初始化。这个技巧在写批量处理工具时特别有用，命令行跑着跑着需要人工确认，弹个对话框比在控制台里读一行输入友好多了。

6.3 可拉伸的对话框布局

最后说个进阶话题：可拉伸的对话框。MFC原生的CDialog对拉伸支持很弱，窗口拉大后控件还待在原地，体验很割裂。几种做法，一是重写OnSize，手动按比例调整每个控件的位置和尺寸；二是用CDialogBar或者第三方布局库。网上的"MFC CDialogBar 能拉伸大小"这类问题，本质都是想知道怎么让里面的控件跟着动。手写OnSize虽然笨，但可控性最强，尤其适合控件数量不多的对话框。思路就是记录初始的控件矩形，在OnSize里根据窗口新旧宽度比例重新计算每个控件的Rect，然后MoveWindow。做熟了之后你会发现，这个套路基本能应付80%的布局需求，比引入依赖要轻量。

写到这里也差不多了。MFC对话框这个东西，机制不算复杂，但细节特别多，每一个看起来不起眼的地方——命名、Tab顺序、UpdateData的时机、非模态的销毁——都可能是后期加班的源头。我个人在实际项目里的体会是，把规范做在前面，比事后重构省太多力气，尤其是ID命名和消息映射这两块，趁工程规模小的时候统一好，后面加多少个对话框都不会乱。至于高DPI显示不全、列表首列对齐这类问题，多点几下属性、多做几次实测，基本都能找到合适的解法，不用太焦虑。