简介：一份面向Windows Forms/WPF开发者的自定义控件示例，解决标准ComboBox只能单选、无法满足多选需求的场景。该Demo以Codebehind方式演示了如何继承ComboBox并集成CheckBox，在下拉列表中实现多选项勾选，可应用于用户权限配置、设置项筛选等界面。资源共55个文件，以C#源码（15个.cs）、XAML界面与逻辑（3个.xaml）、编译输出（exe/dll）及Visual Studio工程文件为主，压缩包约125KB，结构简洁、便于直接打开工程对照学习。目前已有498人学习下载。通过阅读和运行该示例，开发者可以掌握自定义控件渲染、CheckBox事件联动、数据源绑定等关键实现思路，在此基础上扩展搜索过滤或样式定制，能大幅提升多选交互的开发效率。
1. 让下拉框支持多选：带CheckBox功能的ComboBox实战解析
在做桌面端工具的时候，几乎每个开发者都会遇到一个尴尬的场景：功能明明很简单，但原生控件就是做不到。比如用户需要在一个下拉列表里勾选多个筛选项，ComboBox只能单选，ListBox又太占地方。这个“带CheckBox功能的ComboBox”资源解决的就是这个问题——在一套源码里既能保留下拉框的紧凑交互，又能让每个选项前面带一个复选框，鼠标点一下就能多选，选中的项统一显示在收缩后的框体里。适合正在做winform或类似桌面框架工具、被多选交互卡住、不想自己从头封装控件的开发者直接拿来改。
2. 为什么原生ComboBox做不到：先看它卡在哪
2.1 原生控件的单选逻辑与多选需求的矛盾
用过ComboBox的都知道，它本质上是一个文本框加一个下拉列表，下拉列表触发ItemSelect时只允许一条选中记录。代码里常见的写法是这样：
comboBox1.Items.Add("选项A"); comboBox1.Items.Add("选项B"); comboBox1.SelectedIndexChanged += (s, e) => { var selected = comboBox1.SelectedItem?.ToString(); Console.WriteLine($"当前选择：{selected}"); };这段逻辑在单选场景下没有任何问题，但当你尝试让它“勾选多个选项”时，原生控件根本没有CheckBox的概念。你把CheckBox塞进Items里，它只会显示一个类型的字符串，不会渲染出勾选框，用户点上去也只会触发选中事件，而不是勾选事件。这是控件的绘制机制决定的，不是改几个属性就能绕过去的。
2.2 常见的“野路子”方案为什么都翻车
动手能力强的开发者通常第一反应是：那我不用ComboBox了，直接放一个CheckedListBox？CheckedListBox确实支持多选勾选，但它不是下拉式的，永远占着一块界面区域。再或者有人想用“TextBox + ListBox + CheckBox”自己拼一个组合控件，结果要处理的交互细节远比想象中多——点击外部关闭下拉、滚动条联动、选中项回显、点击CheckBox不触发失焦……每一条都是坑。
我拆这套资源的时候发现，它并没有重新造轮子，而是基于ComboBox做自绘扩展。原理也很清晰：在ComboBox的DropDown事件里替换掉默认的下拉列表，用一个自绘的ListBox（里面每项都叠加绘制CheckBox）来承载选项，同时拦截鼠标点击，把“点击选中项”转换成“点击切换勾选状态”。把下拉框的显示文本绑定到所有已勾选项的拼接结果上。这个思路是正路，因为它没有抛弃ComboBox本身的折叠、失焦关闭等特性，只是在内部“偷梁换柱”。
2.3 这套资源的自定义控件结构拆解
下载下来的源码里，核心控件类命名大概是MultiSelectComboBox之类。它的基本结构可以这样理解：
| 成员 | 职责 |
|---|---|
| 内部ListBox | 替代默认下拉面板，逐项自绘CheckBox图标 |
| 勾选状态集合 | 用HashSet或List 记录每个索引是否被勾选 |
| ItemCheck事件 | 对外暴露，供业务层感知勾选变化 |
| SelectedText拼接逻辑 | 控制收缩状态下显示的文本格式，比如“A, B, C” |
我一开始以为这是个几百行的小Demo，拆开看才发现不是。里面处理了键盘上下键移动时CheckBox的高亮跟随、鼠标点击时判断命中区域是在框体还是文字上、下拉关闭时要不要保留已勾选状态等细节。这些恰恰是手写方案最容易漏掉的部分。
3. 动手接入项目：引用控件到跑通首轮勾选
3.1 把自定义控件文件加入你的解决方案
这套资源一般会提供一个或多个.cs源文件，最省事的方式是直接拷到你的项目里统一编译。操作路径很简单：
// 在你的WinForms项目中，右键项目 → 添加 → 现有项 // 选择 MultiSelectComboBox.cs（或对应文件） // 编译一次，工具栏里会出现新的自定义控件添加完成之后，界面设计器里的工具箱会自动刷新，你会看到一个带自定义图标的控件出现在组件列表里。如果没有出现，检查一下该文件是不是被编译成了“内容”而不是“编译”类型。右键文件 → 属性 → 生成操作改成 Compile，再重新生成解决方案。
3.2 从工具栏拖入窗体并初始化数据源
这个控件用起来和原生ComboBox几乎一样，唯一的变化是勾选逻辑不一样：
multiSelectComboBox1.DisplayMember = "Name"; multiSelectComboBox1.ValueMember = "Id"; multiSelectComboBox1.DataSource = GetFilterItems(); private List<FilterItem> GetFilterItems() { return new List<FilterItem> { new FilterItem { Id = 1, Name = "全部状态" }, new FilterItem { Id = 2, Name = "待处理" }, new FilterItem { Id = 3, Name = "处理中" }, new FilterItem { Id = 4, Name = "已结束" } }; }这里要注意一个关键点：这个控件内部并不会自动帮你把数据变成一个List ，它只是对每一行执行自绘操作。当某一项被勾选时，控件对外抛出的ItemCheck事件会告诉你勾选的是第几项，你再去数据源里取对应记录。如果直接给DataSource绑了一个DataTable，记得把DisplayMember和ValueMember都指对，不然事件回调里拿到的value大概率是默认ToString()结果。
3.3 读取勾选结果：事件回调与属性轮询双通道
我习惯用一个全局的HashSet 来承接勾选状态，这样后续做筛选、拼接SQL条件都方便。
private HashSet<int> selectedIdSet = new HashSet<int>(); private void multiSelectComboBox1_ItemCheck(object sender, ItemCheckEventArgs e) { var filterList = (List<FilterItem>)multiSelectComboBox1.DataSource; var item = filterList[e.Index]; if (e.NewState == CheckState.Checked) selectedIdSet.Add(item.Id); else selectedIdSet.Remove(item.Id); UpdateDisplayText(); }逻辑不复杂，但要留两个心眼。第一个是关于事件参数，ItemCheckEventArgs里既有Index也有NewState，NewState表示本次勾选动作完成后的新状态，不要再从控件当前状态反向推断。第二个是UpdateDisplayText这个刷新函数，必须在这个回调里主动触发一次，因为收缩区域的文本不会自动跟着勾选变化，这一点官方的CheckedListBox也不会帮你处理。
参数维度上，这个控件把“是否显示全选”做成可配置项，有的版本还支持“空文本提示”和“最大显示数量”。比如超过5个勾选项后折叠成“已选5项”，避免一行文本被塞得太长，这些在真实项目里都是刚需。具体属性名各版本略有差异，打开设计器看一眼PropertyGrid就能确认。
4. 定制显示与数据回填：从写死到动态适配
4.1 收缩态文本格式的三种设置姿势
默认情况下，勾选后的显示文本会把所有项的DisplayMember字段用逗号拼接起来。但这个默认行为在产品需求面前往往不够用，最常见的是需要“A、B、C等3个选项”这样的带数量文案。这个控件的作者通常会在内部暴露一个TextSeparator或者DisplayFormat的属性。
// 比如设置分隔符为"、" multiSelectComboBox1.TextSeparator = "、"; // 显示层强制限制最多显示3项，超出显示“等N项” multiSelectComboBox1.MaxShowItemCount = 3; multiSelectComboBox1.SuffixText = "等{0}项";注意这个模板占位符的写法，不同版本的参数名可能是{0}也可能是%count%，接的时候要去看源码里的Format调用。我见过有开发者直接把SuffixText设成“等”字，结果真实显示成了“A、B、C等”缺了数量，排查了半天发现是把占位符给丢了。
4.2 初始勾选回填：从已有配置还原界面状态
业务上还有一个高频场景——编辑弹窗打开时，需要把已经保存的筛选条件回显成勾选状态。直接给控件赋DataSource是不够的，必须走一遍“遍历所有项 → 判断Id是否在已存在集合中 → 设置勾选状态”的逻辑。
private void RestoreCheckedState(List<int> savedIdList) { var savedSet = new HashSet<int>(savedIdList); var filterList = (List<FilterItem>)multiSelectComboBox1.DataSource; for (int i = 0; i < filterList.Count; i++) { bool shouldCheck = savedSet.Contains(filterList[i].Id); multiSelectComboBox1.SetItemChecked(i, shouldCheck); if (shouldCheck) selectedIdSet.Add(filterList[i].Id); } UpdateDisplayText(); }这段代码的关键在于SetItemChecked这个方法，它不仅要改勾选状态集合，还必须强制触发一次重绘，否则界面上不会出现勾选效果，但内部状态已经变了。回填完成后手动调用UpdateDisplayText，修复边缘情况下文本不同步的问题。
4.3 动态增删选项时的状态联动
如果一个下拉列表的选项是从接口动态拉的，那勾选状态集合必须跟着数据集一起重建。直接把新List丢给DataSource，旧勾选索引就会错位——原来勾的是“处理中”，刷新后可能变成勾“待处理”。
常见做法是每次刷新前先记录已选中的ValueMember值，刷新后用值重新匹配：
private void RefreshData(List<FilterItem> newItems) { var previousSelectedIds = new HashSet<int>(selectedIdSet); multiSelectComboBox1.DataSource = null; multiSelectComboBox1.DataSource = newItems; RestoreCheckedState(previousSelectedIds.ToList()); }先把旧的勾选Id存下来，再全量重建数据源，最后回填。这一套顺序不能反。你如果先清DataSource再取selectedIdSet，取到的要么是错位索引要么直接抛异常。这个坑我踩过，后来就强制自己每次刷新都走这个顺序。
5. 避坑与排错：四个月使用中遇到的高频问题
5.1 下拉面板点选后立刻关闭，根本来不及勾第二个
现象：鼠标点第一个CheckBox，整个下拉马上就收起来了，连勾第二个的机会都没有。
原因：自绘列表的OnMouseClick事件没有被拦截，点击操作被透传给了底层的ComboBox选中逻辑，触发了原本的SelectedIndexChanged然后自动收起。
解决：在自定义控件的内部ListBox中重写WndProc或拦截MouseClick消息，判断鼠标落点是否在CheckBox图标区域。区域内的事件标记为Handled，阻止其冒泡；只有点击文本区域时才触发选中并关闭。拆源码时重点看OnMouseClick重写部分，判断思路是if (hitIndex >= 0 && e.X < checkBoxWidth)。
5.2 收缩框显示的文本和实际勾选List对不上
现象：第一次打开勾选了两项，关闭后再打开，显示的是三项，其中一项根本没点过。
原因：显示文本拼接的逻辑与勾选状态集合的赋值顺序不一致。通常是先更新了显示文本，再改勾选状态集合，导致某一次刷新读到的是旧状态。另一种情况是把文本刷新逻辑同时挂在了多个事件上，比如也挂在了DropDownClosed里，造成重复拼接。
解决：统一收敛到唯一的刷新入口，也就是UpdateDisplayText，内部先读勾选状态集合再生成文本。不要在ItemCheck之外的地方额外更新文本。检查所有对Text属性的赋值点，确保只有一处生效。
5.3 DataSource换成DataTable后事件取不到正确的行
现象：业务代码里ItemCheck事件返回的Index是0，但DataTable第一行显示的不是预期数据。
原因：DataTable绑定时没有指定DisplayMember，导致控件内部拿到的对象是DataRowView，而不是原始业务对象，索引取值自然错位。
解决：给DataTable的每一列设置好ColumnName，然后指定DisplayMember = "列名"; ValueMember = "另一列名"; 在事件回调里通过((DataRowView)multiSelectComboBox1.Items[e.Index]).Row来取整行数据。如果嫌DataRowView用着别扭，直接退回List 绑定的方式，业务代码清爽得多。
5.4 控件失去焦点时灰度显示，误以为被禁用
现象：窗体加载完控件是正常的，鼠标一点别的地方，整个下拉框变灰色，视觉上像被禁用。
原因：这是原生ComboBox的Enabled样式派生问题。自绘控件重写了OnDrawItem，但没有重写控件整体的禁用状态绘制分支，导致默认的灰色绘制效果覆盖了自绘内容。
解决：在OnPaint里判断Enabled属性，如果为true则强制用正常颜色绘制背景和文字。资源源码里如果有DrawMode = OwnerDrawFixed这行，基本就是这个原因。找到绘制背景色的分支，把灰化逻辑改成读自定义样式字典里的NormalColor即可。
5.5 加载大量选项时下拉弹窗有明显卡顿
现象：选项超过200条，每次点开下拉框要转半圈才出来。
原因：每一项在自绘时都执行了一次CreateGraphics或字体测量，测量文本像素宽度、绘制CheckBox图片都是耗时操作，量级一上来就卡。
解决：在构造函数里预测量最大文本宽度并缓存下来，绘制时直接复用缓存数据。另外把DoubleBuffered属性设为true，减少闪烁。如果数据量真的很大，建议做一次索引过滤，把前50条作为首屏渲染，滚动时再增量加载，体验会好很多。
6. 让控件更顺手：附加的快捷操作与默认值技巧
6.1 全选与清空：两个高频操作如何一键补齐
拆这套资源时我发现源码里并没有自带全选按钮，但事件系统完全支持外部触发全选。自己补一个扩展方法就能实现：
public void CheckAll() { for (int i = 0; i < this.Items.Count; i++) { this.SetItemChecked(i, true); } UpdateDisplayText(); }清空同理，就是把SetItemChecked(i, false)循环一遍。需要注意的是，反复调用SetItemChecked会触发多次ItemCheck事件，如果每个事件里都去更新数据库，会产生大量冗余操作。建议在批量操作前用一个布尔标志位抑制事件，比如isBatchUpdating = true;，循环结束再统一刷一次。
6.2 按回车键确认，按Esc键还原上一次选择
原生ComboBox在下拉状态下按Esc会收起列表，但勾选状态会被保留。这个行为在数据筛选场景下往往不符合直觉——用户打开面板乱点了一通，发现选错了，按Esc想回到之前的状态，结果错选依然保留。这个控件的源码里通常会有KeyDown预处理，可以自己接一层：
protected override void OnKeyDown(KeyEventArgs e) { if (e.KeyCode == Keys.Escape) { RestoreCheckedState(lastConfirmedIdList); this.DroppedDown = false; e.Handled = true; return; } base.OnKeyDown(e); }lastConfirmedIdList可以在DropDownClosed事件里更新，这样用户按Esc取消，按回车或者点击其他区域关闭都会保留正确状态。这个逻辑既不复杂又很实用，导航式的筛选弹窗里体验提升非常明显。
6.3 把勾选结果直接序列化成查询条件
最后分享一个我常用的收尾手法：把勾选结果序列化成给人看的筛选条件文本，同时生成给后端用的查询参数。这样界面上显示的是“待处理、处理中”，传给接口的就是status=2,3。
public string ToQueryString() { var selectedIds = selectedIdSet.ToList(); if (selectedIds.Count == 0) return string.Empty; return "status=" + string.Join(",", selectedIds); }这个写法的好处是后端接口不需要改，前端把字符串拼到请求URL上即可。当时我把这个控件集成到内部订单筛选工具里，就是靠这个ToQueryString直接对接原有查询接口，前后端改动几乎为零。从那以后我每次封装这类自绘控件，都会强制自己在交付前跑一遍“绑定数据 → 勾选 → 回填 → 序列化”的闭环，把默认值和边界情况提前暴露出来再交付。希望这个拆解能让你少走几步弯路。
本文还有配套的精品资源，点击获取
