简介：面向Windows桌面应用开发者的自定义控件示例，针对标准ComboBox仅支持单选、难以承载多选交互的痛点，给出带复选框下拉列表的实现方案与可运行演示。压缩包共55个文件，约125KB，以15个C#源码和3个XAML界面文件为核心，并包含sln/csproj工程文件、资源、配置及编译产物，解压后可直接打开解决方案对照调试。已有498人学习下载。示例以MultiSelectComboBox和主窗口调用为主线，呈现CheckBox列表的渲染、勾选状态与数据源同步、事件响应以及Codebehind组织方式，读者可据此掌握自定义控件继承、下拉面板重写与数据绑定等关键环节，并迁移到权限配置、条件筛选等多选场景，提升桌面应用的交互灵活性与开发效率。

1. 下拉框里塞复选框：一个被反复重造的小控件

后台系统里总有几个地方绕不过去：给一条记录打标签、给一个角色配权限、给一次推送挑接收范围。选项动辄二三十个，用户得从中勾出好几个，普通 ComboBox 只能单选，摊一排 CheckBox 又太占表单空间。带 CheckBox 功能的 ComboBox 就是为这个场景准备的：收起时是一行文本，展开后每个条目左边带一个勾选框，选完自动回显「已选 3 项」这类摘要。它不是标准控件，.NET 的 WinForms 和 WPF 都没有现成的，所以每隔一段时间就有人重新写一遍。这篇笔记拆的就是一份可以直接编译运行的自定义控件实现，讲清它怎么把 ComboBox 拆成绘制层和弹出层，怎么处理勾选事件里的那个坑，以及拿到代码后往哪个方向改最省事。

2. 架构与选型：先想清楚 ComboBox 到底卡在哪

2.1 原生 ComboBox 为什么加不进 CheckBox

很多人的第一反应是给 ComboBox 的 Items 里塞 CheckBox 对象，跑起来直接翻车——Items 只接受任意 object 作为数据项，它不是控件容器，放进去的 CheckBox 不会被实例化成一个可交互的子控件，只会被 ToString 成一行文字画出来。第二条路是打开DrawMode = OwnerDrawFixed自己画，这条路能画出勾选框的样子，但画出来的东西是死的：鼠标点下去命中的仍然是「选中某一项」这个原生行为，拿不到勾选框区域的独立点击事件，也没法让某一项的勾选状态和「当前选中项」解耦。

所以这个控件的核心矛盾在于：ComboBox 的显示区需要 OwnerDraw 来定制外观，而它的下拉区需要换成一个真正能承载勾选交互的列表控件。把这两件事拆开，问题就有解了。

2.2 三层结构：绘制层、弹出层、数据层各管一段

拆开之后的职责划分是这样的：

这种拆法的好处是每一层都能单独换。比如后面想加一个搜索过滤框，只需要在弹出层里塞一个 TextBox，数据层过滤完再刷 CheckedListBox，绘制层完全不用动。如果用完全自绘的 Control 一把梭，加需求的时候就得从头改到尾。

提示：这三层不是必须凑齐的。如果项目里只在一个窗体用一次，直接继承 ComboBox 把逻辑全写在一个文件里也能跑；但只要控件会被复用超过三次，按这三层分文件，后面改起来会轻松很多。

2.3 工程目录：控件库和演示程序分开

推荐把控件做成独立的类库项目，演示程序单独一个 exe 引用它，这样控件可以直接复制到别的解决方案里用。

CheckedComboBox.sln ├── CheckedComboBox.Controls/ # 控件类库 │ ├── CheckedComboBox.cs # 主控件，继承 ComboBox │ ├── CheckedComboBoxItem.cs # 条目模型，带 Text / Value / Checked │ ├── CheckedComboBoxRenderer.cs # 绘制逻辑，抽出来方便换主题 │ └── CheckedComboBoxDesigner.cs # 设计器支持，可选 └── CheckedComboBox.Demo/ # 演示程序 ├── MainForm.cs └── MainForm.Designer.cs

把绘制逻辑单独抽成一个Renderer类不是过度设计。默认的ControlPaint.DrawCheckBox画出来的是系统经典样式，在有主题色的系统上会显得很突兀。抽出来之后，想换成自绘的圆角勾选框，只需要实现一个新的 Renderer，主控件一行不用改。

2.4 三条必须提前定下的设计约束

动手写之前有三件事必须先定，否则写到一半会推倒重来。

第一是单选兼容。有些表单里同一个控件既要支持单选又要支持多选，常见做法是留一个SelectionMode属性，单选时在 ItemCheck 里把其他项全部取消勾选。这个开关要在数据层就判断好，别等到绘制层再去补救。

第二是只读模式。控件经常要放在「查看详情」页里，这时候下拉不能弹出来。ComboBox 自带的Enabled = false会把整行文字变灰，视觉上太重，通用做法是加一个ReadOnly属性，在下拉触发的地方直接 return，外观不变，行为禁用。

第三是数据源绑定。手写Items.Add在演示程序里够用，真实项目里基本都是从 List 或 DataTable 绑过来，需要DataSource、DisplayMember、ValueMember三个属性。绑定时机没处理好，勾选状态会在数据刷新时被清空，这个坑后面单独说。

3. 渲染层拆解：OnDrawItem 里把每个条目画成带勾选框的一行

3.1 打开 OwnerDraw 之前要设的四个属性

渲染层的入口是这几个属性，在构造函数里一次设好：

public CheckedComboBox() { // 必须开启自绘，否则 DrawItem 根本不会触发 this.DrawMode = DrawMode.OwnerDrawFixed; // 可编辑风格，这样才能用代码给编辑区赋「已选 N 项」这样的摘要文本 this.DropDownStyle = ComboBoxStyle.DropDown; // 行高调大一点，勾选框和文字才有呼吸空间 this.ItemHeight = 22; // 把原生下拉压到 1 像素，视觉上等于禁用，实际弹出交给自定义面板 this.DropDownHeight = 1; this.MaxDropDownItems = 8; BuildDropDown(); // 初始化弹出层，下一章展开 }

DropDownStyle这里选的是DropDown而不是DropDownList，原因很实际：在DropDownList风格下，ComboBox 的Text属性 setter 会直接抛异常，而我们需要用代码把编辑区文本改成「已选 3 项」。选DropDown之后，需要在KeyPress和KeyDown里把用户的键盘输入挡掉，让它行为上等于只读。这个权衡在很多实现里都能看到，代价是要多写两行拦截代码。

DropDownHeight = 1是压制原生下拉的常见手法。原生下拉的高度被压到 1 像素后基本看不见，DropDown事件里改弹自己的面板。另一种更彻底的做法是完全继承Control自绘，边框、箭头、焦点框都得自己画，工作量大一倍，除非有特殊视觉要求，一般不值得。

3.2 DrawItem 完整代码与逐行说明

下拉面板里的每一行都由这个方法画出来：

private void OnDrawItem(object sender, DrawItemEventArgs e) { // 设计器里控件刚拖上来时 Items 为空，索引可能是 -1 if (e.Index < 0 || e.Index >= _items.Count) return; bool isSelected = (e.State & DrawItemState.Selected) == DrawItemState.Selected; // 1. 先铺底：选中行用高亮色，普通行用控件背景色 Color backColor = isSelected ? SystemColors.Highlight : this.BackColor; using (var backBrush = new SolidBrush(backColor)) { e.Graphics.FillRectangle(backBrush, e.Bounds); } // 2. 算勾选框矩形：左侧留 4px 边距，垂直方向居中 const int boxSize = 13; const int leftPad = 4; int boxTop = e.Bounds.Top + (e.Bounds.Height - boxSize) / 2; var boxRect = new Rectangle(e.Bounds.Left + leftPad, boxTop, boxSize, boxSize); // 3. 按条目的勾选状态画勾或画空框 var state = _items[e.Index].Checked ? ButtonState.Checked : ButtonState.Normal; ControlPaint.DrawCheckBox(e.Graphics, boxRect, state); // 4. 画文字，起点跳过勾选框占用的宽度 var textRect = new Rectangle( boxRect.Right + 6, e.Bounds.Top, Math.Max(0, e.Bounds.Right - boxRect.Right - 10), e.Bounds.Height); TextRenderer.DrawText( e.Graphics, _items[e.Index].Text, e.Font, textRect, isSelected ? SystemColors.HighlightText : this.ForeColor, TextFormatFlags.VerticalCenter | TextFormatFlags.EndEllipsis); // 5. 键盘停在当前行时补一个焦点虚线框，不然看不出焦点在哪 if ((e.State & DrawItemState.Focus) == DrawItemState.Focus) { ControlPaint.DrawFocusRectangle(e.Graphics, e.Bounds); } }

几个参数值得单独说一下。e.Index是当前要绘制的条目在Items集合里的下标，e.State是一个位标志枚举，DrawItemState.Selected表示这一行正被键盘或鼠标高亮，DrawItemState.Focus表示焦点在这一行上，两个要分开判断，不能混用。e.Bounds是这一行的完整矩形，包含行高，所以垂直居中的计算直接用e.Bounds.Height。

ControlPaint.DrawCheckBox是 Windows 原生勾选框的封装，接受ButtonState枚举，Checked画勾，Normal画空框。它在高 DPI 环境下会自动按系统缩放绘制，比自己拿Graphics.DrawLine画两条线要稳。主持人如果说这个控件「看起来太素」，替换点就是这一行，改成自绘圆角矩形加对勾路径即可。

文字用TextRenderer.DrawText而不是Graphics.DrawString，前者走 GDI 路径，和 WinForms 其他控件的文字渲染保持一致，不会出现同一窗口里字体粗细对不上的问题。EndEllipsis保证超长文本自动截断成省略号，配合Math.Max(0, ...)防止宽度算成负数导致异常。

3.3 高 DPI 和主题色的适配

三处地方在高 DPI 下容易出问题。行高写死成 22 在 150% 缩放下会显得拥挤，正确的做法是构造时按DeviceDpi换算：

protected override void OnHandleCreated(EventArgs e) { base.OnHandleCreated(e); // 按当前 DPI 比例放大行高，96 是基准 DPI this.ItemHeight = (int)(22f * this.DeviceDpi / 96f); }

勾选框尺寸同理，boxSize不要用常量 13，改成按 DPI 换算的字段。字体一般不用管，WinForms 在进程清单声明了 PerMonitorV2 之后会自动缩放，但控件自己算的像素值不会，这两者不同步就会出现「字变大了框没变大」。

主题色方面，SystemColors.Highlight在深色主题下是深蓝底白字，在浅色主题下是浅蓝底黑字，直接用它基本能跟随系统。如果应用有自己的品牌色，就在 Renderer 里换掉这两个颜色，记得同时换背景色和文字色，只换一个会出现「白字白底」。

还有一种玄学情况：在某些显卡驱动加远程桌面的组合下，ControlPaint.DrawCheckBox画出来的勾会偏移一个像素。碰上这种问题不用深究，改成用e.Graphics.DrawRectangle加DrawLine手画就绕过去了。

3.4 编辑区的文本怎么回显

编辑区显示什么，直接决定这个控件好不好用。三种策略各有适用场景：

实现上是统一在一个RefreshEditText()方法里做，勾选状态一变就调用：

private void RefreshEditText() { var checkedItems = _items.Where(i => i.Checked).ToList(); if (checkedItems.Count == 0) { this.Text = string.Empty; // 没选时留空，靠 Watermark 提示 } else if (checkedItems.Count <= 3 && DisplayMode == DisplayMode.Full) { this.Text = string.Join(", ", checkedItems.Select(i => i.Text)); } else { this.Text = $"已选 {checkedItems.Count} 项"; } // 光标挪到末尾，避免用户点进来时插入符停在中间 this.SelectionStart = this.Text.Length; this.SelectionLength = 0; }

注意这里每次都要重设SelectionStart。因为DropDown风格下编辑区是可编辑的，用户点进来时如果光标停在文字中间，再配合键盘拦截没写全，可能会出现能删字符的漏洞。把光标推到末尾是治标，真正的只读还得靠KeyPress里把e.Handled置为 true。

注意：RefreshEditText在构造阶段调用时，控件的句柄可能还没创建，直接设Text有时会触发一次多余的TextChanged。稳妥的做法是在方法开头判断this.IsHandleCreated，没创建就存到字段里，等OnHandleCreated再赋一次。

4. 弹出层拆解：用 ToolStripDropDown 把 CheckedListBox 挂到下拉位置

4.1 宿主容器的构造与尺寸计算

弹出层的核心是把CheckedListBox塞进ToolStripControlHost，再由ToolStripDropDown承载。这套组合的好处是弹出层自带阴影、边缘不抢焦点、点击外部自动关闭，省了很多手工处理。

private ToolStripDropDown _dropDown; private ToolStripControlHost _host; private CheckedListBox _listBox; private void BuildDropDown() { _listBox = new CheckedListBox { CheckOnClick = true, // 点一次就切换勾选，不用点两下 BorderStyle = BorderStyle.None, IntegralHeight = false, // 关掉自动取整，否则最后一行的行高被吃掉 Font = this.Font }; _listBox.ItemCheck += OnListBoxItemCheck; _host = new ToolStripControlHost(_listBox) { Margin = Padding.Empty, Padding = Padding.Empty, AutoSize = false // 尺寸完全由我们控制 }; _dropDown = new ToolStripDropDown { Padding = Padding.Empty, AutoClose = false, // 勾选过程中绝不能自动收起 DropShadowEnabled = true }; _dropDown.Items.Add(_host); }

CheckOnClick = true是这整段里最关键的一行。默认情况下CheckedListBox要求先选中某一行，再点一次才切换勾选状态，两步操作反人类。打开这个属性后单击即勾选，符合用户对下拉多选的预期。

AutoClose = false同样关键。ToolStripDropDown默认在点击子项后自动关闭，而恰好CheckedListBox的勾选操作会被识别成「点击子项」，导致用户勾一个就收起了面板，得反复展开。关掉自动关闭后，收起时机完全由代码控制，一般是点击面板外部或者按回车键时收。

4.2 打开下拉：位置、尺寸、焦点三件事

protected override void OnDropDown(EventArgs e) { // 不调用 base，屏蔽原生下拉的展开逻辑 if (this.ReadOnly) return; // 尺寸：宽度跟下拉框对齐，高度按条目数和上限取小 int visibleRows = Math.Min(_listBox.Items.Count, this.MaxDropDownItems); int height = visibleRows * _listBox.ItemHeight + 2; // +2 补边框 _host.Size = new Size(this.DropDownWidth, Math.Max(height, _listBox.ItemHeight)); // 位置：贴在下拉框正下方，屏幕坐标为基准 Point screenPoint = this.PointToScreen(new Point(0, this.Height)); _dropDown.Show(screenPoint); // 焦点给到列表，键盘操作才生效 _listBox.Focus(); if (_listBox.Items.Count > 0 && _listBox.SelectedIndex < 0) { _listBox.SelectedIndex = 0; } }

OnDropDown在继承 ComboBox 的写法里是可行的重写点，但即使重写了它，原生下拉仍然会弹出来——这就是前面设DropDownHeight = 1的原因。两件事配合起来，原生下拉被压到看不见，自定义面板在事件里弹出来，视觉上是一体的。

位置计算用PointToScreen而不是Location，是因为弹出层需要一个屏幕绝对坐标，用控件相对坐标在窗体被移动、缩放或者多显示器环境下会偏移。这个坑很隐蔽：单屏调试时完全正常，用户接了外接屏一拖就露馅。

高度那个+2是给面板边框留的。如果不加，最后一行会被边框压住半截。IntegralHeight = false也是同一个目的，它默认会按整行高度向上取整容器高度，在小尺寸面板上会显得很怪。

4.3 键盘交互：空格勾选、回车关闭、方向键移动

鼠标操作写完只算一半，键盘不通的控件在真实项目里会被用户投诉。核心是让键盘事件从 ComboBox 转发到 CheckedListBox：

protected override bool ProcessCmdKey(ref Message msg, Keys keyData) { if (_dropDown != null && _dropDown.Visible) { switch (keyData) { case Keys.Space: // 空格切换当前行的勾选状态 if (_listBox.SelectedIndex >= 0) { bool now = !_listBox.GetItemChecked(_listBox.SelectedIndex); _listBox.SetItemChecked(_listBox.SelectedIndex, now); } return true; case Keys.Enter: // 回车收起面板，同时把焦点还回主控件 _dropDown.Close(); this.Focus(); return true; case Keys.Escape: _dropDown.Close(); this.Focus(); return true; case Keys.Up: case Keys.Down: // 方向键交给列表自己处理，但要在面板可见时才转发 _listBox.Focus(); return false; } } return base.ProcessCmdKey(ref msg, keyData); }

ProcessCmdKey比KeyDown更早拿到按键，适合做这种跨控件的转发。返回true表示事件已处理，不再往下传，避免空格同时触发按钮点击之类的怪事。

上下方向键那里返回false是有意的：让事件继续传给当前有焦点的控件，而焦点已经在_listBox上，它自己会把选中行上下移动。如果这里返回true，方向键就废了。

还有一个细节是按下拉框本身的时候。用户习惯是点一下展开，再点一下收起。这个「再点一下」得自己实现：

protected override void OnMouseDown(MouseEventArgs e) { if (_dropDown != null && _dropDown.Visible) { _dropDown.Close(); // 面板已展开时再点主控件，收起 return; } base.OnMouseDown(e); }

4.4 勾选结果的回写链路

从用户点下勾选框，到编辑区文字变化，中间要串起三段：

第一段是CheckedListBox触发ItemCheck，这时勾选状态还没真正提交到项上，拿到的是即将变成的值。第二段是把这个值同步到内部的_items集合，因为绘制层读的是_items而不是CheckedListBox的项。第三段是调用RefreshEditText()刷新编辑区，再触发对外的ItemCheckedChanged事件。

分三段而不是一把梭的原因是可测试性。_items是纯数据，可以脱离 UI 单独跑单元测试；CheckedListBox的项只是展示用的镜像，坏了可以随时从_items重建。这套结构在后面加数据源绑定时会救你一命，改绑定的逻辑只需要重写「数据到_items」这一段。

5. 避坑记录：五个让我返工的细节

5.1 现象：ItemCheck 里读出来的勾选状态是旧的

现象：在ItemCheck事件里打日志，发现GetItemChecked(e.Index)拿到的是操作前的值，用户勾上之后读到 false，取消勾选之后读到 true，导致对外事件发出去的状态永远是反的。

原因：ItemCheck的触发时机在状态真正写入之前。这是 WinForms 里少数几个「事件名和行为不完全对应」的地方，文档里一句话带过，实际写的时候不看就中招。

解决：用e.NewValue判断即将变成的状态，或者在内层处理完之后用BeginInvoke延后一拍再读：

private void OnListBoxItemCheck(object sender, ItemCheckEventArgs e) { // 用 e.NewValue，不要用 GetItemChecked bool willBeChecked = e.NewValue == CheckState.Checked; _items[e.Index].Checked = willBeChecked; // 状态回写和界面刷新延后到事件循环下一拍，此时 CheckedListBox 已完成更新 this.BeginInvoke(new Action(() => { RefreshEditText(); RaiseItemCheckedChanged(_items[e.Index]); })); }

BeginInvoke那层不能省。如果不延后，RefreshEditText里如果还读了CheckedListBox的任何状态，拿到的又是旧的。

5.2 现象：勾一个选项面板就收起来了

现象：用户点第一个选项，勾上了，面板同时消失，得再点开勾第二个。选了五个标签点了十次鼠标。

原因：ToolStripDropDown默认把子控件上的鼠标点击识别为「选中并关闭」。这个默认行为在菜单场景下是对的，在多选场景下就是灾难。

解决：构造时设AutoClose = false，然后自己接管关闭时机。关闭点有三个：点击面板外部、按回车、再点一次主控件。前两个在上一章已经覆盖，第三个靠OnMouseDown里判断面板可见性。设了AutoClose = false之后要记得在控件Dispose时把_dropDown也释放掉，否则会漏一个窗口句柄。

5.3 现象：重新绑定数据源后，之前勾的项全没了

现象：页面上有个刷新按钮，点了重新从服务端拉数据赋给DataSource，用户已经勾好的选项全部清空，体验很差。

原因：DataSource赋值会重建整个项集合，CheckedListBox的所有项都是新建的，勾选状态自然是默认的未选中。内部_items如果跟着重建，原来的在勾选状态也一起丢了。

解决：绑定时先按业务主键把旧的勾选状态存成一个集合，重建完之后再回填：

public void RebindDataSource(IList<CheckedComboBoxItem> newItems) { // 1. 先记住旧数据里哪些主键是勾上的 var checkedKeys = new HashSet<string>( _items.Where(i => i.Checked).Select(i => i.Value)); // 2. 重建内部集合和列表项 _items.Clear(); _items.AddRange(newItems); _listBox.Items.Clear(); // 3. 回填勾选状态 for (int i = 0; i < _items.Count; i++) { _items[i].Checked = checkedKeys.Contains(_items[i].Value); _listBox.Items.Add(_items[i].Text, _items[i].Checked); } RefreshEditText(); }

这里用Value做主键匹配，所以条目的Value必须在业务上唯一且稳定。如果服务端返回的Value是自增 ID 还能用，如果是每次刷新都重新生成的 GUID 就匹配不上，得换业务编码。

5.4 现象：150% 缩放下勾选框被切掉一半

现象：开发机 100% 缩放一切正常，到 150% 缩放的笔记本上，勾选框只露出上面三分之二，下面被行边界裁掉了。

原因：ItemHeight写死成 22，但系统缩放后ControlPaint.DrawCheckBox画出来的框按 DPI 放大了，垂直居中的计算又用的是旧的固定值，两者对不上。

解决：行高和勾选框尺寸都改成按DeviceDpi换算，并且在OnHandleCreated里重新计算一次，因为句柄创建前DeviceDpi拿到的是默认值 96。跨显示器拖动的场景还要处理WM_DPICHANGED消息，简单点的做法是监听DpiChangedAfterParent事件重设行高。

5.5 现象：面板展开后点别的地方不关闭，一直浮在上面

现象：偶发，把主窗体切到后台再切回来，下拉面板还在，而且层级跑到别的窗口上面去了。

原因：AutoClose = false关掉了所有自动关闭逻辑，包括「失去焦点时关闭」。程序切换到其他窗口时，弹出层本身没有收到关闭指令。

解决：给主控件和弹出层都挂上失焦处理，主窗体Deactivate时强制关闭：

private void HookCloseEvents() { // 主控件失去焦点时关闭，但焦点转移到面板内部时不能关 this.Leave += (s, e) => { if (!_dropDown.Focused && !_listBox.Focused) _dropDown.Close(); }; // 面板本身失去焦点也要关 _dropDown.Closed += (s, e) => this.Focus(); }

_dropDown.Focused这个判断不能少。点击面板里的选项时，焦点会从主控件转到面板内部，如果这时直接关，用户永远勾不上。判断顺序是先看面板有没有焦点，再看列表有没有焦点，两个都没有才关。

6. 二次开发：往搜索过滤和跨框架迁移两个方向改

拿到这份代码之后，最值得先做的改造是加一个搜索框。选项超过 30 个之后，纯靠滚动找效率很低，而加搜索的改动面很小，基本只动弹出层。

具体做法是在ToolStripDropDown里再加一个ToolStripControlHost，里面放一个TextBox，Dock = Top，放在列表上面。TextChanged里按_items的Text做不区分大小写的模糊匹配，把匹配结果重新填进_listBox.Items。注意勾选状态要按_items为准重建，不能直接读列表项，否则过滤一次再清空过滤条件，之前勾的会丢一半。过滤时还要临时关掉ItemCheck的处理，避免程序自动重建列表的行为被当成用户操作，把内部状态改乱。

第二个方向是跨框架迁移。这份实现是 WinForms 的，但三层的思路可以直接搬到别处：

WPF 那边Popup的StaysOpen属性对应这里的AutoClose，坑几乎一模一样：设成 false 之后得自己处理点击外部关闭，常见做法是挂一个全屏透明遮罩层接点击事件。前端组件库里的Select加了multiple之后的行为差异也是同一个来源。

验证改造是否成功，我一般跑三个手工用例。第一个是勾选五个选项，收起面板看编辑区是否显示「已选 5 项」，再展开看五个是否都还在勾上。第二个是切换系统缩放比例到 150%，看勾选框有没有被裁。第三个是把窗口拖到第二个显示器再展开面板，看位置有没有偏。这三条覆盖了状态同步、DPI、多屏坐标三类最容易返工的问题。

血泪经验是：这个控件看着简单，真正花时间的全在边界条件上。从那以后我每次动这类下拉控件的代码，都会先把「空数据、单条数据、超长文本、高 DPI、多显示器」这五个用例手动走一遍再提交，比事后被测试打回来省太多时间。希望帮到你。

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