在 Excel 里布置一张审批用的流程表，通常不只有格子：一个"审批通过"按钮、一列"已复核"复选框，再配一小段说明文字，版面才算完整。这几样东西还常常被收进同一个组里------先拖到一起，再执行组合，之后整组移动、一起复制、整体删除都只对组下手，比逐个摆弄省事，排版也不易散掉。
表单控件与普通形状混在一组里的文件，交到服务端表格组件手里，过去就常出岔子。读进来、改几笔、存回去，再导出成 PDF 或图片，组里的控件总在某一步走样：控件不见了、组的层级断掉、控件清单与形状清单对不上。这类问题常常要等文件被重新打开、或导出结果落到眼前时才暴露，排查起来并不容易。
GcExcel V9.2 让表单控件能安稳地待在组里。控件以正式成员的身份参与组的完整生命周期，读、改、存、导出各环节都把它当作组的一部分来对待。
组，是给"一批对象"用的
Excel 的形状分组，处理的从来不是一个对象，而是一批对象。几个形状组合之后，点一下选中的是整组，拖动是一起挪，复制粘贴一并发生，删除整组则成员随之消失。想在版面上把若干对象当作一块整体去排位置、调间距，组合几乎是必用的一步。
表单控件同样有进组的需要。按钮、复选框、选项按钮、标签，它们也占位置、有尺寸，可以被整体摆布，Excel 的形状分组模型本来就允许控件入组。一张审核表上的"审批通过""已复核""说明"，常常就是几个成组的控件：成组之后整组移动不散架，复制到别的工作表时一份就位，界面也整齐。
对做模板的集成方来说，组还是一种可复用的编排单位。把一组控件连同周边的形状摆好、成组，再复制到需要它的分表或版面上，整套相对位置一并带过去，比逐个重排可靠得多。模板里哪些控件是成组出现的，直接决定这份模板在服务端能否被放心地复制与搬运。
曾经，控件会在组里走丢
麻烦出在"组里的控件"上。此前 GcExcel 对这类控件的处理并不牢靠，工作簿只要含一个装控件的组，载入或保存就可能出问题------控件丢一个，或组的层级被压平，控件从原来的组里掉出来。
出问题的场合不止一种。控件可能在普通组里，组里只有控件与少量形状；也可能待在嵌套组里，外层组套着内层组，控件藏得最深；还常出现在混合组里，组里同时混着普通形状、图片、图表、连接线与文本框。组越深、成员越杂，载入、保存、导出时越容易走样。
丢失之外，还有登记对不上的毛病。一个组内对象在文件里留有两份登记：一份作为组内成员，一份作为工作表的控件。此前处理组内控件时，这两份登记偶尔不一致------控件清单里还在，组成员里却没了，或者反过来。程序想按控件去改它的位置，形状那一侧却没跟上，版面上便出现错位。
三种毛病的表现各不相同：载入即丢的，文件一打开控件就缺位；保存后再丢的，改动落盘的那一刻才消失。层级断裂常让控件从组里逸出、落回工作表顶层；集合不一致则让程序遍历控件时以为它还在组内，实际形状一侧已经找不到它。无论哪种，对依赖文件往返的服务端流程都是隐患。
现在，控件能安稳待在组里
V9.2 把表单控件正式纳入既有的形状分组。这次没有新增公开接口，延展的是已有的组合、取消组合、复制、删除等行为，让它们对组内控件同样生效：凡是原来对整组形状成立的操作，如今对组里的控件也成立。
处于工作表顶层的控件，现在可以与其它形状一起组合成一个组，组合这一步对控件与普通形状一视同仁。入组之后，控件如何被找到也有两条路径：组的成员集合里，控件以表单控件成员的身份列出，遍历组成员就能读到它的位置与属性；工作表面向控件的集合也仍然可以直接访问这个已被分组的控件，按控件处理时不必先绕过组。
两条路径各有用途。要整体查看一组控件在版面上的排布，从组成员一侧入手，能连带着看到同组的普通形状；只想改某个控件的文字或勾选状态，则从工作表的控件集合直接取用，不必先按组定位。两条路取到的是同一个对象，改了一处，另一侧的登记同步更新，不会出现两侧各执一词。
覆盖范围落在 Excel 表单控件这一类上：按钮、复选框、选项按钮、组合框、列表框、微调项、滚动条、分组框、标签，都具备作为组内成员的能力。其中按钮、复选框、选项按钮用于接收操作与勾选，组合框、列表框用于从预设项中选择，微调项、滚动条用于调节数值，分组框与标签主要承担分区和说明。这些用途不会因为控件进了组而改变。超出这一类的对象不在本次范围之内。
组与成员的整套生命周期
控件入组之后，组与成员各自的处理都按同一套规则走。复制一个组，组内控件随组一起复制出来，新组带着完整的一份控件成员，位置与属性照旧。只对组里某个控件单独复制、剪切或重复，同样按控件的既有规则处理，不会把它丢出组外。
删除的两个方向都处理干净。删除整个组，组内控件连带删除，不留残余；只删组里的一个控件，它会同时从组的成员集合与工作表的控件集合中移除，两侧不会留下对不上的记录。
取消组合则把组内控件还原成顶层形状，重新直接归属工作表，之后可以单独移动或再次组合。整张工作表被复制时，成组的控件也随工作表一并过去。组合、拆开、改动、再组合可以反复进行，控件各自的位置、尺寸与属性在这一过程中都不受影响。
保存的环节同样可靠。存回 XLSX，或转到 SJS、SSJSON 这类格式，组与控件的层级、组内成员的先后顺序、每个控件的位置尺寸都按原样保留。处理过程中对控件属性的改动，比如切换一个复选框的勾选状态、换掉按钮上的文字，也随文件存下，重新打开时仍在。
导出时不缺席
控件待在组里，不影响它出现在导出结果里。PDF、HTML 与图片导出都会把组内控件按原样画出来，位置、大小和组里其它成员保持相对关系，不会因为隔了一层组就渲染缺失。网页预览、截图生成这类直接看画面的场景，组内控件的观感与 Excel 中保持一致。
PDF 导出还保留着可交互的选项。开启交互式表单域导出时，组内受支持类型的控件按既有规则导出为可填写的 PDF 表单域，按钮可点按、复选框可勾选。收件人不必回到 Excel，在 PDF 阅读器里就能完成勾选与确认。
不在支持范围内的控件，则作为普通图形画在页面上，版式仍然完整。这一分寸与控件未成组时的规则一致，组不改变控件在导出时的待遇。
覆盖到哪里为止
该划清的边界也要说清。此次覆盖只针对 Excel 表单控件，前面列出的类型之外，ActiveX 控件与 OLE 对象不在承诺范围之内------即使它们被放进组里，其保留与可操作性也不受这次更新保障。文件里若有此类对象与控件混排，集成方需要另行评估处理。
对集成方而言，这套能力的落点是让流转不再绕路。一份带着成组控件的表格可以放心地交到服务端：程序按组处理布局、按控件读值与改值，再存回或导出交付，组还是那个组，控件还是那些控件。读、改、存、导出各环节遵循同一套行为，集成代码不必为"组里的控件"单开一套特判。做报表生成、流程自动化这类要反复读写文件的集成时，成组控件与普通形状一样，是可以托付的一部分。