企业官网建设流程全解析

简介：这份资源面向使用 VC/MFC 进行桌面开发的程序员，尤其是需要在对话框或视图里快速呈现数据库查询结果的开发者，系统讲解 MFC DataGrid 控件的实际用法。内容围绕显示查询结果、控制列宽等显示属性、格式化数据、多行显示以及 HeadClick 消息排序等典型场景展开，并给出可直接套用的代码片段，帮助读者把控件接入自己的项目。资源包为单个 doc 文档，约 226KB，属于图文并茂的技术笔记，便于离线阅读与随查随用。目前已有 851 人学习，说明其在 MFC 数据网格应用这一细分方向上有一定参考价值。读者可从中获得从建立工程、插入控件、绑定 ADO 记录集到列对象操作与格式设置的完整思路，并借助作者对类方法名的梳理快速上手，减少在控件细节上反复试错的成本。

1. 一个被低估的真相：DataGrid 的“简单”背后是三层接口在接力

很多人第一次在对话框上拖出 Microsoft DataGrid OLEDB 6.0 控件时，都会觉得这东西“不就是个表格吗”。拖上去、绑个记录集、列宽调一调，半小时就能跑起来。但真正让人翻车的地方，往往出现在你想改一个看似微不足道的细节时——比如把某一列的小数显示成百分数，或者点一下表头就按该列排序。这时候你会发现，网上能搜到的中文资料翻来覆去就是那几行SetRefDataSource和SetWidth，再往下就没了。

问题出在哪？出在大多数人把 DataGrid 当成一个“控件”来用，而它本质上是一个 ActiveX 控件，背后是一整套 COM 接口在支撑。你在 ClassWizard 里勾选的那几个类——CDataGrid、CColumns、CColumn——只是 MFC 帮你生成的薄薄一层包装，真正的功能入口藏在 COM 的查询接口里。搞懂这三层接口怎么接力，你才能从“会用”走到“能改”。这篇内容就沿着“数据怎么进去 → 显示怎么控制 → 格式怎么干预”这条链路，把 DataGrid 的底层机制拆开来看。

2. 数据绑定：SetRefDataSource到底把什么交给了控件

2.1 从 ADO 记录集到 DataGrid 的数据通路

先看那段几乎每篇教程都会贴的代码：

CADODatabase m_DBCn; // 数据库连接对象 CADORecordset m_Rs; // 记录集对象 CDataGrid m_ctrlDG; // DataGrid 控件对象 CString strConnection; strConnection.Format(_T("Provider=Microsoft.Jet.OLEDB.4.0;") _T("Data Source=note.mdb")); m_DBCn.Open((LPCTSTR)strConnection); // 打开 Access 数据库 m_Rs.SetDatabase(&m_DBCn); // 记录集绑定到连接 m_Rs.Open(_T("select * from test;")); // 执行查询 m_ctrlDG.SetRefDataSource((LPUNKNOWN)m_Rs.GetRecordset()); // 关键一步

这段代码里最值得琢磨的是最后一行。SetRefDataSource的参数类型是LPUNKNOWN，也就是 COM 里最基础的IUnknown*。这意味着 DataGrid 并不关心你传进来的是 ADO 记录集、DAO 记录集还是别的什么，它只要求这个对象能通过QueryInterface拿到它需要的接口。常见的实现思路是：DataGrid 内部会尝试查询IUnknown背后的数据源接口，拿到之后建立一个“数据绑定”关系，之后控件自己负责从数据源拉取行集、监听数据变化。

这里有一个容易被忽略的细节：m_Rs.GetRecordset()返回的是 ADO 记录集对象的接口指针，而SetRefDataSource接受的是LPUNKNOWN。这个转换之所以能成立，是因为 ADO 记录集本身就是一个 COM 对象，它的IUnknown可以被 DataGrid 识别。如果你用的是别的数据访问方式，只要拿到的对象支持 DataGrid 需要的接口，同样可以绑上去。这就是为什么原文说“你可以使用其它的方法访问数据库，而不会影响控件的使用”——绑定的本质是接口，不是具体的类。

2.2 为什么绑定的是接口而不是对象

理解这一点，就能理解 DataGrid 设计上的一个核心取舍：它把自己定位成一个“数据消费者”，而不是“数据管理者”。数据从哪来、怎么查、什么时候刷新，这些都不归它管。它只负责在拿到数据源接口之后，把行和列画出来，并在用户操作时把事件抛回去。

这种设计的直接好处是解耦。你的数据库层可以用 ADO、可以用 ODBC、甚至可以自己实现一个符合接口规范的数据源，DataGrid 都能显示。代价是你在绑定时必须确保数据源对象的生命周期覆盖控件的使用期——如果m_Rs先于m_ctrlDG析构，控件再去访问数据源就会出问题。常见的排查思路是：如果程序在关闭对话框时崩溃，先检查记录集对象和控件的析构顺序。

注意：SetRefDataSource之后，DataGrid 并不会复制一份数据。它持有的是数据源的接口引用，所以对记录集的修改（比如重新查询）会直接反映到控件上，前提是接口支持通知机制。

3. 列对象模型：CColumns和CColumn是怎么组织起来的

3.1 从控件到列集的层级关系

数据绑好之后，下一步就是控制显示。原文给出的路径很清晰：

CColumns cols = m_ctrlDG.GetColumns(); // 取得列集 CColumn col = cols.GetItem(vt); // 按索引取得某一列 col.SetWidth(fWidth); // 设置列宽

这三行代码对应的是 COM 里的一个层级对象模型：DataGrid 控件 → 列集（Columns）→ 单列（Column）。GetColumns()返回的是CColumns对象，它代表整个列集合；GetItem(vt)接受一个VARIANT类型的索引，返回单个CColumn对象。这里的vt可以是整数索引，也可以是列名字符串——用VARIANT是为了同时支持两种寻址方式。

为什么要有“列集”这一层？因为很多操作是面向集合的，比如遍历所有列、批量设置属性。如果只有单列对象，你就得自己维护一个列表。列集的存在让“对所有列做同一件事”变得自然。常见的实现思路是：CColumns内部持有一个列对象的数组或映射，GetItem根据传入的VARIANT类型决定是按索引查还是按名称查。

3.2CColumn上能做什么：属性、格式、行为

拿到CColumn之后，能做的事情就多了。原文提到了三类：列宽（SetWidth）、数字格式（SetNumberFormat）、以及通过消息机制实现的排序。实际上CColumn暴露的方法远不止这些，但方法名本身就有很强的自解释性——这也是原文结尾提到的“查看相关类的方法名，能顾名思义”。

从机制上看，CColumn的每个方法最终都会转换成对 COM 接口的调用。比如SetWidth对应的是设置列的宽度属性，SetNumberFormat对应的是设置格式化字符串。这些属性由控件内部维护，并在重绘时生效。这里有一个设计上的取舍：为什么格式化字符串用的是"0.0%"这种形式，而不是一个枚举值？因为格式化规则需要足够的表达能力，枚举覆盖不了所有场景。用字符串格式，你可以组合出各种显示效果，代价是需要了解格式字符串的语法。

// 将当前列的数字格式设置为百分数，保留一位小数 col.SetNumberFormat(_T("0.0%"));

这行代码的效果是：如果单元格里的值是 0.123，显示出来就是 12.3%。注意它改变的是显示，不是底层数据。数据源里的值仍然是 0.123，只是控件在绘制时按格式字符串做了转换。这一点在导出数据时特别容易踩坑——你看到的和实际存的不一样。

4. 消息机制：HeadClick 排序是怎么串起来的

4.1 ActiveX 事件在 MFC 里的映射方式

DataGrid 作为一个 ActiveX 控件，它的事件（比如点击表头）需要通过消息映射连接到你的处理函数。原文提到“利用消息机制，对控件的 HeadClick 消息处理，使控件能进行排序”，但没有展开。这里补全一下机制。

在 MFC 里，ActiveX 控件的事件通过“事件接收器映射”来处理。ClassWizard 在生成CDataGrid包装类时，会同时生成一个事件接收器类，里面有一张映射表，把控件的事件 ID 映射到你的处理函数。当用户点击表头时，控件触发HeadClick事件，MFC 框架根据映射表找到你的函数并调用。

// 在事件接收器映射中关联 HeadClick 事件 BEGIN_EVENTSINK_MAP(CYourDlg, CDialog) ON_EVENT(CYourDlg, IDC_DATAGRID1, 2, OnHeadClickDataGrid1, VTS_I2) END_EVENTSINK_MAP() void CYourDlg::OnHeadClickDataGrid1(short ColIndex) { // ColIndex 是用户点击的列索引 // 在这里根据列索引重新排序记录集，然后刷新控件 }

ON_EVENT宏的第三个参数是事件 ID，第四个是处理函数名，第五个是参数类型描述。VTS_I2表示事件带一个short类型的参数，也就是列索引。这个参数由控件在触发事件时填入，你拿到之后就知道用户点了哪一列。

4.2 排序的实现思路与边界

排序本身不是 DataGrid 内置的功能，它只是把“用户点了表头”这件事告诉你，具体怎么排、按什么排，需要你自己实现。常见的做法是：在OnHeadClick里根据列索引构造一个ORDER BY子句，重新打开记录集，然后再次调用SetRefDataSource刷新控件。

这里有几个容易翻车的点。第一，重新查询后记录集对象的内容变了，但控件持有的接口引用还是同一个，所以不需要重新绑定，只需要通知控件数据变了。第二，如果数据量很大，每次点击都重新查询可能会慢，需要考虑缓存或者只对当前页排序。第三，排序状态需要自己维护——用户点一次升序、再点一次降序，这个状态控件不管，得你在对话框类里加一个成员变量来记录。

注意：HeadClick事件的参数类型在不同版本的控件里可能不同，有的是short，有的是long。如果事件处理函数的参数类型和映射表里的描述不匹配，运行时可能收不到事件或者收到错误的值。

5. 避坑与排查：那些文档里不会写的翻车现场

5.1 控件注册失败，对话框上显示一个空白方块

现象：在对话框资源里插入 DataGrid 控件后，编译运行，控件位置显示一个空白区域或者一个带叉的方块。

原因：ActiveX 控件需要在系统里注册后才能使用。如果目标机器上没有注册MSDATGRD.OCX，或者注册的版本不对，控件就无法创建。

解决：确认MSDATGRD.OCX存在于系统目录，并用regsvr32注册。如果是发布程序，需要在安装包里包含这个文件并执行注册。另外注意 32 位和 64 位的问题——32 位程序需要 32 位的控件版本。

5.2 绑定数据后控件不显示任何内容

现象：SetRefDataSource调用成功，但控件里一行数据都没有。

原因：最常见的是记录集没有真正打开，或者查询返回空结果。另一个常见原因是记录集的游标类型不支持控件需要的操作。

解决：先检查m_Rs.Open的返回值，确认查询执行成功。然后在绑定之前打印一下记录集的记录数。如果记录数大于零但控件不显示，尝试更换游标类型，比如使用客户端游标或静态游标。

5.3 设置列宽后没有效果

现象：调用SetWidth之后，列宽没有变化。

原因：可能是GetItem返回的CColumn对象无效，或者设置的时机不对。如果控件还没有创建窗口，设置属性可能不会生效。

解决：确保在控件已经创建并绑定数据之后再设置列属性。可以在OnInitDialog里绑定数据，然后在数据绑定之后立即设置列宽。如果还是不行，检查vt索引是否越界——列索引从 0 开始，如果传了超出列数的值，GetItem可能返回空对象。

5.4 格式化字符串不生效

现象：SetNumberFormat(_T("0.0%"))调用后，单元格显示的还是原始数字。

原因：格式化只对数值类型的列生效。如果列的数据类型是字符串，格式化字符串会被忽略。另外，格式字符串的语法必须正确，写错了不会报错，只是不生效。

解决：确认该列的数据类型是数值型。如果是字符串但里面存的是数字，需要先在数据源层面转换类型，或者在绑定前处理记录集。格式字符串可以参考"0.00"、"#,##0"、"0.0%"这些常见写法，注意百分号会自动把值乘以 100。

5.5 程序退出时崩溃

现象：关闭对话框或退出程序时，出现访问违例。

原因：DataGrid 控件持有数据源的接口引用，如果数据源对象先被销毁，控件在析构时再去释放引用就会访问已释放的内存。

解决：确保数据源对象的生命周期长于控件。在对话框的OnDestroy里先解除绑定（可以调用SetRefDataSource(NULL)），然后再让记录集和连接对象析构。或者调整成员变量的声明顺序，让控件对象在数据源对象之前析构。

6. 从封装到接口：DataGrid 的设计取舍与延伸思考

回头看 DataGrid 这套机制，它最核心的取舍是：把复杂性留给接口，把简单性留给调用者。你在 MFC 里看到的CDataGrid、CColumns、CColumn是三层包装，每一层都在屏蔽底层的 COM 细节。SetRefDataSource接受LPUNKNOWN，是在用最宽泛的接口换取最大的兼容性；GetItem接受VARIANT，是在用类型灵活性换取调用便利；SetNumberFormat接受字符串，是在用表达能力换取实现复杂度。

这些取舍带来的直接后果是：入门很容易，但想深入定制就得往下挖一层。比如你想在单元格里画自定义的进度条，或者根据数据值改变单元格背景色，这些在 MFC 包装类的方法列表里找不到直接对应的函数。你需要拿到控件的底层接口，自己处理绘制事件。常见的实现思路是：通过QueryInterface拿到控件的绘制相关接口，在DrawItem或类似事件里接管绘制逻辑。

另一个值得注意的设计是数据绑定与显示控制的分离。绑定只管数据从哪来，显示控制只管数据怎么画，两者通过控件内部的机制连接，而不是通过你的代码耦合在一起。这种分离让替换数据源变得容易——只要新数据源支持相同的接口，显示层的代码几乎不用改。这也是为什么原文说“如果它升级了，你的系统几乎不作改动就可以继续为你效劳”。

验证你是否真正理解这套机制，有一个简单的办法：试着把数据源从 ADO 记录集换成一个自定义的 COM 对象，看看需要实现哪些接口才能让 DataGrid 正常显示。如果你能列出这些接口并说清每个接口的作用，说明你已经从“会用”走到了“懂原理”。

从那以后我每次在项目里用 ActiveX 控件，都会先花十分钟把它的接口层级画一遍，搞清楚哪个对象持有哪个对象的引用、谁负责释放。这个习惯帮我省掉了无数次退出崩溃的排查时间。希望帮到你。

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