企业官网建设流程全解析

做 MFC 界面的人，几乎都绕不开CMFCPropertyGridCtrl这个属性网格控件。把几十个配置项往里一塞，再配上描述区，一套标准的设置面板就出来了。可真正把项目做完，你会发现默认状态根本没法直接交付：左列太窄，长一点的属性名直接变成省略号；行高看着正常，一换 DPI 或字体，文字又挤得跟压缩包似的。这篇就把列宽、行高这两个尺寸问题彻底捋一遍，讲清楚它们由谁决定、怎么改、改的时候会踩哪些坑。适合正在用 MFC 做工具类软件、对话框或属性页的同学，尤其是已经被这两个尺寸问题折腾过的人。

1. 为什么列宽和行高会在同一个源码函数里决定

1.1 属性网格的客户区到底被分成了几块

我一开始也以为CMFCPropertyGridCtrl就是一个大列表，列宽和行高是列表控件的常规属性。后来翻源码才发现，它的内部结构比想象中复杂。

一个典型的属性网格，从上到下大概是这个布局：

+-------------------------------------------+ | Name | Value | <- 表头区（Header） +-------------------------------------------+ | Appearance (分组行，整行标题) | | ------------+-----------------------------+ | Color | RGB(255, 0, 0) | <- 属性条目 | ------------+-----------------------------+ | Size | 100 x 100 | <- 属性条目 +-------------------------------------------+ | 属性描述文字会显示在这一块 | <- 描述区（可选） +-------------------------------------------+

这里面有四个区域：

• 表头区：显示“Name”和“Value”两个列标题，它是内部的一个自绘 Header 控件，不是普通CListCtrl的表头。
• 列表区：真正的属性条目列表，每个条目占一行，行高就是这个区域里的一行矩形高度。
• 分组行：属性条目可以有 Group，分组标题默认整行显示，但会被左列宽度截断（后面细说）。
• 描述区：显示当前选中属性的说明文字，高度由SetDescriptionRows控制，和行高没有直接关系。

很多人以为列宽是“Header 控件的列宽”，行高是“列表项的 item height”，两者各管各的。但实际上，这两个尺寸都在同一个布局函数里被统一计算和设置的。要理解列宽和行高，必须先看这个函数。

1.2 布局核心：AdjustLayout 做了什么

CMFCPropertyGridCtrl所有涉及尺寸变化的事件，最终都会汇聚到一个内部函数AdjustLayout上。比如：

• 控件收到WM_SIZE
• 调用SetRowHeight
• 开关表头、开关描述区
• 字体变化

统统走这条路。源码里这个函数很长，但核心的布局逻辑可以简化为这样一段伪代码：

void CMFCPropertyGridCtrl::AdjustLayout() { CRect rcClient; GetClientRect(&rcClient); // 1. 计算左列（属性名列）的宽度 if (m_nColumnWidth <= 0) { m_nColumnWidth = rcClient.Width() / 3; // 默认按三分 } // 2. 把客户区竖向切成左右两半 m_rectNameColumn = rcClient; m_rectNameColumn.right = rcClient.left + m_nColumnWidth; m_rectValueColumn = rcClient; m_rectValueColumn.left = m_rectNameColumn.right; // 3. 根据字体高度和行高成员，计算每一行占用的矩形 int nRowHeight = m_nRowHeight; if (nRowHeight <= 0) { nRowHeight = afxGlobalData.GetTextHeight() + 6; } m_sizeRow.cx = nRowHeight; m_sizeRow.cy = nRowHeight; }

变量名不一定和你本机 SDK 版本完全一致，但逻辑基本就是这一套。 注意几个关键点：

• m_nColumnWidth是左列宽度的“当前值”，用户拖动分隔线时改的就是它，AdjustLayout用它切分左右区域。
• m_nRowHeight是行高，默认取afxGlobalData.GetTextHeight() + 6这类的值。
• 这两个成员都是全局的，对所有条目生效。你没法通过 API 单独给某一个条目设置不同的行高。

理解了这一点，后面所有的问题都好解释了。

2. 列宽：从“拖一拖就能用”到“按需求固定比例”

2.1 用户拖拽分隔线是内置能力，但它有一个隐藏缺陷

CMFCPropertyGridCtrl自带了列宽拖拽能力。鼠标移到属性名列和值列之间的分隔线上时，光标会变成左右双向箭头，按住左键拖动，左列宽度会实时变化。这是内部鼠标消息处理里对分隔线做了 hit-test 的结果。

但这里有个很隐蔽的问题：拖动后得到的列宽，只存在内存里，且没有任何公开接口能查询或设置它。你拖得再满意，下次启动程序，控件重新创建，m_nColumnWidth恢复到初始值，一切重来。

如果你做的是工具软件，用户调整完列宽，关掉程序再打开，列宽变了，用户会觉得很“草台”。但程序员想保存这个值，却找不到 API，这就是这个控件最难受的地方。

我的建议是：要么接受这个缺陷，要么干脆用程序固定列宽比例，不给用户拖拽的预期。对大多数配置面板来说，固定比例比自由拖拽更符合产品设计。

2.2 程序化设置列宽：最干净的做法是改 MFC 源码的布局逻辑

CMFCPropertyGridCtrl没有公开的SetColumnWidth这样的接口。想在代码里直接指定左列宽度，绕不开两种情况。

第一种情况，如果你能接受重新编译 MFC 源码（在 Visual Studio 里，MFC 源码是随安装包分发的，你可以把afxpropertygridctrl.cpp复制到工程里参与编译，而不是使用默认的 MFC 库版本，这是老派 MFC 程序员的常用手段），最直接的办法就是修改AdjustLayout里计算m_nColumnWidth的逻辑。

比如希望左列宽度固定为 40%：

void CMFCPropertyGridCtrl::AdjustLayout() { CRect rcClient; GetClientRect(&rcClient); // 把默认的三等分改成按比例计算 if (m_nColumnWidth <= 0) { m_nColumnWidth = rcClient.Width() * 2 / 5; // 40% } // 后续逻辑保持不变... }

这个办法的优点是彻底、干净，所有使用这个控件的对话框都会生效。缺点也很明显：你要维护一份 MFC 源码的副本，升级 SDK 时要重新做一次改动。

第二种情况，不动源码，用子类化。新建一个CMyPropertyGridCtrl继承CMFCPropertyGridCtrl，覆写OnSize。OnSize里先调用基类，再利用一个我们自己的内部成员来修正列宽。关键点是：你需要在基类的AdjustLayout完成之后，再把分隔线移到指定位置。

由于没有公开 API，我通常用的办法是暴力但有效的“布局后微调”——通过操作内部 Header 控件来设置列宽。具体来说，属性网格内部的表头其实是一个独立的子窗口，枚举子窗口可以找到它，然后直接用HDITEM的HDI_WIDTH设置列宽：

void CMyPropertyGridCtrl::OnSize(UINT nType, int cx, int cy) { CMFCPropertyGridCtrl::OnSize(nType, cx, cy); SetRedraw(FALSE); // 枚举子窗口，找到 Header 控件并设置两列的宽度 CWnd* pChild = GetWindow(GW_CHILD); while (pChild != nullptr) { // 用类名判断是否为 SysHeader32 CString strClassName; ::GetClassName(pChild->GetSafeHwnd(), strClassName.GetBuffer(128), 128); strClassName.ReleaseBuffer(); if (strClassName == L"SysHeader32") { HDITEM hdi = {0}; hdi.mask = HDI_WIDTH; hdi.cxy = cx * 2 / 5; // 左列 40% ::SendMessage(pChild->GetSafeHwnd(), HDM_SETITEM, 0, (LPARAM)&hdi); hdi.cxy = cx * 3 / 5; // 右列 60% ::SendMessage(pChild->GetSafeHwnd(), HDM_SETITEM, 1, (LPARAM)&hdi); break; } pChild = pChild->GetWindow(GW_HWNDNEXT); } SetRedraw(TRUE); Invalidate(TRUE); }

这里要注意：Header 控件在不同版本的系统上可能不是标准的SysHeader32类名（自绘 Header 可能用窗口类名AfxHeaderCtrl之类），所以你要先用 Spy++ 或者::GetClassName确认一下。这个方法虽然是 hack，但不用改动 MFC 源码，在工程里直接就能用。我把这个代码放出来后，很多同事的第一反应也是“这不正规”，但它确实能解决列宽问题。

2.3 别忽略 SetGroupNameFullWidth：分组行被截断的问题

很多人调完列宽发现，分组标题还是被截断。

原因是：属性条目的分组标题，默认只在“左列”的宽度范围里绘制。如果你有很多分组，每个分组标题都是长字符串，就会像这样：

+------------------+----------------------+ | 基础设置 | | | ---------------- + ------------------- | | 名称 | app.config |

分组标题“基础设置”右侧应该延伸到头，但实际上到了分隔线就截断了。解决方案是SetGroupNameFullWidth(TRUE)：

m_wndPropertyGrid.SetGroupNameFullWidth(TRUE);

这个 API 是公开的，它的作用就是让分组标题占满整个客户区宽度，不受列宽限制。我在列宽相关的问题里，印象最深的就是这个：很多人调了半天列宽，表格倒是正常了，分组标题又出问题，其实只要一行代码。

2.4 不要焦虑“保存用户拖拽列宽”这件事

如果你仔细看这一节的标题，会发现我没有给出“保存用户拖拽后的列宽”的完整代码。原因很简单：这个控件根本不提供查询列宽值的公开接口，你要做只能继续用枚举子窗口的 hack，在每次拖拽结束后通过HDM_GETITEM拿到左列宽度，存到注册表或配置文件里，下次启动时再调用上一节的方法恢复。

这种事情投入产出比极低。属性网格的列宽，对用户来说只是一个“舒适度”问题，不是“功能”问题。用户今天拖宽了，明天重新打开又变回去，顶多是觉得有点蠢，但不会影响他用软件干活。与其在这里做大量 hack，不如直接把列宽固定成合理的比例。

我个人的建议很简单：

• 属性名都是短词的，列宽 40% 左右。
• 属性名有“命名空间前缀”这类长字符串的，列宽 50% 到 60%。
• 带有颜色预览、按钮、下拉框的，值列一定要留够空间，别让编辑器控件挤在一小块区域里。

3. 行高：唯一公开 API 是 SetRowHeight，但别只盯着行高

3.1 SetRowHeight 的行为细节

行高的控制比列宽要明确得多。公开接口就是SetRowHeight(int nRowHeight)，对应源码里会更新m_nRowHeight，然后调用AdjustLayout重排所有条目。

有几个行为细节，文档里不会写，但你会踩到：

第一，传入一个负数，比如-1，控件会认为是“恢复默认值”，然后回到“根据当前字体高度 + 固定 padding”的计算逻辑。也就是说，如果你想设置固定像素行高，传一个正数；想恢复默认，传负数。

第二，行高不是单纯的“行矩形高度”，它还直接影响所有属性值的编辑器控件的高度。比如属性值是CMFCPropertyGridComboCtrl下拉框，那下拉框的实际控件高度就是从行高矩形里扣出来的。行高设置过小，下拉按钮就被裁掉一半；行高设置过大，每个条目之间又会显得空荡荡。

第三，分组行的高度也会受到行高的影响，但和普通条目行不完全一致。实际表现是：分组行往往比普通条目行矮一点，文字垂直居中的位置也会有差异。这个是内部硬编码的，你没有办法单独调分组行的高度。

3.2 行高与字体强绑定：为什么换了字体就乱

我最开始用这个控件时，在OnCreate里直接写了：

m_wndPropertyGrid.SetRowHeight(20);

当时显示正常，因为那个对话框用的是 9 号系统字体。后来项目为了美观，给对话框设置了 11 号雅黑字体，结果运行起来，所有行的文字都只露出上半部分，像被剪刀从中间剪了一样。

原因很简单：我写死 20 像素，但 11 号雅黑的字体高度已经超过 20 像素了，文字矩形被裁剪。属性网格内部不会因为你把字体调大了就自动调整行高，它只会按你上次设置的m_nRowHeight来布局。

正确的做法是：行高永远不用固定的像素，而是根据字体实时计算。

比较可靠的方式是拿到控件的字体，用GetTextMetrics或GetTextExtent算出字体高度，再留出上下各 3~4 像素的呼吸空间。比如：

void CMyDialog::ApplyFontToPropertyGrid(CWnd* pGrid, CFont* pFont) { pGrid->SetFont(pFont); ASSERT(pGrid->IsKindOf(RUNTIME_CLASS(CMFCPropertyGridCtrl))); CMFCPropertyGridCtrl* pPropGrid = (CMFCPropertyGridCtrl*)pGrid; // 计算字体高度, 作为行高基准 CDC* pDC = pGrid->GetDC(); CFont* pOldFont = pDC->SelectObject(pFont); TEXTMETRIC tm; pDC->GetTextMetrics(&tm); pDC->SelectObject(pOldFont); pGrid->ReleaseDC(pDC); int nRowHeight = tm.tmHeight + 6; // 上下各留 3 像素 pPropGrid->SetRowHeight(nRowHeight); }

这个方案的核心思想是：字体是行高的唯一决定因素，一切跟着字体走。换了字体就重新计算，千万不要在主对话框初始化时设置一次行高就再也不管。

3.3 行高不够时的典型症状：值控件错位

如果行高设置得太小，不只文字被裁剪，值区域的控件也会“乱掉”。下面这些现象你肯定见过，只是未必想到它们和行高有直接关系：

• 颜色属性的颜色块按钮明显偏上，和文字不在一条垂直中心线上。
• 下拉框右侧的箭头变成了一个“缺角”，甚至看不到箭头。
• 数字属性变成一个高耸的编辑框，但文字都在底部，上面一大片空白。

出现这些症状，第一反应先看行高是不是和字体不匹配。通常把行高设置成“字体高度 + 6~8 像素”就能解决。注意：这个 padding 取 4~8 比较适中。取 2 时文字贴着上下边，选中高亮色块几乎挨着文字，看着很拥挤；取 20 时每一行都巨大，一屏显示不了几个条目，用户翻页翻到手抽筋。

如果你有一个特别重要的属性，其值区域控件本身比较高，想给这一行单独加高，这种需求，CMFCPropertyGridCtrl做不到。行高是控件级全局设置，不是条目级属性。网上有些帖子说可以通过派生CMFCPropertyGridProperty重绘达到目的，我试过一阵子，结论是：要动的东西太多了，得不偿失。大多数情况下，全局行高统一设置就够用。

3.4 行高的“另一种控制”：关闭表头对行布局的影响

有人喜欢属性网格有表头，有人不喜欢。EnableHeaderCtrl(FALSE)可以去掉表头，省出那几十像素的高度，让属性列表区更大。去掉表头之后，列宽分隔线仍然可以拖动，行高逻辑不变。所以我通常会在“行高问题排查”里先问一句：你是不是觉得空间不够才想调行高的？

如果是，那先关表头比调行高更管用。表头本身的高度是跟随字体走的，没法通过 API 设置具体像素，但它至少占了二三十像素。关掉表头后，这一部分空间直接还给列表区，比强行压缩行高要舒服得多。

这个经验来自于一个我实际维护的旧项目：对话框空间很小，属性网格有很多条目，一开始我拼命压缩行高，结果字体一换就乱成一团。后来一位同事提醒我“你先把表头关了吧，本来就两列，表头写个 Name 和 Value 有什么意义？”关了之后，同样的空间多了两三行条目，行高反而能比之前更宽松。

4. 高 DPI 缩放：列宽行高问题的重灾区

4.1 症状：96 DPI 下正常，144 DPI 下全乱

现在的高分屏已经很普及了，系统缩放从 100% 调到 125%、150% 甚至 200% 都很常见。MFC 默认对 DPI 的支持比较“凑合”，很多控件内部用的是绝对的像素值。CMFCPropertyGridCtrl也不例外。

典型的翻车现场：

• 文字模糊、变虚，这是没做字体缩放或者字体被双重缩放。
• 行高明显不够，文字被截断，原因和 3.2 节说的一样：行高固定 20 像素，但系统字体已经被缩放成 24 像素高了。
• 列宽比例异常：你写死了列宽 200 像素，但客户区宽度只有 700 像素，换成 150% DPI 后客户区变成更小或更大的逻辑尺寸，200 像素占的比例就完全不同了。

4.2 高 DPI 下正确的尺寸策略

先说结论：不要在任何地方写死“多少像素”的列宽和行高，全部用相对值或者根据字体计算的值。

• 列宽：按客户区宽度比例算，比如“左列占 40%”。
• 行高：按字体高度算，比如“字体高度 + 6”。
• 表头、描述区等区域，跟着字体走。

这个策略和普通 DPI 下是一致的，只是在高 DPI 下一旦违反，问题暴露得会特别明显。

如果你要处理系统 DPI 变化事件，比如WM_DPICHANGED消息，需要在这里面把属性网格重新调整一遍：

case WM_DPICHANGED: { // 更新字体 g_Font.DeleteObject(); g_Font.CreatePointFontIndirect(m_lf); // 重新计算行高 int nRowHeight = /* 用新字体计算 */; m_wndPropertyGrid.SetFont(&g_Font); m_wndPropertyGrid.SetRowHeight(nRowHeight); // 强制重新布局 CRect rc; m_wndPropertyGrid.GetClientRect(&rc); m_wndPropertyGrid.MoveWindow(rc); break; }

这里的核心是：所有字体对象、行高、列宽，都要跟着新的 DPI 重新生成，而不是只拉伸窗口尺寸。很多 MFC 对话框在 DPI 变化后只 MoveWindow 拉伸了控件，没有重新设置字体和行高，导致窗口变大了但文字还是那么小、行高还是那么矮，非常难看。

4.3 一个小技巧：用 dialog unit 代替像素

如果你在设计阶段就想让属性网格在多个 DPI 下表现一致，可以考虑用一个“基准字体高度”来推导行高，而不是用五号字对应的 20 像素。简单说就是：

• 用一个LOGFONT结构来管理字体，比如 9 号雅黑。
• 每次拿到LOGFONT，根据 DPI 用MulDiv缩放字体高度。
• 行高再基于字体高度计算。

这样做的好处是，以后换系统、换 DPI，代码里有一处统一的换算逻辑，而不是散落一堆魔法数字。这不算什么高级技巧，但它能让你少加好几个小时的班。

5. 一次实战排查：为什么我的属性网格文字被“腰斩”了

最后分享一个真实的排查过程，希望能帮你形成一套“遇到列宽行高问题怎么查”的思路。

某天测试反馈说：设置对话框的属性列表，很多条目文字只显示上半部分，下拉框也看起来不太对。当时我的第一反应是行高设低了，直接在OnCreate里把SetRowHeight(20)改成SetRowHeight(30)，测试说“没好多少”。

这时候我开始觉得不对劲。如果只是行高不够，改成 30 应该至少能看出一部分变化。于是我从头排查：

1. 看字体：属性网格用的是什么字体？测试机是 150% DPI，而我开发机是 100% DPI。我开发机上字体是 9 号雅黑，高度约 14 逻辑像素，加 6 等于 20 像素行高，足够。测试机上系统对字体做了缩放，实际字体高度已经到 21 逻辑像素，20 像素行高当然不够。

2. 看行高是哪儿来的：我发现代码里SetRowHeight(20)是写死的，不是计算出来的。问题根源就在这里。

3. 改成动态计算：按 3.2 节的方式，用GetTextMetrics计算高度，再加 padding。改完上传测试机，一切正常。

这个案例没什么高深技巧，但它能很好地说明CMFCPropertyGridCtrl这类控件的尺寸 API 有多“脆”：一个写死的像素值，能让你在高 DPI 机器上完全无法交付。

我的建议是，凡是和这个控件尺寸相关的逻辑，全部集中在一个初始化函数里，明确分成三步：

• 设置字体
• 根据字体计算行高
• 根据控件客户区计算列宽

这样以后无论换字体、换 DPI、换系统，都只需要改这一个函数，不会在代码里到处找魔法数字。

用这个控件好几年了，最大的体会是：CMFCPropertyGridCtrl的默认外观“能用”，但“不精致”。列宽和行高这两个参数，看着简单，实则牵一发动全身。多花十分钟把尺寸逻辑梳理成动态计算的，后面能省下大量调界面的时间。