简介围绕 VC6 环境下 MFC 中 CListCtrl 表格可编辑功能展开面向需要扩展单文档应用界面、实现列表项就地编辑与交互处理的 C/MFC 开发者。内容涉及动态创建列表控件、设置可编辑标签风格、响应 LVN_BEGINLABELEDIT 与 LVN_ENDLABELEDIT 消息以及窗口尺寸变化时的布局调整并结合控件追踪器示例说明编辑、选择与拖动等交互的衔接方式对编辑状态同步、输入校验和结果更新也有可借鉴的处理思路。压缩包共 58 个文件、约 3.8MB包含 h/cpp 源码、dsp/dsw 工程文件、rc/res/ico 界面资源及 exe、调试中间文件便于直接打开工程对照编译和调试。已有 841 人学习适合作为 VC6 单文档类扩展与可编辑表格实现的参考样例帮助梳理消息映射、控件生命周期和界面资源组织思路。1. CListCtrl 表格可编辑一个看着五分钟、实际能磨一天的需求CListCtrl 表格可编辑这件事在 VC6 单文档工程里出现的频率高得离谱列表把数据列出来了需求方看一眼就问“能不能直接改”。很多人的第一反应是加LVS_EDITLABELS动手之后才发现它只管第一列、只认键盘、点到别处还不提交再往上叠一个 CEdit 盖在单元格上焦点、滚动、中文输入法、列宽拖动又全是坑。这里要说清的是这套做法解决的是“单文档/对话框程序里 CListCtrl 任意列的原地编辑”技术栈是 MFC 6.0 动态创建控件 事件处理不引入第三方网格控件适合还在维护 VC6 老工程、又不想为了一个表格引入整套新库的人。2. 选型先立住CListCtrl 可编辑的四条路和它们的边界动手之前先把方案摆平比写完再推翻重来划算得多。MFC 的 CListCtrl 从设计上就不是一个编辑控件它只提供报告模式下的显示和选择任何“可编辑”都是在外围补出来的。补法有四种代价和适用范围差得很远选错了后面全是返工。2.1 LVS_EDITLABELS 的能力上限只解决第一列LVS_EDITLABELS是 CListCtrl 自带的一个风格位加上去之后点中某项再点一次第一列的文本会原地变成可编辑状态并抛出LVN_BEGINLABELEDIT和LVN_ENDLABELEDIT两个通知。它的好处是零成本一行ModifyStyle就能用坏处是硬伤太多只能编辑第 0 列编辑框的创建、定位、销毁都由系统内部代码完成你插不上手编辑框样式固定想要一个下拉框、想要限制只能输数字都得在LVN_ENDLABELEDIT里“事后驳回”。还有一个更隐蔽的问题它的编辑框是系统的 label edit 窗口父窗口不是你PreTranslateMessage收不到它的按键想拦 ESC 或者回车提交只能依赖默认行为。在数据录入场景里这个限制很致命——用户按回车默认是提交并跳回列表但你往往希望回车后直接进入下一行同一列的编辑状态这在LVS_EDITLABELS上做不到。所以这条路的定位很清楚只读表格里偶尔改个名字、改个备注够用只要涉及多列、涉及输入校验、涉及连续录入直接放弃别在这上面浪费时间。2.2 原地编辑CEdit 盖在单元格上真正能覆盖任意列的做法只有一个自己在列表控件上动态创建一个 CEdit把它挪到目标单元格的矩形位置上编辑结束时读回文本再SetItemText。这套东西业内叫原地编辑in-place edit本质是把列表控件当成一块画布编辑框是浮在上面的一个子窗口。关键点有三个。第一是坐标系编辑框的父窗口必须设成列表控件本身坐标用列表的客户区坐标这样滚动时两者能一起动如果父窗口设成桌面或者 View滚动之后编辑框就会脱离原来的位置变成“贴错位置”。第二是矩形计算必须精确拿到第 nItem 行第 nSubItem 列那个格子的矩形不能拿整行矩形凑合否则编辑框会横跨好几列。第三是生命周期创建一次、反复复用比每次new一个再delete稳得多VC6 下频繁创建销毁子窗口很容易在退出时留下野句柄。这条路的成本在于要自己处理一堆边角回车提交、ESC 取消、点别处提交、滚动时跟随或关闭、列宽拖动后重新定位、中文输入法的候选窗口。好处是全程可控任何一列都能编辑输入校验可以在提交前做交互想怎么改就怎么改。2.3 对话框式编辑与整行编辑的适用场景如果业务允许还有一种更省事的做法双击某行弹一个模态对话框把所有字段摊开让用户填确定后一次性回写整行。这种方案在 VC6 时代非常常见做起来最快事件处理也最简单——不需要管焦点、不需要管滚动、不需要管输入法对话框本身就是标准控件容器。代价是交互重。用户改一个单元格的数字要先弹窗、再定位、再关窗连续录入几十行会非常难受。它适合“行数据字段多、单条编辑耗时长、修改频率低”的场景比如配置项维护不适合“一屏几十行、逐格微调”的场景比如价格表、库存表。还有一种折中是整行编辑双击行之后把整行的每一列都换成编辑框或者只把当前行切成输入态一次性提交。实现上比单格原地编辑复杂因为要同时维护多个编辑框的创建、Tab 顺序、提交时机但比弹窗体验好适合列数固定且不多的表格。选型时按“编辑频率 × 列数”两个维度判断即可频率高、列数少就用单格原地编辑反过来就上对话框。2.4 单文档框架里的类扩展位置为什么放在派生类而不是 ViewVC6 单文档程序的结构是 CWinApp → CFrameWnd → CView → 控件。CListCtrl 通常是 CView 里的一个成员或者 CView 本身就是一个CListCtrl派生类CListView形式。可编辑逻辑放哪儿直接决定了后面好不好维护。放到 View 里最省事所有消息映射都写在CXXXView上OnLButtonDblClk、PreTranslateMessage、滚轮消息一把抓。问题是这套逻辑一旦写进 View就绑死在这个视图上下一个工程想复用只能整段复制粘贴改一处漏一处。而且 View 里的消息又多又杂OnDraw、OnSize、菜单命令全在一个 cpp 里编辑逻辑混进去之后排查问题会非常痛苦。更合适的做法是先派生一个CListCtrl子类把编辑框的创建、定位、提交、取消、键盘拦截全部封在里面View 只负责Create它、给它喂数据、接收它抛上来的“编辑完成”通知。这样类扩展就是一次性的视图类只需要包含头文件编辑能力就跟着来了跟单文档还是对话框没关系。这也是后面第 6 章要抽基类的原因——先把边界划清楚再谈复用。3. 动态创建控件把 CEdit 精确盖到单元格上方案定了就开始动手。这一章给出一套能直接跑的骨架派生一个 CListCtrl 子类在里面挂一个 CEdit 成员双击进入编辑回车/ESC/失焦三条路径退出。代码按 VC6 MFC 6.0 写注意里面有几个 VC6 特有的宏缺失问题需要自己补定义。3.1 打开扩展风格与准备字体列表控件要先把“能编辑”的基础条件铺好整行选中、网格线、选中项失焦后仍然高亮否则编辑框一拿到焦点原来那行就变灰用户看不出来在改哪一行、双击激活。扩展风格通过LVS_EX_*系列设置VC6 的commctrl.h里这些宏都有但列表控件需要 comctl32.dll 4.71 以上版本系统里一般是满足的。// EditableListCtrl.h #pragma once // VC6 的 commctrl.h 是 IE4 之前的版本这两个消息宏可能没有定义必须自己补 #ifndef LVM_GETSUBITEMRECT #define LVM_GETSUBITEMRECT (LVM_FIRST 56) #endif #ifndef LVM_SUBITEMHITTEST #define LVM_SUBITEMHITTEST (LVM_FIRST 57) #endif #define IDC_INPLACE_EDIT 1001 class CEditableListCtrl : public CListCtrl { public: CEditableListCtrl(); virtual ~CEditableListCtrl(); void BeginEdit(int nItem, int nSubItem); // 进入编辑 void EndEdit(BOOL bCancel FALSE); // 退出编辑 protected: CEdit m_wndEdit; // 复用的编辑框只创建一次 CFont m_fontEdit; // 与列表保持一致的字体 int m_nEditItem; // 当前正在编辑的行-1 表示没有 int m_nEditSub; // 当前正在编辑的列 CString m_strOldText; // 编辑前的原文用于 ESC 回滚 int GetColumnWidth(int nCol); void PlaceEdit(int nItem, int nSubItem); int SubItemHitTest(LVHITTESTINFO* pHti); afx_msg void OnLButtonDblClk(UINT nFlags, CPoint point); afx_msg void OnEditKillFocus(); afx_msg void OnDestroy(); virtual BOOL PreTranslateMessage(MSG* pMsg); DECLARE_MESSAGE_MAP() };风格设置放在PreSubclassWindow或者OnCreate之后统一做一次别散在各处。LVS_EX_FULLROWSELECT和LVS_EX_GRIDLINES是必开的LVS_EX_TWOCLICKACTIVATE不要开——它会跟双击编辑抢消息导致第一次双击被吞掉。字体方面VC6 默认给控件用的是SYSTEM_FONT中文在编辑框里会发虚、行高也对不齐统一用DEFAULT_GUI_FONT最稳列表和编辑框用同一份。// EditableListCtrl.cpp CEditableListCtrl::CEditableListCtrl() { m_nEditItem -1; m_nEditSub -1; } void CEditableListCtrl::OnInitialUpdateStyle() // 放在 OnCreate 之后调用 { SetExtendedStyle(GetExtendedStyle() | LVS_EX_FULLROWSELECT | LVS_EX_GRIDLINES); m_fontEdit.CreateStockObject(DEFAULT_GUI_FONT); SetFont(m_fontEdit); // 列表本身也用同一字体保证行高对齐 }CreateStockObject(DEFAULT_GUI_FONT)是 VC6 里少数几个能直接拿到中文字体的可靠方式比CreateFont拼一堆参数省事。注意m_fontEdit要是成员变量不能是局部变量——字体对象析构之后控件引用的句柄就失效了表现是界面文字突然变成乱码或者小方块。这种问题调试时看不出来跑一段时间才崩属于典型的“看着能跑实际在漏水”。3.2 用 LVM_GETSUBITEMRECT 精确算格子编辑框盖不准九成问题出在矩形计算。很多人第一反应是GetItemRect(nItem, rc, LVIR_BOUNDS)拿到的却是整行的矩形编辑框会横跨所有列。正确做法是走LVM_GETSUBITEMRECT但这个 API 有个非常反直觉的约定它复用RECT结构的前两个成员当输入参数调用前必须先把left填成列号、top填成行号返回时这两个值被覆盖成真实坐标。不预先赋值的话拿回来的矩形基本是垃圾数据。还有一个坑第 0 列不能用LVM_GETSUBITEMRECT对它调用会返回失败或者全零。第 0 列得走LVM_GETITEMRECT拿整行矩形再把右边界改成第 0 列的宽度。int CEditableListCtrl::GetColumnWidth(int nCol) { CHeaderCtrl* pHeader GetHeaderCtrl(); if (pHeader NULL) return 0; HDITEM hd; ::ZeroMemory(hd, sizeof(hd)); hd.mask HDI_WIDTH; if (!pHeader-GetItem(nCol, hd)) return 0; return hd.cxy; } void CEditableListCtrl::PlaceEdit(int nItem, int nSubItem) { CRect rcCell(0, 0, 0, 0); if (nSubItem 0) { // 第 0 列LVM_GETSUBITEMRECT 不适用用整行矩形截出首列宽度 rcCell.top nItem; GetItemRect(nItem, rcCell, LVIR_BOUNDS); rcCell.right rcCell.left GetColumnWidth(0); } else { // 重点left 放列号top 放行号这两个是“入参”不是输出 rcCell.left nSubItem; rcCell.top nItem; SendMessage(LVM_GETSUBITEMRECT, (WPARAM)nItem, (LPARAM)rcCell); } // 格子已经滚出可视区就别显示了否则编辑框会飘在列表外面 CRect rcClient; GetClientRect(rcClient); if (rcCell.bottom rcClient.bottom || rcCell.top rcClient.top) { m_wndEdit.ShowWindow(SW_HIDE); return; } m_wndEdit.MoveWindow(rcCell); m_wndEdit.ShowWindow(SW_SHOW); m_wndEdit.SetFocus(); m_wndEdit.SetSel(0, -1); // 全选用户双击进来直接覆盖输入 }MoveWindow一定要在ShowWindow之前顺序反了会看到编辑框从 (0,0) 闪一下再跳到目标位置观感很差。另外SetFocus之后不要再回头调用列表的SetFocus否则输入会丢失这个顺序问题在第 4 章还会展开。3.3 创建、子类化与显示编辑框编辑框不需要每次重建构造函数里不创建第一次进入编辑时创建一次之后一直复用。创建时的关键参数是父窗口和样式父窗口必须是this列表控件本身样式至少要WS_CHILD | ES_AUTOHSCROLL | ES_NOHIDESELES_NOHIDESEL是为了让编辑框在失焦时仍显示选中内容用户体验更连贯。不要加WS_BORDER边框会和列表网格线打架看上去像多了一条线。void CEditableListCtrl::BeginEdit(int nItem, int nSubItem) { if (nItem 0 || nSubItem 0) return; // 已有编辑在进行先提交掉保证同一时刻只有一个编辑框 if (m_nEditItem 0) EndEdit(FALSE); m_nEditItem nItem; m_nEditSub nSubItem; m_strOldText GetItemText(nItem, nSubItem); if (!::IsWindow(m_wndEdit.GetSafeHwnd())) { // 父窗口必须是列表自己坐标才是客户区坐标滚动才能跟着走 if (!m_wndEdit.Create(WS_CHILD | ES_AUTOHSCROLL | ES_NOHIDESEL, CRect(0, 0, 0, 0), this, IDC_INPLACE_EDIT)) { m_nEditItem -1; return; } m_wndEdit.SetFont(m_fontEdit); } m_wndEdit.SetWindowText(m_strOldText); PlaceEdit(nItem, nSubItem); }这里用的是“直接 Create 到父窗口”的方式没有走资源里的对话框控件再SubclassDlgItem。两种都行但如果是单文档视图里嵌列表资源里加一个 IDC_EDIT 再子类化反而绕多一个资源、多一步GetDlgItem不如直接 Create 干净。代价是编辑框的 ID 要自己定义并且要确保不和工程里已有的控件 ID 冲突1001这种范围值建议先全局搜一遍再定。3.4 提交、取消与数据回写退出编辑有三条路径回车提交、ESC 取消、焦点转移到别处提交。三条路最后都汇到EndEdit用一个bCancel参数区分。函数里先取文本、再隐藏窗口、再清状态最后才SetItemText——顺序反了容易在SetItemText触发的重绘里又踩到编辑框。void CEditableListCtrl::EndEdit(BOOL bCancel) { if (m_nEditItem 0 || !::IsWindow(m_wndEdit.GetSafeHwnd())) return; CString strNew; m_wndEdit.GetWindowText(strNew); int nItem m_nEditItem; int nSub m_nEditSub; m_nEditItem -1; // 先清状态避免 SetItemText 重入 m_nEditSub -1; m_wndEdit.ShowWindow(SW_HIDE); if (bCancel || strNew m_strOldText) return; // 取消或没改动直接返回 SetItemText(nItem, nSub, strNew); // 抛给父窗口让 View 同步到自己的数据模型/数据库 CWnd* pParent GetParent(); if (pParent ! NULL) pParent-PostMessage(WM_USER 100, (WPARAM)nItem, (LPARAM)nSub); }PostMessage而不是SendMessage是有意的SendMessage会在当前调用栈里同步执行父窗口的处理逻辑如果父窗口里又去刷新列表、又去查数据库重入风险很高。PostMessage把它推到消息队列等当前这轮消息处理完再执行安全得多。父窗口收到之后自己用GetItemText取值即可或者你干脆在消息里带一个结构体指针但那样要管内存释放不如让父窗口自己取。4. 事件处理的分寸键盘、滚动、列宽与输入法编辑框盖上去只是开始真正决定好不好用的是事件处理这一层。VC6 下没有现成的事件框架全靠消息映射和PreTranslateMessage手工拦截分寸拿捏不好就会出现“按回车没反应”“滚一下轮编辑框留在原地”“中文打一半变乱码”这类问题。这一章把四类高频事件拆开讲。4.1 PreTranslateMessage 拦截回车与 ESC 的分寸编辑框是列表的子窗口用户按下的键先进入消息队列再由 MFC 的消息泵沿着父窗口链调用PreTranslateMessage。这个“沿父链走”的行为是 MFC 的CWnd::WalkPreTranslateTree实现的意味着列表控件的PreTranslateMessage能收到子编辑框的按键——这是一个很好用的口子不用给 CEdit 单独派生一个类就能拦回车和 ESC。BOOL CEditableListCtrl::PreTranslateMessage(MSG* pMsg) { if (m_nEditItem 0 ::IsWindow(m_wndEdit.GetSafeHwnd()) pMsg-hwnd m_wndEdit.GetSafeHwnd()) { if (pMsg-message WM_KEYDOWN) { switch (pMsg-wParam) { case VK_RETURN: EndEdit(FALSE); return TRUE; // 吃掉别让编辑框再处理 case VK_ESCAPE: EndEdit(TRUE); return TRUE; case VK_TAB: EndEdit(FALSE); // 这里可以接“跳到下一格”的逻辑见 6.1 return TRUE; } } } return CListCtrl::PreTranslateMessage(pMsg); }分寸在于“只拦自己该拦的”。判断条件里必须带上pMsg-hwnd m_wndEdit.GetSafeHwnd()否则列表本身的按键比如方向键移动选中行也会被误吃。返回TRUE表示消息已处理、不再往下传返回FALSE则继续默认流程。有人在PreTranslateMessage里不判断 hwnd直接把所有WM_KEYDOWN都拦下来结果列表的键盘导航全废用户只能靠鼠标这种问题在验收时很容易被漏过去。还有一点VK_TAB在单文档程序里默认是对话框导航用的编辑框作为普通子窗口其实不参与 Tab 循环但为了后续扩展比如 Tab 跳下一格在这里拦掉比在后面补要省事。4.2 编辑框的位置如何跟滚动保持一致列表滚动分两种滚轮和滚动条。滚轮消息WM_MOUSEWHEEL会先发给有焦点的窗口编辑框有焦点时它会收到这个消息但它自己不认识会往上抛给列表列表再滚动内容——这时候编辑框还留在原来的屏幕位置上跟单元格错位了。处理方式有两种。简单粗暴的是滚动即取消编辑BOOL CEditableListCtrl::OnMouseWheel(UINT nFlags, short zDelta, CPoint pt) { EndEdit(TRUE); // 滚动就放弃本次编辑避免错位 return CListCtrl::OnMouseWheel(nFlags, zDelta, pt); }温和一点的是滚动结束后重新定位void CEditableListCtrl::OnVScroll(UINT nSBCode, UINT nPos, CScrollBar* pScrollBar) { CListCtrl::OnVScroll(nSBCode, nPos, pScrollBar); if (m_nEditItem 0) { // 滚动完成后按当前行列重新算一次矩形编辑框跟着走 PlaceEdit(m_nEditItem, m_nEditSub); } }选哪个看业务。数据录入场景里用户滚动往往是想看别的行这时候保留编辑框反而碍事取消更合理而“看大表格边改边翻”的场景跟随更顺手。我的习惯是先做取消等真的有人抱怨了再改成跟随——因为跟随要处理“单元格滚出可视区”的情况PlaceEdit里那段隐藏逻辑就是为它准备的边界多容易翻车。4.3 列宽拖动与列重排时的坐标重算列表头是可以拖的用户把某列拉宽之后编辑框还停在原来的宽度上看着就像贴歪了。头控件是列表的子窗口它发出的HDN_BEGINTRACK、HDN_ENDTRACK、HDN_ITEMCHANGED通知会先到列表再往上抛。在列表子类里用ON_NOTIFY_REFLECT接住就能在拖动结束时重新定位。BEGIN_MESSAGE_MAP(CEditableListCtrl, CListCtrl) ON_WM_LBUTTONDBLCLK() ON_WM_MOUSEWHEEL() ON_WM_VSCROLL() ON_WM_DESTROY() ON_CONTROL(EN_KILLFOCUS, IDC_INPLACE_EDIT, OnEditKillFocus) ON_NOTIFY_REFLECT(HDN_ENDTRACK, OnHeaderEndTrack) END_MESSAGE_MAP() void CEditableListCtrl::OnHeaderEndTrack(NMHDR* pNMHDR, LRESULT* pResult) { if (m_nEditItem 0) { // 列宽变了编辑框宽度必须跟着变否则文字会被截断 PlaceEdit(m_nEditItem, m_nEditSub); } *pResult 0; }ON_NOTIFY_REFLECT和ON_NOTIFY的区别要拎清头控件是列表的子窗口通知默认发往列表的父窗口也就是 View如果你在 View 里用ON_NOTIFY接也能收到但那样编辑逻辑就漏到 View 里去了用ON_NOTIFY_REFLECT是把通知“反射”回列表自己处理封装才完整。VC6 的 MFC 支持反射宏名就是ON_NOTIFY_REFLECT别写成ON_NOTIFY_REFLECT_EX那是后面版本才有的。还有一处容易漏列被拖动重排之后nSubItem和实际显示位置的对应关系变了。如果你的表格不允许拖动列直接在头控件上禁掉HDS_DRAGDROP最省事允许拖的话PlaceEdit里的列号要用LVM_MAPINDEXTOID/LVM_MAPIDTOINDEX换算或者干脆在重排时结束编辑。4.4 中文输入法与焦点的先后顺序中文输入法是 VC6 可编辑表格里最容易出玄学的地方。表现是用户切到拼音输入法敲第一个字母编辑框突然消失或者候选窗口弹出来但按键进不去编辑框或者打完字按空格上屏第一个字丢失。原因通常在于失焦处理写得太粗暴。编辑框的EN_KILLFOCUS会在焦点转移到任何其他窗口时触发输入法的候选窗口、状态窗口在某些实现下会短暂抢焦点于是OnEditKillFocus被调用里面无条件EndEdit(FALSE)编辑框就没了。正确的做法是在失焦时先判断焦点到底去了哪儿void CEditableListCtrl::OnEditKillFocus() { // 输入法候选窗口抢焦点时GetFocus() 可能返回 NULL 或者输入法自己的窗口 CWnd* pFocus CWnd::GetFocus(); if (pFocus ! NULL pFocus-GetSafeHwnd() m_wndEdit.GetSafeHwnd()) return; // 焦点其实还在编辑框上忽略 // 延迟提交给输入法一个上屏的机会避免第一个字被吞 PostMessage(WM_COMMIT_EDIT, 0, 0); }PostMessage而不是直接EndEdit是给自己留一条“等一下”的路输入法上屏是会往编辑框里塞字符的如果失焦的瞬间就销毁编辑框塞进去的字自然就丢了。延后一轮消息再提交绝大多数情况下字符已经落到编辑框里了。另外编辑框创建时如果没设字体VC6 会给它一个默认的System字体中文显示成方块或者大小不对。这一点在 3.1 已经用DEFAULT_GUI_FONT解决但要注意SetFont之后编辑框的高度不会自动变MoveWindow用的矩形高度是从列表单元格拿的如果字体行高比单元格高文字会被裁掉——所以列表本身的字体必须和编辑框统一这是两者行高对齐的唯一办法。5. 避坑与排查VC6 下可编辑表格的五个翻车现场下面这五条基本覆盖了这套方案在 VC6 里九成以上的故障。每条按“现象 → 原因 → 解决”写遇到问题可以直接对号入座。5.1 双击第一列能编辑双击第二列没反应现象双击第 0 列正常进入编辑双击第 1 列之后的位置毫无反应鼠标怎么点都不出现编辑框。原因行列判断用的是GetItemRect或者HitTest后者只返回行号不返回列号又或者用了LVM_GETSUBITEMRECT但没给RECT的left、top预填列号和行号函数返回失败rcCell还是全零MoveWindow到一个零尺寸矩形看起来就是“没反应”。解决命中测试走LVM_SUBITEMHITTEST它返回的LVHITTESTINFO::iSubItem才是列号矩形计算按 3.2 的写法分两种情况处理第 0 列单独走LVM_GETITEMRECT。VC6 的commctrl.h里可能没有LVM_SUBITEMHITTEST宏先补定义再编译别指望链接器给你提示。int CEditableListCtrl::SubItemHitTest(LVHITTESTINFO* pHti) { pHti-flags LVHT_ONITEM; return (int)SendMessage(LVM_SUBITEMHITTEST, 0, (LPARAM)pHti); }5.2 编辑框第一次显示正常第二次位置错乱或者跑到左上角现象第一次双击编辑没问题提交后再双击另一行编辑框出现在 (0,0) 附近或者宽度只有几个像素。原因Create时的初始矩形是全零之后靠MoveWindow定位如果某次PlaceEdit中途返回比如单元格滚出可视区那段逻辑编辑框就被ShowWindow(SW_HIDE)了但状态m_nEditItem没清下一次BeginEdit判断“已有编辑在进行”走EndEdit(FALSE)EndEdit里因为窗口已隐藏、文本没变又提前返回状态就错乱了。解决PlaceEdit里隐藏编辑框的分支要同步把状态清掉或者干脆不在PlaceEdit里做隐藏判断改成在OnVScroll里判断单元格是否可见不可见就EndEdit(TRUE)。状态机要保持单一入口进入编辑只有BeginEdit退出只有EndEdit中间任何分支都不许偷偷改m_nEditItem。5.3 输入中文时第一个字被吞或者编辑框直接消失现象切到拼音输入法敲第一个键编辑框消失或者候选词上屏后只进去一半。原因EN_KILLFOCUS里无条件调用了EndEdit输入法候选窗口弹出时短暂抢走焦点触发失焦编辑框被销毁或隐藏后续字符自然进不去。解决失焦处理改成延迟提交见 4.4并且在EndEdit里先GetWindowText再隐藏窗口保证已经落到编辑框里的字能被读出来。如果你们的输入法比较特殊还可以在EndEdit之前发一个WM_IME_COMPOSITION相关的处理但绝大多数情况下延迟一轮消息就够了。5.4 拖动列宽之后编辑框停在旧位置、宽度也不对现象编辑状态下拖动表头分隔线列变宽了编辑框还是原样右边露出一截空白。原因没有处理头控件的HDN_ENDTRACK或者用ON_NOTIFY接在了 View 上列表子类里收不到。解决在列表子类里用ON_NOTIFY_REFLECT(HDN_ENDTRACK, ...)接住回调里重新PlaceEdit。另外如果表格允许列拖动重排同时要处理HDN_ENDDRAG否则列顺序一变nSubItem和显示位置就对不上了最简单的办法是直接禁掉列拖动。5.5 程序退出时崩溃或者 Debug 版报断言现象关闭主窗口时弹出断言或者干脆无提示退出Release 版偶发Debug 版必现。原因窗口销毁顺序问题。列表控件先被销毁子编辑框跟着销毁但m_wndEdit的 C 对象还在成员析构时 MFC 会去Detach一个已经无效的句柄或者EndEdit在WM_DESTROY之后被调用里面还去SetItemText访问了已经析构的列表内部数据。解决在列表的OnDestroy里先把编辑状态清干净再交给基类。void CEditableListCtrl::OnDestroy() { m_nEditItem -1; // 先断状态防止后续重入 m_nEditSub -1; if (::IsWindow(m_wndEdit.GetSafeHwnd())) m_wndEdit.DestroyWindow(); // 主动销毁子窗口别等父窗口连带销毁 CListCtrl::OnDestroy(); }DestroyWindow之后再走基类顺序不能反。这一条是所有动态创建子窗口的通病不只是列表编辑养成“谁创建谁销毁、销毁在基类之前”的习惯能省掉大量退出崩溃。6. 收口把编辑能力抽成基类附一份上线自检清单前面五章的东西散在 View 里也能跑但下一个工程就得重来一遍。真正省时间的是把编辑能力抽成一个独立的CEditableListCtrlView 只做三件事创建它、喂数据、接通知。抽的时候有两个细节值得说一下。第一个是“编辑完成”的通知方式。最开始我用的是PostMessage(WM_USER100, ...)父窗口在OnEditDone里自己去GetItemText。后来发现同一个 View 里有好几个列表消息没法区分来源只好在WPARAM里塞控件 IDLPARAM塞打包后的行列号凑合能用但写起来别扭。更干净的方案是让基类持有一个回调接口class IEditNotify { public: virtual void OnCellEdited(CWnd* pList, int nItem, int nSubItem, LPCTSTR lpszNewText) 0; }; // CEditableListCtrl 里加一个成员 IEditNotify* m_pNotify; // EndEdit 里改成 if (m_pNotify ! NULL) m_pNotify-OnCellEdited(this, nItem, nSub, strNew);View 实现这个接口EndEdit直接回调不用跟消息号打交道也不用担心多列表串消息。代价是 View 和列表之间多了一层依赖但 VC6 工程本来就没多少解耦可言这点代价换来的是可读性值。第二个是 Tab 跳下一格。这块逻辑放在基类里最好因为要算“当前是不是最后一列、是不是最后一行、要不要自动新增一行”全都跟列表数据相关。实现上就是在PreTranslateMessage的VK_TAB分支里算下一格坐标BeginEdit之前先EnsureVisible保证目标行在可视区内否则编辑框会创建在一个看不见的位置上。void CEditableListCtrl::EditNextCell() { int nItem m_nEditItem; int nSub m_nEditSub 1; int nCols GetHeaderCtrl()-GetItemCount(); if (nSub nCols) // 到行尾跳下一行第一列 { nSub 0; nItem nItem 1; } if (nItem GetItemCount()) // 到最后一行停在原地 return; EnsureVisible(nItem, FALSE); // 先滚动过去再建编辑框 BeginEdit(nItem, nSub); }抽完基类之后这个文件大概 300 行左右把编辑框创建、矩形计算、键盘拦截、滚动处理、销毁清理全包了。剩下的问题基本都在使用方数据量大的时候SetItemText触发的重绘会卡那是SetRedraw(FALSE)的事列表项特别多的时候用虚拟列表LVS_OWNERDATA那套跟原地编辑配合要另写一版GetItemText得换成你自己维护的数据源不在这次的范围内。最后给一份上线前的自检清单我在几个 VC6 老工程上都是照着这张表过一遍才敢交付检查项通过标准常见问题第 0 列与其余列双击任意列都能进入编辑位置准确第 0 列走错 API矩形全零回车 / ESC / 失焦三条路径行为一致无残留ESC 后文本没回滚中文输入法拼音、五笔打完字完整上屏首字丢失、编辑框消失滚动滚轮和滚动条都不留错位框编辑框挂在原位置不动列宽拖动编辑框宽度随列变化只在 View 里接了通知连续编辑连续双击、Tab 切换 20 次不崩状态机被中途改动退出关闭主窗口无断言、无崩溃OnDestroy 顺序写反大数据量500 行以上滚动流畅没关重绘、逐行 SetItemText从那以后我每次接手 VC6 的表格改造都强制先把这张表过一遍尤其是第 0 列和退出这两项——它们不会在开发阶段暴露只会在演示或者交付现场给你一下。希望帮到你。本文还有配套的精品资源点击获取
简介围绕 VC6 环境下 MFC 中 CListCtrl 表格可编辑功能展开面向需要扩展单文档应用界面、实现列表项就地编辑与交互处理的 C/MFC 开发者。内容涉及动态创建列表控件、设置可编辑标签风格、响应 LVN_BEGINLABELEDIT 与 LVN_ENDLABELEDIT 消息以及窗口尺寸变化时的布局调整并结合控件追踪器示例说明编辑、选择与拖动等交互的衔接方式对编辑状态同步、输入校验和结果更新也有可借鉴的处理思路。压缩包共 58 个文件、约 3.8MB包含 h/cpp 源码、dsp/dsw 工程文件、rc/res/ico 界面资源及 exe、调试中间文件便于直接打开工程对照编译和调试。已有 841 人学习适合作为 VC6 单文档类扩展与可编辑表格实现的参考样例帮助梳理消息映射、控件生命周期和界面资源组织思路。1. CListCtrl 表格可编辑一个看着五分钟、实际能磨一天的需求CListCtrl 表格可编辑这件事在 VC6 单文档工程里出现的频率高得离谱列表把数据列出来了需求方看一眼就问“能不能直接改”。很多人的第一反应是加LVS_EDITLABELS动手之后才发现它只管第一列、只认键盘、点到别处还不提交再往上叠一个 CEdit 盖在单元格上焦点、滚动、中文输入法、列宽拖动又全是坑。这里要说清的是这套做法解决的是“单文档/对话框程序里 CListCtrl 任意列的原地编辑”技术栈是 MFC 6.0 动态创建控件 事件处理不引入第三方网格控件适合还在维护 VC6 老工程、又不想为了一个表格引入整套新库的人。2. 选型先立住CListCtrl 可编辑的四条路和它们的边界动手之前先把方案摆平比写完再推翻重来划算得多。MFC 的 CListCtrl 从设计上就不是一个编辑控件它只提供报告模式下的显示和选择任何“可编辑”都是在外围补出来的。补法有四种代价和适用范围差得很远选错了后面全是返工。2.1 LVS_EDITLABELS 的能力上限只解决第一列LVS_EDITLABELS是 CListCtrl 自带的一个风格位加上去之后点中某项再点一次第一列的文本会原地变成可编辑状态并抛出LVN_BEGINLABELEDIT和LVN_ENDLABELEDIT两个通知。它的好处是零成本一行ModifyStyle就能用坏处是硬伤太多只能编辑第 0 列编辑框的创建、定位、销毁都由系统内部代码完成你插不上手编辑框样式固定想要一个下拉框、想要限制只能输数字都得在LVN_ENDLABELEDIT里“事后驳回”。还有一个更隐蔽的问题它的编辑框是系统的 label edit 窗口父窗口不是你PreTranslateMessage收不到它的按键想拦 ESC 或者回车提交只能依赖默认行为。在数据录入场景里这个限制很致命——用户按回车默认是提交并跳回列表但你往往希望回车后直接进入下一行同一列的编辑状态这在LVS_EDITLABELS上做不到。所以这条路的定位很清楚只读表格里偶尔改个名字、改个备注够用只要涉及多列、涉及输入校验、涉及连续录入直接放弃别在这上面浪费时间。2.2 原地编辑CEdit 盖在单元格上真正能覆盖任意列的做法只有一个自己在列表控件上动态创建一个 CEdit把它挪到目标单元格的矩形位置上编辑结束时读回文本再SetItemText。这套东西业内叫原地编辑in-place edit本质是把列表控件当成一块画布编辑框是浮在上面的一个子窗口。关键点有三个。第一是坐标系编辑框的父窗口必须设成列表控件本身坐标用列表的客户区坐标这样滚动时两者能一起动如果父窗口设成桌面或者 View滚动之后编辑框就会脱离原来的位置变成“贴错位置”。第二是矩形计算必须精确拿到第 nItem 行第 nSubItem 列那个格子的矩形不能拿整行矩形凑合否则编辑框会横跨好几列。第三是生命周期创建一次、反复复用比每次new一个再delete稳得多VC6 下频繁创建销毁子窗口很容易在退出时留下野句柄。这条路的成本在于要自己处理一堆边角回车提交、ESC 取消、点别处提交、滚动时跟随或关闭、列宽拖动后重新定位、中文输入法的候选窗口。好处是全程可控任何一列都能编辑输入校验可以在提交前做交互想怎么改就怎么改。2.3 对话框式编辑与整行编辑的适用场景如果业务允许还有一种更省事的做法双击某行弹一个模态对话框把所有字段摊开让用户填确定后一次性回写整行。这种方案在 VC6 时代非常常见做起来最快事件处理也最简单——不需要管焦点、不需要管滚动、不需要管输入法对话框本身就是标准控件容器。代价是交互重。用户改一个单元格的数字要先弹窗、再定位、再关窗连续录入几十行会非常难受。它适合“行数据字段多、单条编辑耗时长、修改频率低”的场景比如配置项维护不适合“一屏几十行、逐格微调”的场景比如价格表、库存表。还有一种折中是整行编辑双击行之后把整行的每一列都换成编辑框或者只把当前行切成输入态一次性提交。实现上比单格原地编辑复杂因为要同时维护多个编辑框的创建、Tab 顺序、提交时机但比弹窗体验好适合列数固定且不多的表格。选型时按“编辑频率 × 列数”两个维度判断即可频率高、列数少就用单格原地编辑反过来就上对话框。2.4 单文档框架里的类扩展位置为什么放在派生类而不是 ViewVC6 单文档程序的结构是 CWinApp → CFrameWnd → CView → 控件。CListCtrl 通常是 CView 里的一个成员或者 CView 本身就是一个CListCtrl派生类CListView形式。可编辑逻辑放哪儿直接决定了后面好不好维护。放到 View 里最省事所有消息映射都写在CXXXView上OnLButtonDblClk、PreTranslateMessage、滚轮消息一把抓。问题是这套逻辑一旦写进 View就绑死在这个视图上下一个工程想复用只能整段复制粘贴改一处漏一处。而且 View 里的消息又多又杂OnDraw、OnSize、菜单命令全在一个 cpp 里编辑逻辑混进去之后排查问题会非常痛苦。更合适的做法是先派生一个CListCtrl子类把编辑框的创建、定位、提交、取消、键盘拦截全部封在里面View 只负责Create它、给它喂数据、接收它抛上来的“编辑完成”通知。这样类扩展就是一次性的视图类只需要包含头文件编辑能力就跟着来了跟单文档还是对话框没关系。这也是后面第 6 章要抽基类的原因——先把边界划清楚再谈复用。3. 动态创建控件把 CEdit 精确盖到单元格上方案定了就开始动手。这一章给出一套能直接跑的骨架派生一个 CListCtrl 子类在里面挂一个 CEdit 成员双击进入编辑回车/ESC/失焦三条路径退出。代码按 VC6 MFC 6.0 写注意里面有几个 VC6 特有的宏缺失问题需要自己补定义。3.1 打开扩展风格与准备字体列表控件要先把“能编辑”的基础条件铺好整行选中、网格线、选中项失焦后仍然高亮否则编辑框一拿到焦点原来那行就变灰用户看不出来在改哪一行、双击激活。扩展风格通过LVS_EX_*系列设置VC6 的commctrl.h里这些宏都有但列表控件需要 comctl32.dll 4.71 以上版本系统里一般是满足的。// EditableListCtrl.h #pragma once // VC6 的 commctrl.h 是 IE4 之前的版本这两个消息宏可能没有定义必须自己补 #ifndef LVM_GETSUBITEMRECT #define LVM_GETSUBITEMRECT (LVM_FIRST 56) #endif #ifndef LVM_SUBITEMHITTEST #define LVM_SUBITEMHITTEST (LVM_FIRST 57) #endif #define IDC_INPLACE_EDIT 1001 class CEditableListCtrl : public CListCtrl { public: CEditableListCtrl(); virtual ~CEditableListCtrl(); void BeginEdit(int nItem, int nSubItem); // 进入编辑 void EndEdit(BOOL bCancel FALSE); // 退出编辑 protected: CEdit m_wndEdit; // 复用的编辑框只创建一次 CFont m_fontEdit; // 与列表保持一致的字体 int m_nEditItem; // 当前正在编辑的行-1 表示没有 int m_nEditSub; // 当前正在编辑的列 CString m_strOldText; // 编辑前的原文用于 ESC 回滚 int GetColumnWidth(int nCol); void PlaceEdit(int nItem, int nSubItem); int SubItemHitTest(LVHITTESTINFO* pHti); afx_msg void OnLButtonDblClk(UINT nFlags, CPoint point); afx_msg void OnEditKillFocus(); afx_msg void OnDestroy(); virtual BOOL PreTranslateMessage(MSG* pMsg); DECLARE_MESSAGE_MAP() };风格设置放在PreSubclassWindow或者OnCreate之后统一做一次别散在各处。LVS_EX_FULLROWSELECT和LVS_EX_GRIDLINES是必开的LVS_EX_TWOCLICKACTIVATE不要开——它会跟双击编辑抢消息导致第一次双击被吞掉。字体方面VC6 默认给控件用的是SYSTEM_FONT中文在编辑框里会发虚、行高也对不齐统一用DEFAULT_GUI_FONT最稳列表和编辑框用同一份。// EditableListCtrl.cpp CEditableListCtrl::CEditableListCtrl() { m_nEditItem -1; m_nEditSub -1; } void CEditableListCtrl::OnInitialUpdateStyle() // 放在 OnCreate 之后调用 { SetExtendedStyle(GetExtendedStyle() | LVS_EX_FULLROWSELECT | LVS_EX_GRIDLINES); m_fontEdit.CreateStockObject(DEFAULT_GUI_FONT); SetFont(m_fontEdit); // 列表本身也用同一字体保证行高对齐 }CreateStockObject(DEFAULT_GUI_FONT)是 VC6 里少数几个能直接拿到中文字体的可靠方式比CreateFont拼一堆参数省事。注意m_fontEdit要是成员变量不能是局部变量——字体对象析构之后控件引用的句柄就失效了表现是界面文字突然变成乱码或者小方块。这种问题调试时看不出来跑一段时间才崩属于典型的“看着能跑实际在漏水”。3.2 用 LVM_GETSUBITEMRECT 精确算格子编辑框盖不准九成问题出在矩形计算。很多人第一反应是GetItemRect(nItem, rc, LVIR_BOUNDS)拿到的却是整行的矩形编辑框会横跨所有列。正确做法是走LVM_GETSUBITEMRECT但这个 API 有个非常反直觉的约定它复用RECT结构的前两个成员当输入参数调用前必须先把left填成列号、top填成行号返回时这两个值被覆盖成真实坐标。不预先赋值的话拿回来的矩形基本是垃圾数据。还有一个坑第 0 列不能用LVM_GETSUBITEMRECT对它调用会返回失败或者全零。第 0 列得走LVM_GETITEMRECT拿整行矩形再把右边界改成第 0 列的宽度。int CEditableListCtrl::GetColumnWidth(int nCol) { CHeaderCtrl* pHeader GetHeaderCtrl(); if (pHeader NULL) return 0; HDITEM hd; ::ZeroMemory(hd, sizeof(hd)); hd.mask HDI_WIDTH; if (!pHeader-GetItem(nCol, hd)) return 0; return hd.cxy; } void CEditableListCtrl::PlaceEdit(int nItem, int nSubItem) { CRect rcCell(0, 0, 0, 0); if (nSubItem 0) { // 第 0 列LVM_GETSUBITEMRECT 不适用用整行矩形截出首列宽度 rcCell.top nItem; GetItemRect(nItem, rcCell, LVIR_BOUNDS); rcCell.right rcCell.left GetColumnWidth(0); } else { // 重点left 放列号top 放行号这两个是“入参”不是输出 rcCell.left nSubItem; rcCell.top nItem; SendMessage(LVM_GETSUBITEMRECT, (WPARAM)nItem, (LPARAM)rcCell); } // 格子已经滚出可视区就别显示了否则编辑框会飘在列表外面 CRect rcClient; GetClientRect(rcClient); if (rcCell.bottom rcClient.bottom || rcCell.top rcClient.top) { m_wndEdit.ShowWindow(SW_HIDE); return; } m_wndEdit.MoveWindow(rcCell); m_wndEdit.ShowWindow(SW_SHOW); m_wndEdit.SetFocus(); m_wndEdit.SetSel(0, -1); // 全选用户双击进来直接覆盖输入 }MoveWindow一定要在ShowWindow之前顺序反了会看到编辑框从 (0,0) 闪一下再跳到目标位置观感很差。另外SetFocus之后不要再回头调用列表的SetFocus否则输入会丢失这个顺序问题在第 4 章还会展开。3.3 创建、子类化与显示编辑框编辑框不需要每次重建构造函数里不创建第一次进入编辑时创建一次之后一直复用。创建时的关键参数是父窗口和样式父窗口必须是this列表控件本身样式至少要WS_CHILD | ES_AUTOHSCROLL | ES_NOHIDESELES_NOHIDESEL是为了让编辑框在失焦时仍显示选中内容用户体验更连贯。不要加WS_BORDER边框会和列表网格线打架看上去像多了一条线。void CEditableListCtrl::BeginEdit(int nItem, int nSubItem) { if (nItem 0 || nSubItem 0) return; // 已有编辑在进行先提交掉保证同一时刻只有一个编辑框 if (m_nEditItem 0) EndEdit(FALSE); m_nEditItem nItem; m_nEditSub nSubItem; m_strOldText GetItemText(nItem, nSubItem); if (!::IsWindow(m_wndEdit.GetSafeHwnd())) { // 父窗口必须是列表自己坐标才是客户区坐标滚动才能跟着走 if (!m_wndEdit.Create(WS_CHILD | ES_AUTOHSCROLL | ES_NOHIDESEL, CRect(0, 0, 0, 0), this, IDC_INPLACE_EDIT)) { m_nEditItem -1; return; } m_wndEdit.SetFont(m_fontEdit); } m_wndEdit.SetWindowText(m_strOldText); PlaceEdit(nItem, nSubItem); }这里用的是“直接 Create 到父窗口”的方式没有走资源里的对话框控件再SubclassDlgItem。两种都行但如果是单文档视图里嵌列表资源里加一个 IDC_EDIT 再子类化反而绕多一个资源、多一步GetDlgItem不如直接 Create 干净。代价是编辑框的 ID 要自己定义并且要确保不和工程里已有的控件 ID 冲突1001这种范围值建议先全局搜一遍再定。3.4 提交、取消与数据回写退出编辑有三条路径回车提交、ESC 取消、焦点转移到别处提交。三条路最后都汇到EndEdit用一个bCancel参数区分。函数里先取文本、再隐藏窗口、再清状态最后才SetItemText——顺序反了容易在SetItemText触发的重绘里又踩到编辑框。void CEditableListCtrl::EndEdit(BOOL bCancel) { if (m_nEditItem 0 || !::IsWindow(m_wndEdit.GetSafeHwnd())) return; CString strNew; m_wndEdit.GetWindowText(strNew); int nItem m_nEditItem; int nSub m_nEditSub; m_nEditItem -1; // 先清状态避免 SetItemText 重入 m_nEditSub -1; m_wndEdit.ShowWindow(SW_HIDE); if (bCancel || strNew m_strOldText) return; // 取消或没改动直接返回 SetItemText(nItem, nSub, strNew); // 抛给父窗口让 View 同步到自己的数据模型/数据库 CWnd* pParent GetParent(); if (pParent ! NULL) pParent-PostMessage(WM_USER 100, (WPARAM)nItem, (LPARAM)nSub); }PostMessage而不是SendMessage是有意的SendMessage会在当前调用栈里同步执行父窗口的处理逻辑如果父窗口里又去刷新列表、又去查数据库重入风险很高。PostMessage把它推到消息队列等当前这轮消息处理完再执行安全得多。父窗口收到之后自己用GetItemText取值即可或者你干脆在消息里带一个结构体指针但那样要管内存释放不如让父窗口自己取。4. 事件处理的分寸键盘、滚动、列宽与输入法编辑框盖上去只是开始真正决定好不好用的是事件处理这一层。VC6 下没有现成的事件框架全靠消息映射和PreTranslateMessage手工拦截分寸拿捏不好就会出现“按回车没反应”“滚一下轮编辑框留在原地”“中文打一半变乱码”这类问题。这一章把四类高频事件拆开讲。4.1 PreTranslateMessage 拦截回车与 ESC 的分寸编辑框是列表的子窗口用户按下的键先进入消息队列再由 MFC 的消息泵沿着父窗口链调用PreTranslateMessage。这个“沿父链走”的行为是 MFC 的CWnd::WalkPreTranslateTree实现的意味着列表控件的PreTranslateMessage能收到子编辑框的按键——这是一个很好用的口子不用给 CEdit 单独派生一个类就能拦回车和 ESC。BOOL CEditableListCtrl::PreTranslateMessage(MSG* pMsg) { if (m_nEditItem 0 ::IsWindow(m_wndEdit.GetSafeHwnd()) pMsg-hwnd m_wndEdit.GetSafeHwnd()) { if (pMsg-message WM_KEYDOWN) { switch (pMsg-wParam) { case VK_RETURN: EndEdit(FALSE); return TRUE; // 吃掉别让编辑框再处理 case VK_ESCAPE: EndEdit(TRUE); return TRUE; case VK_TAB: EndEdit(FALSE); // 这里可以接“跳到下一格”的逻辑见 6.1 return TRUE; } } } return CListCtrl::PreTranslateMessage(pMsg); }分寸在于“只拦自己该拦的”。判断条件里必须带上pMsg-hwnd m_wndEdit.GetSafeHwnd()否则列表本身的按键比如方向键移动选中行也会被误吃。返回TRUE表示消息已处理、不再往下传返回FALSE则继续默认流程。有人在PreTranslateMessage里不判断 hwnd直接把所有WM_KEYDOWN都拦下来结果列表的键盘导航全废用户只能靠鼠标这种问题在验收时很容易被漏过去。还有一点VK_TAB在单文档程序里默认是对话框导航用的编辑框作为普通子窗口其实不参与 Tab 循环但为了后续扩展比如 Tab 跳下一格在这里拦掉比在后面补要省事。4.2 编辑框的位置如何跟滚动保持一致列表滚动分两种滚轮和滚动条。滚轮消息WM_MOUSEWHEEL会先发给有焦点的窗口编辑框有焦点时它会收到这个消息但它自己不认识会往上抛给列表列表再滚动内容——这时候编辑框还留在原来的屏幕位置上跟单元格错位了。处理方式有两种。简单粗暴的是滚动即取消编辑BOOL CEditableListCtrl::OnMouseWheel(UINT nFlags, short zDelta, CPoint pt) { EndEdit(TRUE); // 滚动就放弃本次编辑避免错位 return CListCtrl::OnMouseWheel(nFlags, zDelta, pt); }温和一点的是滚动结束后重新定位void CEditableListCtrl::OnVScroll(UINT nSBCode, UINT nPos, CScrollBar* pScrollBar) { CListCtrl::OnVScroll(nSBCode, nPos, pScrollBar); if (m_nEditItem 0) { // 滚动完成后按当前行列重新算一次矩形编辑框跟着走 PlaceEdit(m_nEditItem, m_nEditSub); } }选哪个看业务。数据录入场景里用户滚动往往是想看别的行这时候保留编辑框反而碍事取消更合理而“看大表格边改边翻”的场景跟随更顺手。我的习惯是先做取消等真的有人抱怨了再改成跟随——因为跟随要处理“单元格滚出可视区”的情况PlaceEdit里那段隐藏逻辑就是为它准备的边界多容易翻车。4.3 列宽拖动与列重排时的坐标重算列表头是可以拖的用户把某列拉宽之后编辑框还停在原来的宽度上看着就像贴歪了。头控件是列表的子窗口它发出的HDN_BEGINTRACK、HDN_ENDTRACK、HDN_ITEMCHANGED通知会先到列表再往上抛。在列表子类里用ON_NOTIFY_REFLECT接住就能在拖动结束时重新定位。BEGIN_MESSAGE_MAP(CEditableListCtrl, CListCtrl) ON_WM_LBUTTONDBLCLK() ON_WM_MOUSEWHEEL() ON_WM_VSCROLL() ON_WM_DESTROY() ON_CONTROL(EN_KILLFOCUS, IDC_INPLACE_EDIT, OnEditKillFocus) ON_NOTIFY_REFLECT(HDN_ENDTRACK, OnHeaderEndTrack) END_MESSAGE_MAP() void CEditableListCtrl::OnHeaderEndTrack(NMHDR* pNMHDR, LRESULT* pResult) { if (m_nEditItem 0) { // 列宽变了编辑框宽度必须跟着变否则文字会被截断 PlaceEdit(m_nEditItem, m_nEditSub); } *pResult 0; }ON_NOTIFY_REFLECT和ON_NOTIFY的区别要拎清头控件是列表的子窗口通知默认发往列表的父窗口也就是 View如果你在 View 里用ON_NOTIFY接也能收到但那样编辑逻辑就漏到 View 里去了用ON_NOTIFY_REFLECT是把通知“反射”回列表自己处理封装才完整。VC6 的 MFC 支持反射宏名就是ON_NOTIFY_REFLECT别写成ON_NOTIFY_REFLECT_EX那是后面版本才有的。还有一处容易漏列被拖动重排之后nSubItem和实际显示位置的对应关系变了。如果你的表格不允许拖动列直接在头控件上禁掉HDS_DRAGDROP最省事允许拖的话PlaceEdit里的列号要用LVM_MAPINDEXTOID/LVM_MAPIDTOINDEX换算或者干脆在重排时结束编辑。4.4 中文输入法与焦点的先后顺序中文输入法是 VC6 可编辑表格里最容易出玄学的地方。表现是用户切到拼音输入法敲第一个字母编辑框突然消失或者候选窗口弹出来但按键进不去编辑框或者打完字按空格上屏第一个字丢失。原因通常在于失焦处理写得太粗暴。编辑框的EN_KILLFOCUS会在焦点转移到任何其他窗口时触发输入法的候选窗口、状态窗口在某些实现下会短暂抢焦点于是OnEditKillFocus被调用里面无条件EndEdit(FALSE)编辑框就没了。正确的做法是在失焦时先判断焦点到底去了哪儿void CEditableListCtrl::OnEditKillFocus() { // 输入法候选窗口抢焦点时GetFocus() 可能返回 NULL 或者输入法自己的窗口 CWnd* pFocus CWnd::GetFocus(); if (pFocus ! NULL pFocus-GetSafeHwnd() m_wndEdit.GetSafeHwnd()) return; // 焦点其实还在编辑框上忽略 // 延迟提交给输入法一个上屏的机会避免第一个字被吞 PostMessage(WM_COMMIT_EDIT, 0, 0); }PostMessage而不是直接EndEdit是给自己留一条“等一下”的路输入法上屏是会往编辑框里塞字符的如果失焦的瞬间就销毁编辑框塞进去的字自然就丢了。延后一轮消息再提交绝大多数情况下字符已经落到编辑框里了。另外编辑框创建时如果没设字体VC6 会给它一个默认的System字体中文显示成方块或者大小不对。这一点在 3.1 已经用DEFAULT_GUI_FONT解决但要注意SetFont之后编辑框的高度不会自动变MoveWindow用的矩形高度是从列表单元格拿的如果字体行高比单元格高文字会被裁掉——所以列表本身的字体必须和编辑框统一这是两者行高对齐的唯一办法。5. 避坑与排查VC6 下可编辑表格的五个翻车现场下面这五条基本覆盖了这套方案在 VC6 里九成以上的故障。每条按“现象 → 原因 → 解决”写遇到问题可以直接对号入座。5.1 双击第一列能编辑双击第二列没反应现象双击第 0 列正常进入编辑双击第 1 列之后的位置毫无反应鼠标怎么点都不出现编辑框。原因行列判断用的是GetItemRect或者HitTest后者只返回行号不返回列号又或者用了LVM_GETSUBITEMRECT但没给RECT的left、top预填列号和行号函数返回失败rcCell还是全零MoveWindow到一个零尺寸矩形看起来就是“没反应”。解决命中测试走LVM_SUBITEMHITTEST它返回的LVHITTESTINFO::iSubItem才是列号矩形计算按 3.2 的写法分两种情况处理第 0 列单独走LVM_GETITEMRECT。VC6 的commctrl.h里可能没有LVM_SUBITEMHITTEST宏先补定义再编译别指望链接器给你提示。int CEditableListCtrl::SubItemHitTest(LVHITTESTINFO* pHti) { pHti-flags LVHT_ONITEM; return (int)SendMessage(LVM_SUBITEMHITTEST, 0, (LPARAM)pHti); }5.2 编辑框第一次显示正常第二次位置错乱或者跑到左上角现象第一次双击编辑没问题提交后再双击另一行编辑框出现在 (0,0) 附近或者宽度只有几个像素。原因Create时的初始矩形是全零之后靠MoveWindow定位如果某次PlaceEdit中途返回比如单元格滚出可视区那段逻辑编辑框就被ShowWindow(SW_HIDE)了但状态m_nEditItem没清下一次BeginEdit判断“已有编辑在进行”走EndEdit(FALSE)EndEdit里因为窗口已隐藏、文本没变又提前返回状态就错乱了。解决PlaceEdit里隐藏编辑框的分支要同步把状态清掉或者干脆不在PlaceEdit里做隐藏判断改成在OnVScroll里判断单元格是否可见不可见就EndEdit(TRUE)。状态机要保持单一入口进入编辑只有BeginEdit退出只有EndEdit中间任何分支都不许偷偷改m_nEditItem。5.3 输入中文时第一个字被吞或者编辑框直接消失现象切到拼音输入法敲第一个键编辑框消失或者候选词上屏后只进去一半。原因EN_KILLFOCUS里无条件调用了EndEdit输入法候选窗口弹出时短暂抢走焦点触发失焦编辑框被销毁或隐藏后续字符自然进不去。解决失焦处理改成延迟提交见 4.4并且在EndEdit里先GetWindowText再隐藏窗口保证已经落到编辑框里的字能被读出来。如果你们的输入法比较特殊还可以在EndEdit之前发一个WM_IME_COMPOSITION相关的处理但绝大多数情况下延迟一轮消息就够了。5.4 拖动列宽之后编辑框停在旧位置、宽度也不对现象编辑状态下拖动表头分隔线列变宽了编辑框还是原样右边露出一截空白。原因没有处理头控件的HDN_ENDTRACK或者用ON_NOTIFY接在了 View 上列表子类里收不到。解决在列表子类里用ON_NOTIFY_REFLECT(HDN_ENDTRACK, ...)接住回调里重新PlaceEdit。另外如果表格允许列拖动重排同时要处理HDN_ENDDRAG否则列顺序一变nSubItem和显示位置就对不上了最简单的办法是直接禁掉列拖动。5.5 程序退出时崩溃或者 Debug 版报断言现象关闭主窗口时弹出断言或者干脆无提示退出Release 版偶发Debug 版必现。原因窗口销毁顺序问题。列表控件先被销毁子编辑框跟着销毁但m_wndEdit的 C 对象还在成员析构时 MFC 会去Detach一个已经无效的句柄或者EndEdit在WM_DESTROY之后被调用里面还去SetItemText访问了已经析构的列表内部数据。解决在列表的OnDestroy里先把编辑状态清干净再交给基类。void CEditableListCtrl::OnDestroy() { m_nEditItem -1; // 先断状态防止后续重入 m_nEditSub -1; if (::IsWindow(m_wndEdit.GetSafeHwnd())) m_wndEdit.DestroyWindow(); // 主动销毁子窗口别等父窗口连带销毁 CListCtrl::OnDestroy(); }DestroyWindow之后再走基类顺序不能反。这一条是所有动态创建子窗口的通病不只是列表编辑养成“谁创建谁销毁、销毁在基类之前”的习惯能省掉大量退出崩溃。6. 收口把编辑能力抽成基类附一份上线自检清单前面五章的东西散在 View 里也能跑但下一个工程就得重来一遍。真正省时间的是把编辑能力抽成一个独立的CEditableListCtrlView 只做三件事创建它、喂数据、接通知。抽的时候有两个细节值得说一下。第一个是“编辑完成”的通知方式。最开始我用的是PostMessage(WM_USER100, ...)父窗口在OnEditDone里自己去GetItemText。后来发现同一个 View 里有好几个列表消息没法区分来源只好在WPARAM里塞控件 IDLPARAM塞打包后的行列号凑合能用但写起来别扭。更干净的方案是让基类持有一个回调接口class IEditNotify { public: virtual void OnCellEdited(CWnd* pList, int nItem, int nSubItem, LPCTSTR lpszNewText) 0; }; // CEditableListCtrl 里加一个成员 IEditNotify* m_pNotify; // EndEdit 里改成 if (m_pNotify ! NULL) m_pNotify-OnCellEdited(this, nItem, nSub, strNew);View 实现这个接口EndEdit直接回调不用跟消息号打交道也不用担心多列表串消息。代价是 View 和列表之间多了一层依赖但 VC6 工程本来就没多少解耦可言这点代价换来的是可读性值。第二个是 Tab 跳下一格。这块逻辑放在基类里最好因为要算“当前是不是最后一列、是不是最后一行、要不要自动新增一行”全都跟列表数据相关。实现上就是在PreTranslateMessage的VK_TAB分支里算下一格坐标BeginEdit之前先EnsureVisible保证目标行在可视区内否则编辑框会创建在一个看不见的位置上。void CEditableListCtrl::EditNextCell() { int nItem m_nEditItem; int nSub m_nEditSub 1; int nCols GetHeaderCtrl()-GetItemCount(); if (nSub nCols) // 到行尾跳下一行第一列 { nSub 0; nItem nItem 1; } if (nItem GetItemCount()) // 到最后一行停在原地 return; EnsureVisible(nItem, FALSE); // 先滚动过去再建编辑框 BeginEdit(nItem, nSub); }抽完基类之后这个文件大概 300 行左右把编辑框创建、矩形计算、键盘拦截、滚动处理、销毁清理全包了。剩下的问题基本都在使用方数据量大的时候SetItemText触发的重绘会卡那是SetRedraw(FALSE)的事列表项特别多的时候用虚拟列表LVS_OWNERDATA那套跟原地编辑配合要另写一版GetItemText得换成你自己维护的数据源不在这次的范围内。最后给一份上线前的自检清单我在几个 VC6 老工程上都是照着这张表过一遍才敢交付检查项通过标准常见问题第 0 列与其余列双击任意列都能进入编辑位置准确第 0 列走错 API矩形全零回车 / ESC / 失焦三条路径行为一致无残留ESC 后文本没回滚中文输入法拼音、五笔打完字完整上屏首字丢失、编辑框消失滚动滚轮和滚动条都不留错位框编辑框挂在原位置不动列宽拖动编辑框宽度随列变化只在 View 里接了通知连续编辑连续双击、Tab 切换 20 次不崩状态机被中途改动退出关闭主窗口无断言、无崩溃OnDestroy 顺序写反大数据量500 行以上滚动流畅没关重绘、逐行 SetItemText从那以后我每次接手 VC6 的表格改造都强制先把这张表过一遍尤其是第 0 列和退出这两项——它们不会在开发阶段暴露只会在演示或者交付现场给你一下。希望帮到你。本文还有配套的精品资源点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
