简介：基于MFC对话框程序的一份可直接运行的示例工程，面向需要掌握CListCtrl与CComboBox联动操作的Windows桌面开发者，也适合C++初学者入门控件事件处理。资源解决的是“通过下拉框选择来动态修改列表内容”这一典型交互需求，重点演示了控件ID关联、消息映射函数编写以及列表数据同步更新等完整流程，风格紧凑，省去从零搭建框架的繁琐。压缩包共20个文件，包括6个.h头文件、4个.cpp源文件、.rc/.rc2资源脚本、.vcxproj/.sln工程配置文件及图标资源，整体仅160KB，目录结构清晰，可在Visual Studio中直接打开编译运行。已有552人学习/浏览，验证了其作为MFC列表控件与下拉框协同工作参考资料的价值。通过该项目，可直观看到列表列初始化、下拉框选项填充、选择事件响应以及SetItemText等关键接口的实际用法；同时，简洁的工程布局也为后续扩展数据绑定、界面美化或增加数据校验提供了直接可用的修改起点，无论是课程设计还是日常练习均具参考价值。
1. 一个下拉框改一整行 List 数据：别清空重插，先学会精准定位
MFC 对话框里放一个 List 控件和一个下拉框，用户从下拉框里选一项，列表里对应行的数据跟着变——这个需求在 MFC 老项目里出现频率极高，订单状态、产品分类、审批结果，本质都是同一件事：用 CComboBox 的选中事件去驱动 CListCtrl 单元格内容更新。很多刚接触 MFC 的开发者第一反应是先把 List 清空再重新 InsertItem，这种做法能跑，但会破坏选中状态和滚动位置，数据量大时还会闪屏。真正的做法是拿到下拉框的选中项，定位到要修改的行，用 SetItemText 精准改写目标单元格。这篇笔记就从事件模型讲起，把整个联动流程拆开，附带工程里常见的几个坑。
2. CComboBox 与 CListCtrl 的联动模型：先理清消息路径再动手
MFC 里做控件联动，最忌讳一上来就拖控件、写事件、跑通就收工。等到需求一变——比如要改的行不是当前选中行、列表要支持排序、数据量涨到几千行——你会发现控件之间的关系没理清，改起来处处掣肘。这一章先把两个控件在 MFC 里的定位和它们之间的消息路径讲清楚。
2.1 为什么 List 不能像网页那样直接绑数据
用过前端框架的人都知道 Vue 里一个 v-model 就能让下拉框和表格联动，但 MFC 没有数据绑定。CListCtrl 只是 Windows ListView 控件的 MFC 封装，它管显示、管选中、管图标排列，但它不关心你的业务数据存哪里。CComboBox 也一样，它就是一组字符串加一个编辑框的展示容器。两者之间没有内置的关联机制，你必须自己写代码把“下拉框选中了什么”翻译成“List 里哪一行哪一列改成什么值”。
这个“翻译”过程是整个功能的核心，也是大多数人思路容易绕弯的地方。具体到工程实现，MFC 提供了两个关键工具：一个是 CListCtrl::SetItemText，用来改单元格的显示文本；另一个是 SetItemData，用来往列表项上挂一个自定义的 DWORD_PTR 值——这就像给每一行贴了一个标签，后面定位行就靠它。我在实际项目里习惯把业务表的主键 ID 挂到 SetItemData 上，而不是依赖行号，原因后面避坑章节会详细说。
很多人纠结要不要用 LVS_OWNERDATA 这种虚拟列表模式。虚拟列表适合行数上万、数据来自数据库分页查询的场景，它要求你自己实现数据获取回调，代码量大不少。如果你只是几百行数据、一次性载入内存，用普通模式加 SetItemText 完全够用，不值得为虚拟模式增加复杂度。
2.2 CBN_SELCHANGE 是怎么走到你的代码里的
Windows 控件的交互消息，在 MFC 里是通过消息映射宏转到类成员函数的。下拉框在用户切换选项时，会向父窗口发送一个 WM_COMMAND 通知，通知码是 CBN_SELCHANGE。ClassWizard 自动生成的关联代码长这样：
BEGIN_MESSAGE_MAP(CMFCAppDlg, CDialogEx) ON_CBN_SELCHANGE(IDC_COMBOBOX, &CMFCAppDlg::OnCbnSelchangeCombobox) END_MESSAGE_MAP() void CMFCAppDlg::OnCbnSelchangeCombobox() { // 用户切换了下拉框选项，在这里响应 }这里有个容易被忽略的细节：CBN_SELCHANGE 是在用户改变选择时立刻触发的，但此时下拉框的编辑框文本可能还没完全更新，所以你在这个函数里用 GetWindowText 取文本有概率取到旧值。更稳妥的是用 GetCurSel 拿选中项的索引，再用 GetLBText 按索引取文本，这两步是原子的，不会出现时序问题。
另外，同一份代码里不同控件 ID 的消息映射宏很容易抄错。比如你在资源编辑器里把下拉框的 ID 改成了 IDC_COMBO_STATUS，但消息映射里还写的 IDC_COMBOBOX，那这个处理函数永远不会被调用。排查方式很简单：在函数入口打断点，断点没进就是消息映射和资源 ID 对不上。
2.3 ReportCtrl 在工程里到底是什么角色
从工程文件结构看，这个项目里有一个 ReportCtrl.h 和 ReportCtrl.cpp，这是典型的 CListCtrl 派生类封装。为什么要把 List 控件包一层？因为 ListView 在 MFC 裸用会很痛苦——设置行高要发 LVM_SETITEMCOUNT 或者自绘，列头排序要处理 LVN_COLUMNCLICK，右键菜单要处理 WM_CONTEXTMENU，这些逻辑如果全堆在主对话框里，OnInitDialog 会变成几百行的大杂烩。
ReportCtrl 这类封装类通常做这几件事：初始化列表的扩展样式、封装 InsertColumn 系列操作、统一处理行高和字体、把排序逻辑收进 SortItems 回调。主对话框只需要调 m_reportCtrl.InsertRow(...) 这种语义化接口，不用每次都跟 LVCOLUMN 结构体打交道。你要复用这个工程时，先在 ReportCtrl 里翻一翻它暴露了哪些方法，很多时候你要的“按列排序后重新联动下拉框”这种需求，封装类里可能已经有现成实现。
3. 初始化 List 和 ComboBox：列、行、数据三件套一次配齐
联动逻辑能不能跑通，一半取决于初始化写得好不好。很多人的代码跑起来之后出现“下拉框选了没反应”“列表显示错位”这类问题，回溯到最后都是初始化阶段埋的雷。这一章把初始化阶段该做的事按顺序拆开。
3.1 OnInitDialog 里把列表的列和行建好
对话框创建后，第一步是在 OnInitDialog 中给 CListCtrl 设置报表样式并添加列。注意，如果你是在资源编辑器里拖的 List Control，它的默认视图是图标模式，必须在代码里切到报表模式，否则 InsertColumn 不会生效。
BOOL CMFCAppDlg::OnInitDialog() { CDialogEx::OnInitDialog(); // 设置列表为报表模式，并开启整行选中和网格线 m_list.SetExtendedStyle(LVS_EX_FULLROWSELECT | LVS_EX_GRIDLINES | LVS_EX_DOUBLEBUFFER); // 添加三列：名称、价格、状态 m_list.InsertColumn(0, _T("商品名称"), LVCFMT_LEFT, 180); m_list.InsertColumn(1, _T("单价"), LVCFMT_RIGHT, 80); m_list.InsertColumn(2, _T("状态"), LVCFMT_LEFT, 120); // 插入一行示例数据 int nRow = m_list.InsertItem(0, _T("机械键盘")); m_list.SetItemText(nRow, 1, _T("299")); m_list.SetItemText(nRow, 2, _T("在售")); m_list.SetItemData(nRow, 1001); // 1001是这条数据的业务ID return TRUE; }这段代码里有几个参数需要解释。SetExtendedStyle 里我开了三个位：LVS_EX_FULLROWSELECT 让用户点击任意单元格都能选中整行，这是联动操作的前提——你想改哪行就得先能选中哪行；LVS_EX_GRIDLINES 是显示网格线，纯视觉需求，不开也能跑；LVS_EX_DOUBLEBUFFER 是双缓冲，能显著减少刷新时的闪烁，后面避坑章节还会提到它。InsertColumn 的四个参数分别是列索引、列标题、对齐方式、列宽，列宽单位是像素，180 像素在 96 DPI 下大概能显示 6 个汉字加两个英文单词。
SetItemText 的前两个参数是行号和列号，第 3 个参数是显示文本。SetItemData 给这一行挂了一个业务 ID，后续下拉框联动或者排序时，你就用这个 ID 来找行，而不是用行号。这里有个常见误用：有人用 InsertItem 的返回值直接当行号存起来，但列表一旦排序或者增删行，行号全变，这时候 SetItemData 里存的 ID 就成了唯一可靠的锚点。
3.2 填充下拉框：AddString 与 SetItemData 搭配
下拉框的数据来源一般是固定的枚举值或者配置表。如果你在资源编辑器里双击下拉框手动敲选项，那代码里就不需要 AddString 了。我习惯在代码里动态填充，这样数据源可以随时切换，数据库里查出来的状态列表也能直接灌进去。
// 下拉框添加选项，并给每个选项挂一个业务值 int nIdx = m_combo.AddString(_T("在售")); m_combo.SetItemData(nIdx, 1); nIdx = m_combo.AddString(_T("下架")); m_combo.SetItemData(nIdx, 2); nIdx = m_combo.AddString(_T("预售")); m_combo.SetItemData(nIdx, 3); // 默认选中第一项 m_combo.SetCurSel(0);AddString 的返回值是插入项在列表中的位置，失败时返回 CB_ERR 或者 CB_ERRSPACE。SetItemData 挂上去的业务值，和列表行上挂的业务 ID 作用一样——都是为了让逻辑代码不依赖字符串比较。你可能会想：直接用 GetLBText 拿到的字符串去跟 _T("在售") 比较，不是更直观吗？字符串比较在中文场景下有编码隐患，而且以后改文案就得改逻辑代码。用数字 ID 做映射，文案变了代码不用动。
注意 SetCurSel(0) 的作用：它让下拉框初始显示第一项。这个“初始选中”状态是要跟 List 里该行的当前状态保持一致的，否则用户看到的界面是“下拉框选了在售，列表这行却显示下架”，这时候就要做一次手动的通知触发，或者在初始化逻辑里统一从数据模型取值，而不是硬编码两个地方。
3.3 扩展样式和排序头的注意事项
LVS_EX_FULLROWSELECT 和 LVS_EX_GRIDLINES 是 ListView 扩展样式里最常用的两个，但还有一个位经常引起困惑：LVS_EX_CHECKBOXES。如果你开了这个样式，每一行前面会多一个复选框，这个复选框的状态通过 GetCheck 和 SetCheck 存取。它和 SetItemData 是两码事，别把业务状态挂到复选框上——复选框勾选状态和单元格文本是独立存储的，刷新单元格时勾选状态不会丢，但如果你在刷新时调用 DeleteAllItems 再重插，勾选就全没了，而且不会有任何提示。
关于排序头，如果 ReportCtrl 里实现了点击列头排序，注意排序后行号全部变化，你在 OnCbnSelchangeCombobox 里如果用行号定位，就必须在排序回调里同步更新当前选中行的记录。这又是一个用 SetItemData 挂业务 ID 的理由：排序后用 GetItemData 循环查找业务 ID，得到的新行号才是正确的。
4. 核心联动逻辑：在 CBN_SELCHANGE 里精准改掉目标行
初始化做扎实之后，联动逻辑本身其实不长。但越短越要小心边界条件，这一章把事件处理函数的写法、三种定位目标行的方式、以及改完数据后的刷新方式一次说清。
4.1 先取选中项再防御：GetCurSel 和 GetLBText 的配合
下拉框事件处理函数的第一步，是先拿到用户选中的到底是哪一项。这里有两个获取数据的函数，返回值语义不同，容易混。
void CMFCAppDlg::OnCbnSelchangeCombobox() { // 获取当前选中的下拉项索引 int nSel = m_combo.GetCurSel(); if (nSel == CB_ERR) { return; // 没有选中任何项，直接退出 } // 按索引取文本，避免从编辑框里取到旧值 CString strSel; m_combo.GetLBText(nSel, strSel); // 取到当前列表选中的行 int nRow = m_list.GetNextItem(-1, LVNI_SELECTED); if (nRow == -1) { return; // 列表里没有选中行，没有可修改的目标 } // 把这一行的状态列改成下拉框选中的值 m_list.SetItemText(nRow, 2, strSel); }GetCurSel 返回的是整数索引，取不到时返回 CB_ERR，也就是 -1。这里如果漏掉 CB_ERR 检查，下面 GetLBText 就会拿到一个野索引，轻则取到空字符串，重则崩溃。GetLBText 把文本拷贝到 CString 里，注意它不会自动追加尾零，所以必须传入一个已有的 CString 对象，让它内部处理长度。
GetNextItem(-1, LVNI_SELECTED) 是遍历 ListView 查找选中行的惯用写法，第一个参数 -1 表示从头开始找，返回找到的行号，没找到返回 -1。这个调用只能找到一个选中行，如果你的列表支持多选（LVS_MULTISELECT 样式），这里需要改成循环遍历。在这个场景里，联动更新通常是单选模式，所以 GetNextItem 一次就够了。
还有一个细节：SetItemText 之后 List 控件会自动重绘该单元格，不需要你手动 Invalidate。但如果你同时改了 SetItemData，也就是给这行换了一个业务 ID，数据模型和显示不一致，下一次定位就可能出错，这时候建议你在改完 SetItemText 之后，把新的业务 ID 也同步挂上去，语义上保证“显示什么，ID 就是什么”。
4.2 三种定位目标行的方式：各自适合什么场景
上面那段代码用的是“当前选中行”定位法，这是最直觉的做法：用户想改哪行，就先点哪行，再从下拉框选值。但项目开发到后期，你会发现“目标行”这个概念不总是等于“当前选中行”。我总结三种常用定位方式。
第一种是选中行定位，代码就是 4.1 里的写法，适合操作逻辑简单、改动目标单一的场景。第二种是业务 ID 定位：通过 SetItemData 给行挂上数据库主键，遍历查找目标 ID。
// 按业务ID找到行号，遍历方式 int FindRowByData(CListCtrl& list, DWORD_PTR dwTargetId) { int nCount = list.GetItemCount(); for (int i = 0; i < nCount; i++) { if (list.GetItemData(i) == dwTargetId) { return i; } } return -1; }这段代码用 GetItemCount 确定遍历范围，用 GetItemData 逐行取业务 ID 比较，找到就返回行号。这个方案不依赖用户选中状态，哪怕列表排序过、过滤过，只要你维护的业务 ID 不变，永远能找对行。第三种是行号直撸，直接用成员变量 m_nCurrentRow 记录上次操作的行号，适合数据量极小、列表结构永不变化的场景。
对比下来，第一种最常用，第二种最稳，第三种最省事但最脆。我在接手的项目里见过用第三种写法翻车的——用户在表头点了排序，m_nCurrentRow 还停留在排序前的行号，结果下拉框一改，改到另一行去了，数据错乱。
4.3 大批量修改时的刷新优化：WM_SETREDRAW 的用法
下拉框联动单个单元格时，SetItemText 的重绘开销可以忽略。但有一种情况会卡：你的 List 有几百行，下拉框每切换一次就要把所有行的状态一起刷新，或者你要在一个循环里连续改几十个单元格。这时候每个单元格都触发一次重绘，Flash 效果会出现。
// 批量修改前关闭重绘，结束后恢复并强制重绘 m_list.SetRedraw(FALSE); for (int i = 0; i < m_list.GetItemCount(); i++) { m_list.SetItemText(i, 2, strNewStatus); } m_list.SetRedraw(TRUE); m_list.Invalidate();SetRedraw(FALSE) 会挂起控件所有绘制消息，循环结束再恢复，最后 Invalidate 触发一次完整重绘。这个“先关画布再批量改”的做法在 Windows 界面编程里是通用优化手段，效果立竿见影。注意 SetRedraw(TRUE) 之后一定要跟一个 Invalidate，否则恢复绘制后控件不会立刻重画，界面上看起来就像“没刷新”，又会被当成一个新 bug。
5. MFC 联动避坑指南：刷新闪屏、行号错位和消息时序
这一章专门写踩坑记录。下面的每一条都是我在实际项目里遇到过或者接手别人代码时见到过的，按“现象 → 原因 → 解决”的套路写。
5.1 下拉框明明选了，List 却纹丝不动
现象：程序运行后，下拉框切换选项没有任何反应，List 里的数据不变。
原因：最常见的有三个。一是消息映射宏里控件 ID 与资源编辑器里的 ID 不一致，代码里写 IDC_COMBOBOX，资源里实际叫 IDC_COMBO_STATUS。二是处理函数写到了别的类里，比如你让 ReportCtrl 去响应对话框上下拉框的 CBN_SELCHANGE，但 ReportCtrl 不是下拉框的父窗口，收不到 WM_COMMAND。三是下拉框属性里没有勾选“Sort”，你往里面 AddString 的选项顺序乱套，但这不是完全不响应的原因，只会让选项顺序不对。
解决：先在 OnCbnSelchangeCombobox 入口打断点确认有没有进来。没进来就去查消息映射宏和控件 ID；进来了但没反应，就单步看 GetCurSel 是不是返回 CB_ERR，以及 GetNextItem 是不是没有找到选中行。这类问题的排查顺序一定是“消息路径先于业务逻辑”，否则在后面瞎猜半天。
5.2 批量刷新列表时闪屏严重、滚动条回跳
现象：调用一次刷新函数，整个列表白屏闪一下，滚动条回到顶部，用户选中的行丢失。
原因：代码里用了 DeleteAllItems 加 InsertItem 全量重建的方式。这个方法在行数超过几十行时必然闪屏，因为每个 insertItem 都触发一次重绘；滚动条回跳是因为位置跟随行内容变化，全量重建后滚动位置彻底归零；选中行丢失同理。
解决：如果只是修改部分单元格的内容，用 SetItemText 精准改，不要删行重建。如果整列数据确实需要全部替换，那就用 4.3 里的 SetRedraw(FALSE) 包住整个循环。如果数据量真的特别大，考虑 LVS_OWNERDATA 虚拟列表，但代价是你要自己维护全部数据的访问逻辑，适合数据库分页场景，不适合一次性载入的小列表。
5.3 列表排序后，下拉框改到了另一行
现象：点击表头按“单价”排序后，选中某个商品，再看下拉框操作，改的不是选中行的数据。
原因：List 排序后行号全部重新排列。如果你之前用成员变量 m_nCurrentRow 记录行号，或者用某个固定行索引去指向业务数据，排序后这个索引就指向了别的行，属于典型的行号错位。
解决：用 4.2 里的业务 ID 定位法，把主键存进 SetItemData，排序后通过遍历 GetItemData 来找目标行。这是我在项目里最常用的一招，不管列表怎么排、怎么过滤，数据模型的主键不会变，查找永远准。从那以后我接手的每个 MFC 列表工程，都会先确认有没有给行挂业务 ID，没有的我会在早期就补上。
5.4 中文字符串在下拉框和列表之间传过去变成乱码
现象：下拉框里显示正常的中文，选中后用 GetLBText 取出来，SetItemText 写进 List，显示成乱码或者问号。
原因：项目字符集不一致导致的编码转换问题。常见于项目设置为多字节字符集，代码里用了 char* 接收 GetLBText 的结果，再拷贝给 CString，中文字符在转换过程中被截断。另外，代码文件本身如果是 GB2312 编码，但编译器按 UTF-8 解析，字符串字面量也会出现编码错乱。
解决：统一使用 CString 和 _T() 宏，确保项目字符集设置为“使用 Unicode 字符集”，这是 MFC 新项目默认配置。所有字符串参数都要用 CString 传递，避免在 GetLBText 和 SetItemText 之间做 char* 中转。这条经验看起来基础，但我在维护老项目时每隔一阵就会遇到一次，尤其是从老代码里拷贝过来的一段 char 数组写法。
5.5 下拉框还没选完，焦点就丢了，数据就乱了
现象：下拉框的列表展开后，用户用鼠标移动滚动条或者点击空白处，下拉框还没确定选哪项，代码就已经触发了某个事件，List 被改掉了。
原因：CBN_SELCHANGE 和 CBN_KILLFOCUS 的触发顺序问题。当用户点击外部区域时，下拉框失去焦点，KILLFOCUS 先触发，SELCHANGE 后触发，如果你在 KILLFOCUS 里写了刷新逻辑，就会在用户还没完成选择时用旧值刷新了列表。
解决：联动刷新逻辑只写在 CBN_SELCHANGE 里，不要在 KILLFOCUS 里做最终数据落库。如果你的场景必须在下拉框关闭时触发，用 CBN_SELENDOK 通知码，它表示用户完成了选择且不是通过取消方式关闭的。判断条件加上“当前值是否真的变化”，避免焦点切换时不必要的刷新。
6. 两个进阶变体：整行数据切换和列内嵌编辑下拉框
前面的内容都是“一个下拉框控制一行数据”，但实际项目里常常演变成两种变体：下拉框切换整张列表的数据集，以及把下拉框直接嵌到列表的某一列里做行内编辑。这一章给两个方向分别拆解。
6.1 变体一：下拉框控制整行数据集切换
场景：下拉框里是“华东区”“华南区”“华北区”，选中一个区域，下面的 List 展示该区域的所有订单；切换区域时，List 内容整体更换。这种联动的重点是“整体替换数据但不要闪屏”。
void CMFCAppDlg::OnCbnSelchangeCombobox() { int nSel = m_combo.GetCurSel(); if (nSel == CB_ERR) return; // 按区域ID重新拉取数据集，假设从内存缓存里取 std::vector<ORDER_INFO> vecOrders = GetOrdersByRegion(nSel); // 关闭重绘，全量重建数据 m_list.SetRedraw(FALSE); m_list.DeleteAllItems(); for (size_t i = 0; i < vecOrders.size(); i++) { int nRow = m_list.InsertItem(static_cast<int>(i), vecOrders[i].strName); m_list.SetItemText(nRow, 1, vecOrders[i].strPrice); m_list.SetItemText(nRow, 2, vecOrders[i].strStatus); m_list.SetItemData(nRow, vecOrders[i].dwOrderId); } m_list.SetRedraw(TRUE); m_list.Invalidate(); }注意这里我先 SetRedraw(FALSE) 再 DeleteAllItems，否则删除旧数据的一瞬间界面会闪，而且滚动条会跳。全量重建不可避免会丢选中状态，如果产品要求切换区域后保留选中项，就在删除前先记录当前选中行的业务 ID，重建后通过 SetItemState 恢复选中。市场部门最在意这种细节，测试往往也盯这个点。
6.2 变体二：把下拉框嵌入到 List 的某一列里直接编辑
需求升级到这一步，才算真正碰触到 CListCtrl 的边界：用户点击状态列的某个单元格，直接在原地弹出一个下拉框选择。MFC 没有现成的控件支持，常见做法是动态创建一个 CComboBox 实例，在点击事件里把它移动到目标单元格的位置，选择完成后再销毁。
void CMFCAppDlg::OnLvnItemclickList(NMHDR* pNMHDR, LRESULT* pResult) { LPNMITEMACTIVATE pItem = reinterpret_cast<LPNMITEMACTIVATE>(pNMHDR); if (pItem->iSubItem == 2) // 只有状态列显示下拉框 { // 获取单元格在整个对话框上的矩形区域 CRect rcCell; m_list.GetSubItemRect(pItem->iItem, pItem->iSubItem, LVIR_BOUNDS, rcCell); // 创建并定位下拉框 if (m_comboInline.GetSafeHwnd() == NULL) { m_comboInline.Create(WS_CHILD | WS_VISIBLE | CBS_DROPDOWNLIST, rcCell, &m_list, IDC_COMBO_INLINE); } else { m_comboInline.ShowWindow(SW_SHOW); m_comboInline.MoveWindow(&rcCell); } m_comboInline.ResetContent(); // 这里把可选的几个状态项加进去 m_comboInline.AddString(_T("在售")); m_comboInline.AddString(_T("下架")); m_comboInline.AddString(_T("预售")); m_comboInline.SetCurSel(0); } *pResult = 0; }这个方案有几个关键点。下拉框的父窗口要传 &m_list，而不是对话框，这样下拉框跟着 List 的坐标系统走，移动 List 时下拉框不会错位。GetSubItemRect 取单元格区域时，LVIR_BOUNDS 表示不包含列头的完整单元格范围，如果你取的是 LVIR_LABEL，左边部分会被截断。最后在用户选择完成后，把值写回单元格，然后 ShowWindow(SW_HIDE) 隐藏这个下拉框，等下次点击再重新定位。
这个内嵌方案最怕的坑是滚动条：列表向下滚动时，浮动在单元格上的下拉框不会跟着滚，需要你在 WM_VSCROLL 里重新计算位置或者直接隐藏下拉框。这一条很少有人一开始就考虑，都是在测试阶段发现“下拉框飘在半空”才补上。
我自己最初实现这个功能时，也踩了行号错位的亏——排序后内嵌下拉框弹出的位置差了一整行，后来把所有行级操作全部改成 GetItemData 走业务 ID，才彻底安心。从那以后，我每接一个需要 List 联动下拉框的 MFC 项目，都强制先确认数据锚点和刷新方式，再写任何事件代码。希望帮到你。
本文还有配套的精品资源，点击获取
