企业官网建设流程全解析

简介：面向VC6环境下从事MFC界面开发的初中级程序员，这份资料围绕CListCtrl表格可编辑功能展开，重点解决单文档类扩展、动态创建控件以及编辑事件处理等实际问题。压缩包为rar格式，共58个文件、约3.8MB，其中h与cpp源码、rc资源脚本、dsp/dsw工程文件、exe可执行程序及obj/pdb等编译中间文件构成一套可直接运行的ControlTracker_Demo示例，便于对照阅读与调试。已有841人学习，说明该主题在传统Windows桌面开发中仍有稳定需求。通过示例可梳理LVS_EDITLABELS风格设置、LVN_BEGINLABELEDIT与LVN_ENDLABELEDIT消息映射、控件追踪器辅助编辑，以及窗口缩放时列表控件布局调整等关键环节，适合需要补齐MFC消息机制与自定义表格交互能力的开发者参考。

1. 别急着换控件：VC6 里让 CListCtrl 表格可编辑，难点不在“能改”

接手一个跑了很多年的 VC6 单文档项目，视图里那张 CListCtrl 报表每天有人点着看，突然有天提需求——“这表能不能直接改，别每次都导出去再改回来”。CListCtrl 表格可编辑这件事，听起来加个LVS_EDITLABELS就完了，真动手才发现它只管第一列，其余列纹丝不动。真正要处理的是三件事：单文档类扩展之后，视图、控件、文档数据三者怎么分工；控件的动态创建时机和坐标怎么算；以及一次编辑从鼠标按下到数据落盘要经过哪些事件。这套东西适合手里有 VC6 老工程、需要在报表视图上做就地编辑的开发者，也适合课程设计里被要求“实现一个可编辑表格”的学生——按下面的结构搭，代码量不大，但每条路径都得想到。

2. 总体设计：把编辑能力收进一个派生类，视图只留数据

先定一个原则：可编辑表格的所有逻辑只在一个地方，视图、对话框、任何宿主窗口都只负责“给数据、收通知”。这个原则决定后面所有实现细节。

2.1 三条备选路线，以及为什么选类派生

最省事的写法是在视图类里挂消息：双击来了就new CEdit，坐标现算，失焦就销毁。代码三十行能跑通 demo，然后第二个表格要编辑时，这套逻辑原样再抄一遍；再往后要加“Tab 跳到下一格”，两边各改一次，改漏一处就出现两个表格行为不一致。这条路我在早期项目里走过，维护成本高得离谱。

第二条路是用现成的表格控件替换 CListCtrl。第三方网格控件功能齐全，但往 VC6 老工程里塞一堆新源码，编译选项、字符集、运行库版本全要对齐，交付方往往不接受“引入外部依赖”这种改动。而且老项目的界面风格、打印预览、列宽持久化都跟 CListCtrl 绑着，换控件等于重做界面。

第三条是派生一个CGridCtrl : public CListCtrl，把编辑框、命中测试、结束编辑全部收进去。视图只做两件事：初始化列、响应“某格被改了”的通知。三种路线的差别摆出来很清楚：

选第三条。代价是要自己写两百行左右的代码，好处是这两百行写完就再也不用碰。

2.2 三态状态机：空闲、编辑中、收尾中

编辑这件事看着线性，实际上是三个状态来回跳，跳不好就出现“点了别的格子，原来那格的值没保存”。先把状态定死：

中间那个stEnding是关键。编辑框失焦会触发EN_KILLFOCUS，而“按回车结束编辑”这个动作本身又会主动调用一次结束函数，导致KillFocus在提交过程中再进来一次，重入之后可能出现“刚写进去的值被第二次提交的空字符串覆盖”。加一个状态位挡一下，问题就没了：

// GridCtrl.h —— 编辑状态用一个枚举管住，比两个 BOOL 靠谱 enum EditState { stIdle, stEditing, stEnding }; class CGridCtrl : public CListCtrl { public: CGridCtrl(); virtual ~CGridCtrl(); void BeginEdit(int nRow, int nCol); // 进入编辑态 BOOL EndEdit(BOOL bCommit); // 结束编辑，bCommit=FALSE 表示丢弃 BOOL IsEditing() const { return m_state == stEditing; } protected: CEdit* m_pEdit; // 唯一的编辑框，常驻复用，不反复 new/delete EditState m_state; int m_nRow; // 当前编辑的行 int m_nCol; // 当前编辑的列 BOOL HitCell(CPoint pt, int& nRow, int& nCol) const; CRect GetCellRect(int nRow, int nCol) const; void CommitAndMove(int nRow, int nCol, int dRow, int dCol); afx_msg void OnLButtonDown(UINT nFlags, CPoint point); afx_msg void OnLButtonDblClk(UINT nFlags, CPoint point); afx_msg void OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags); afx_msg void OnVScroll(UINT nSBCode, UINT nPos, CScrollBar* pScrollBar); afx_msg void OnHScroll(UINT nSBCode, UINT nPos, CScrollBar* pScrollBar); DECLARE_MESSAGE_MAP() };

m_pEdit只在第一次进入编辑时创建，之后一直复用，靠ShowWindow隐藏和显示切换。这样做有两个直接好处：一是不用在消息处理函数里delete this这类危险动作，二是 GDI 对象数量稳定，连续编辑几百行也不会涨。很多人第一版写成每次new CEdit、结束就delete，短时间看不出问题，跑一天之后任务管理器里该进程的 GDI 对象数一路上飚，界面开始闪烁。

2.3 数据真源只有一个：文档，不是控件

单文档程序里最容易翻车的地方，是把SetItemText当成“改了数据”。控件上显示的字符串只是渲染结果，真正的数据在文档类的数组里。正确的顺序永远是：编辑框拿到文本 → 写文档 → 用文档的值刷新单元格 → 通知其他视图。

// GridView.cpp —— 提交走同一入口，保证“写文档”和“刷显示”永远成对出现 void CGridView::OnGridCellChanged(WPARAM wParam, LPARAM lParam) { int nRow = (int)wParam; int nCol = (int)lParam; CString strText; m_wndGrid.GetEditText(strText); // 从编辑框取当前文本 CMatDoc* pDoc = GetDocument(); if (nRow < 0 || nRow >= pDoc->m_arr.GetSize()) return; pDoc->SetCellText(nRow, nCol, strText); // 先写真源 pDoc->SetModifiedFlag(TRUE); m_wndGrid.RefreshRow(nRow); // 再用真源回刷显示 // 只通知同类视图，避免自己通知自己造成死循环 UpdateAllViews(NULL, 1, NULL); }

UpdateAllViews这里必须带 hint，接收端判断lHint != 1才重刷。不带 hint 直接全量刷新的写法，在一文档多视图的结构里会自己触发自己，界面上表现为“点一下，整个表闪一下，编辑框还失焦了”。

3. 单文档视图承载：动态创建控件与列结构初始化

3.1 用 Create 而不是绑对话框资源

视图类里没有现成的对话框模板可以挂控件，列表必须动态创建。时机放在OnCreate里，尺寸先给个空矩形，真正的布局交给OnSize：

// GridView.cpp —— 视图里动态创建列表控件，必须在 OnCreate 之后才能用 GetSafeHwnd 判断 int CGridView::OnCreate(LPCREATESTRUCT lpCreateStruct) { if (CView::OnCreate(lpCreateStruct) == -1) return -1; // 不绑资源模板：单文档视图里没有可挂控件的对话框 if (!m_wndGrid.Create(WS_CHILD | WS_VISIBLE | LVS_REPORT | LVS_SINGLESEL | LVS_SHOWSELALWAYS, CRect(0, 0, 0, 0), this, IDC_GRID)) { TRACE(_T("列表控件创建失败，多半是 IDC_GRID 与其它控件 ID 冲突\n")); return -1; } // 整行选中 + 网格线是报表视图的默认观感，注意别加 LVS_EDITLABELS m_wndGrid.SetExtendedStyle(LVS_EX_FULLROWSELECT | LVS_EX_GRIDLINES); m_wndGrid.SetFont(CFont::FromHandle( (HFONT)::GetStockObject(DEFAULT_GUI_FONT))); m_wndGrid.InitColumns(); return 0; }

IDC_GRID、IDC_GRID_EDITOR这类常量，VC6 的资源编辑器不会替你生成，因为控件不是从资源模板拖出来的，手工在resource.h里加两行就好，编号从_APS_NEXT_CONTROL_VALUE往后挑，别撞上一堆对话框控件的 ID。这一点看起来是小事，撞过一次之后我养成了建控件前先全工程搜 ID 的习惯。

3.2 列结构一次性声明，别散在代码里

列定义写成一个静态表，后面加列、改宽度、改对齐只动这张表。VC6 没有_countof宏，用sizeof除法算元素个数：

// GridCtrl.cpp —— 列定义集中成一张表，序号即列索引 void CGridCtrl::InitColumns() { struct COL_DEF { LPCTSTR lpszName; int nWidth; int nFormat; }; static const COL_DEF s_cols[] = { { _T("物料编码"), 110, LVCFMT_LEFT }, { _T("物料名称"), 170, LVCFMT_LEFT }, { _T("数量"), 70, LVCFMT_RIGHT }, { _T("交期"), 100, LVCFMT_CENTER }, }; const int nCount = sizeof(s_cols) / sizeof(s_cols[0]); for (int i = 0; i < nCount; ++i) { // 第 4 个参数是列宽，返回值是新列的索引，插入失败返回 -1 if (InsertColumn(i, s_cols[i].lpszName, s_cols[i].nFormat, s_cols[i].nWidth) == -1) { TRACE(_T("插入第 %d 列失败\n"), i); } } }

列宽写成固定值只是起步，实际交付时通常会把它连同窗口位置一起存进注册表或 ini，下次打开恢复，用户调过的列宽不会被重置。这一块不属于编辑功能，但验收的时候一定会被问到。

3.3 OnSize 布局与重绘节流

// GridView.cpp —— 视图尺寸变化时让列表铺满客户区 void CGridView::OnSize(UINT nType, int cx, int cy) { CView::OnSize(nType, cx, cy); if (m_wndGrid.GetSafeHwnd() != NULL && cx > 0 && cy > 0) { m_wndGrid.MoveWindow(0, 0, cx, cy); // 滚动条交给列表自己管 } }

批量填充数据时，逐行InsertItem会看到明显的逐条刷新。老办法是前后各加一次SetRedraw(FALSE)/SetRedraw(TRUE)，中间用LockWindowUpdate也行，但别忘了成对调用——只关不开，界面会整个僵住，看起来像死机。填充两百行以内差别不大，上千行时这一对调用能把加载时间压掉一半以上。

数据要跟着文档走，Serialize里必须把单元格内容一起存，否则“改完存盘，重新打开发现还是旧值”，这个 bug 每年都有人踩：

// Doc.cpp —— 单元格数据跟着文档序列化，存盘才不丢 void CMatDoc::Serialize(CArchive& ar) { if (ar.IsStoring()) { ar << (int)m_arr.GetSize(); for (int i = 0; i < m_arr.GetSize(); ++i) { ar << m_arr[i].strCode << m_arr[i].strName; ar << m_arr[i].nQty << m_arr[i].strDate; } } else { int nCount = 0; ar >> nCount; m_arr.SetSize(nCount); for (int i = 0; i < nCount; ++i) { ar >> m_arr[i].strCode >> m_arr[i].strName; ar >> m_arr[i].nQty >> m_arr[i].strDate; } } }

CString和int都能直接进CArchive，不用手写长度前缀。真正要小心的是字段顺序，存和取的顺序必须完全一致，中间插一个字段，老文件就读废了。稳妥的做法是在文件头写一个版本号，读的时候按版本分支处理。

4. 编辑核心：命中测试、动态编辑框与键盘事件

4.1 从鼠标坐标反查行列

不要用“取选中项再猜列”的办法，LVS_EX_FULLROWSELECT下整行都是选中态，列号猜不出来。直接发LVM_SUBITEMHITTEST：

// GridCtrl.cpp —— 一次命中测试同时拿到行和列 BOOL CGridCtrl::HitCell(CPoint pt, int& nRow, int& nCol) const { LVHITTESTINFO hti; ZeroMemory(&hti, sizeof(hti)); hti.pt = pt; // 用消息而不是封装函数：VC6 的 CListCtrl 没有可靠的 GetSubItemRect 封装 ::SendMessage(m_hWnd, LVM_SUBITEMHITTEST, 0, (LPARAM)&hti); if (hti.iItem < 0 || hti.iSubItem < 0) return FALSE; // 点在空白区或表头上 nRow = hti.iItem; nCol = hti.iSubItem; return TRUE; }

LVM_SUBITEMHITTEST需要 4.71 以上版本的公用控件库，VC6 编译出来的程序在常见的 Windows 系统上都满足这个条件。点在表头或者列表下方空白区时iItem返回 -1，这个分支必须判，不然紧接着的BeginEdit(-1, ...)会把编辑框定位到一个莫名其妙的位置。

4.2 取单元格矩形：第 0 列要单独处理

这是整个功能里最容易翻车的一处。报表模式下，第 0 列并不是一个“子项”，LVM_GETSUBITEMRECT传 0 过去，不同版本返回的矩形不一致，常见现象是编辑框横跨整行，盖住后面所有列。稳定写法是分支处理：

// GridCtrl.cpp —— 第 0 列走 LVM_GETITEMRECT 再按列宽裁剪 CRect CGridCtrl::GetCellRect(int nRow, int nCol) const { CRect rc(0, 0, 0, 0); if (nCol == 0) { // 第 0 列不是子项，先取整行矩形，再裁到第一列的宽度 ::SendMessage(m_hWnd, LVM_GETITEMRECT, (WPARAM)nRow, (LPARAM)&rc); rc.right = rc.left + GetColumnWidth(0); } else { // lParam 里的 top 传入子项索引，left 传 LVIR_BOUNDS 取整个单元格 rc.top = nCol; rc.left = LVIR_BOUNDS; ::SendMessage(m_hWnd, LVM_GETSUBITEMRECT, (WPARAM)nRow, (LPARAM)&rc); } rc.right -= 1; // 让出网格线，避免编辑框压住右边框 rc.bottom -= 1; return rc; }

那两个-= 1不是强迫症。不加的话编辑框边框正好盖住列表的网格线，肉眼看上去是“格子突然少了一条线”，长时间盯着很别扭。

4.3 动态创建编辑框并定位

编辑框的父窗口设为列表本身，坐标就能直接用列表客户区的矩形，不用来回换算屏幕坐标：

// GridCtrl.cpp —— 首次进入编辑时才真正 Create，之后只做显示和定位 void CGridCtrl::BeginEdit(int nRow, int nCol) { if (nRow < 0 || nCol < 0) return; // 已经在编辑别的格子，先提交，避免用户输入的内容被静默丢弃 if (m_state == stEditing) EndEdit(TRUE); if (!EnsureVisible(nRow, FALSE)) return; // 行不在可视区，先滚动到位 CRect rc = GetCellRect(nRow, nCol); if (rc.IsRectEmpty()) return; if (m_pEdit == NULL) { m_pEdit = new CEdit; // 不用资源模板，直接 Create；父窗口是列表，坐标即客户区坐标 m_pEdit->Create(WS_CHILD | WS_VISIBLE | ES_AUTOHSCROLL | ES_LEFT, rc, this, IDC_GRID_EDITOR); m_pEdit->SetFont(GetFont()); // 字体必须跟列表一致，否则行高会跳 } m_nRow = nRow; m_nCol = nCol; m_state = stEditing; m_pEdit->SetWindowPos(NULL, rc.left, rc.top, rc.Width(), rc.Height(), SWP_NOZORDER | SWP_SHOWWINDOW); m_pEdit->SetWindowText(GetItemText(nRow, nCol)); m_pEdit->SetFocus(); m_pEdit->SetSel(0, -1); // 全选，方便直接覆盖 }

SetFont(GetFont())这行不能省。列表如果用了自定义字体（很多老项目的界面用的是宋体 9 号或者更小的字号），编辑框默认用系统字体，一进编辑态行高就变，整行文字上下跳动，视觉上非常廉价。

4.4 键盘事件：回车提交、Tab 横移、ESC 撤销

编辑框有焦点时，键盘消息先到编辑框，所以要在编辑框这一层拦截。做法是派生一个极小的子类，把三个键翻译成业务意图，具体动作交回给列表控件：

// InlineEdit.h —— 只做按键翻译，不持有任何数据 class CInlineEdit : public CEdit { public: CGridCtrl* m_pOwner; int m_nRow; int m_nCol; virtual BOOL PreTranslateMessage(MSG* pMsg) { if (pMsg->message == WM_KEYDOWN) { switch (pMsg->wParam) { case VK_RETURN: m_pOwner->CommitAndMove(m_nRow, m_nCol, 1, 0); // 回车下移一行 return TRUE; case VK_TAB: // Shift+Tab 往回走，普通 Tab 往后走，到头不跨行 m_pOwner->CommitAndMove(m_nRow, m_nCol, 0, (::GetKeyState(VK_SHIFT) < 0) ? -1 : 1); return TRUE; case VK_ESCAPE: m_pOwner->EndEdit(FALSE); // 丢弃修改 return TRUE; } } return CEdit::PreTranslateMessage(pMsg); } };

CommitAndMove里做三件事：提交当前格、算目标格、越界就停在原地。行数不够时不要自动新增行，用户按 Tab 一路按到表尾突然多出一行空记录，属于典型的“功能自作主张”。

列表本身也要处理键盘，主要是 F2 和编辑态下的方向键：

// GridCtrl.cpp —— F2 进入编辑，方向键在编辑态下先提交再移动 void CGridCtrl::OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags) { if (m_state == stIdle && nChar == VK_F2) { POSITION pos = GetFirstSelectedItemPosition(); int nRow = GetNextSelectedItem(pos); if (nRow >= 0) BeginEdit(nRow, 0); return; } CListCtrl::OnKeyDown(nChar, nRepCnt, nFlags); }

4.5 结束编辑：三条路径收口到一个函数

回车、Tab、点击别处、滚动，四条路径最终都要进EndEdit。收口越彻底，越不容易出现“某个入口忘了保存”：

// GridCtrl.cpp —— 所有结束路径的唯一出口 BOOL CGridCtrl::EndEdit(BOOL bCommit) { if (m_state != stEditing || m_pEdit == NULL) return FALSE; m_state = stEnding; // 先置位，挡住 KillFocus 重入 CString strText; m_pEdit->GetWindowText(strText); int nRow = m_nRow; int nCol = m_nCol; m_pEdit->ShowWindow(SW_HIDE); // 只隐藏，不销毁 if (bCommit) { SetItemText(nRow, nCol, strText); // 视图先同步 GetParent()->SendMessage(WM_GRID_CELLCHANGED, // 再通知宿主写文档 (WPARAM)nRow, (LPARAM)nCol); } m_state = stIdle; SetFocus(); // 焦点还给列表，方向键才能继续用 return TRUE; }

WM_GRID_CELLCHANGED用WM_USER + 100定义在头文件里，宿主窗口的ON_MESSAGE接住。这里用SendMessage而不是PostMessage，是保证“通知处理完”之后才真正回到空闲态，避免界面上出现短暂的值不一致。

5. 避坑与排查：四个能把人熬到半夜的地方

5.1 现象：双击第一列，编辑框横跨整行

原因出在GetCellRect。第 0 列不是子项，LVM_GETSUBITEMRECT传 0 过去，部分系统返回的是整行边界，编辑框就铺满了。另一种表现是编辑框跑到表头上去，因为rc没有被正确填充，残留了栈上的垃圾值。

解决办法就是 4.2 节的分支写法：第 0 列走LVM_GETITEMRECT再按GetColumnWidth(0)裁剪，其余列走LVM_GETSUBITEMRECT，并且rc.top明确赋为列索引、rc.left赋为LVIR_BOUNDS。改完之后记得把列表拉到只有两列宽的状态再看一眼，列宽小于编辑框最小宽度时，编辑框会被系统压到最小尺寸，视觉上会显得比格子窄一点，这属于正常现象，不用再折腾。

5.2 现象：点别的格子，程序直接退出

这是最凶的一个。早期的实现里，EN_KILLFOCUS的处理函数里直接delete m_pEdit并把指针置空，结果失焦消息还没返回，控件内部的代码又访问了一次自己的成员，进程就没了。另一种变体是重入：EndEdit里调用了SetFocus，焦点切走又触发一次KillFocus，第二次进来时m_pEdit已经被隐藏，取出来的文本是空的，把刚写进去的值覆盖成空白。

处理办法两条：编辑框常驻复用，永远不在消息处理过程中销毁；状态位stEnding挡重入，看到这个状态就直接返回。如果确实需要在某个时机彻底销毁控件（比如视图关闭），用PostMessage投递一个自定义消息，等消息循环转到下一次再处理，别在通知回调里同步删。

5.3 现象：滚动列表之后，编辑框飘在别的行上

编辑框是列表的子窗口，但列表的滚动是内部绘制偏移，子窗口不跟着动。用户滚一下滚轮，编辑框还停在原来的客户区坐标，看上去就像是飘到了另一行数据上，这时候再按回车，值会写进错的行。

处理办法是滚动即提交：OnVScroll/OnHScroll里先EndEdit(TRUE)再走基类。滚轮消息更麻烦一点，WM_MOUSEWHEEL不一定进OnVScroll，可以在PreTranslateMessage里判断一下，或者干脆在OnMouseWheel里统一提交。另外，拖拽表头改变列宽也会导致坐标变化，稳妥的做法是在HDN_ENDTRACK通知里也结束一次编辑。

5.4 现象：当场改完是对的，存盘再打开又是旧值

SetItemText只改了控件显示，文档数组一动没动，Serialize自然存的是老数据。另一种更隐蔽：文档改了，但SetModifiedFlag忘了调，用户点关闭时没有任何提示，改动直接丢掉，事后完全查不出问题出在哪。

统一入口能解决大半：所有提交都走OnGridCellChanged一个函数，里面固定顺序——写文档、置修改标记、刷显示、通知其他视图。再加一条自检习惯：改完值之后立刻按 Ctrl+S，关掉程序重新打开，值还在，这条链路才算通。

6. 验收与答辩：怎么证明这张表是真能用

功能跑通和能交付是两回事。验收时不要只演示“双击能改”，按下面这张表逐条过，每条都有明确的判定标准，答辩现场照着点一遍，比讲十分钟设计思路有说服力。

最后一行是很多人会忽略的检查。答辩时把任务管理器打开，切到“进程”页把 GDI 对象列显示出来，编辑前后各记一次数字，差值控制在个位数以内就算合格。这一招比任何口头说明都管用，评审一看就知道你是真跑过长时间测试的。

还有一个小技巧：准备一份“问题清单”放在手边，把上面 5.1 到 5.4 那四条现象和对应的排查路径写下来。现场如果被问到“如果编辑框位置不对你怎么查”，直接说“先看第一列还是其他列，第一列走的是LVM_GETITEMRECT，其他列走LVM_GETSUBITEMRECT，两套分支分开验证”，这种回答的分量远高于“我调试过”。

我在第一个带编辑功能的报表项目上栽过一次：功能演示全过，交付第二天用户报“改了三行只存住一行”，查了半天是滚动时编辑框没提交，值写到了错的行上。从那以后，我每次做这类就地编辑，都强制走一遍“编辑→滚动→再编辑→存盘→重开”的完整链路，一步都不跳。希望这套结构能帮到你，少走一遍我走过的夜路。

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