开篇：金蝶云星空客户端是WPF技术实现，其前端控件包含有，通过基于.net WPF系统标准控件实现的自建控件，也有通过购买第三方控件厂商提供的基类控件进行封装应用控件，也有符合业务自定制控件，也有复杂应用多样式复杂控件等等，控件应用基于数据，标准应用场景，产品性能，第三方控件约束，控件本身技术约束等多方面综合原因，与架构师，设计师，性能师大神们综合讨论，金蝶云星空产品标准明确有些使用场景不支持进行说明

一、单据体拖拽保存

说明：标准产品不提供针对表格显示隐藏列的进行自动保存的方案，

原因：1、列的显示隐藏是具有业务含义的，不能作为布局的视图进行自动保存，如果一旦用户行为自动保存与插件写的业务含义的显示隐藏列会起冲突，如，用户拖拽了掉一个字段，但是插件强制代码visible（显示属性）显示出来，那控件是显示还是不显示呢？所以该方式有冲突，需求不合理，标准产品无法做到这种识别 2、提供拖拽列只是当前视图状态，方便用户可以去掉当前列，方便缩短可视列进行查看，此功能类似列头排序，列头小三角排序等功能类似，不能自动保存，当前拖拽后，列头右键有一个展示选择列的功能，可以将拖拽的列进行拖回等功能， 3、启用表格布局属性之后，关闭当前单据，表格会自动保存列顺序，宽度等信息， 综上分析，所以标准产品不支持该需求，如有此需求，客户请合理可以进行二开。 

建议方案：增加针对该单据做一个隐藏列的管理，用户根据选择自动隐藏列进行保存，打开单据时，插件可以默认将用户选择的列，设置隐藏即可 或者用户操作建议：用户可以把不需要显示的字段，拖到最后面，重要信息放在前面，进行顺序调整，满足用户一个侧重点列的不同需求

二、单据体自动行高和自动换行

说明：单据体不支持自动行高和自动换行

原因：1、自动换行是根据数据内容默认自适应的，控件内部在渲染无限计算时，会影响整个表格的渲染计算，极其影响渲染性能 2、单据体本身就是复杂编辑性表格控件，其单元格的编辑都是受不同字段类型对应的不同的独立的编辑控件，很多控件是按照控件定义严格控制属性意义，如单行文本就是单行文本的意义存在，不允许自动换行， 3、如果行高随内容自适应的话，整个表格的高度参差不齐，某个单元格数据大时会无限撑开，体验和人机效果不佳 所以，标准产品不考虑自动换行以及自适应行高的需求 

建议方案：二开可以插件强制改变每行的默认行高，二开详细见帖子：https://vip.kingdee.com/article/146453

三、富文本控件应用

说明：富文本控件不支持复杂应用，无法修复排版内容等细节问题

原因：标准产品的富文本控件的内部编辑是第三方控件提供的控件使用，该控件也是复杂控件，内容定义逻辑，在silverlight和WPF技术是无法干预到的，该控件细节上的使用或许有问题或者不好用等问题，但是标准已经不更新该第三方控件 

建议方案： 1、尝试使用wpf客户端使用该控件，在WPF端使用的该控件，或许会优越一点 2、如果复杂编辑内容场景有问题或者不支持，请酌情使用附件的word文档的方式代替，其富文本的业务作用 3、可以简化场景的编辑内容格式，如果精细化的设置无法支持或者有问题，请酌情简化适当可以用的方式

四、快捷过滤控件切换条件保留值

说明：每个条件值的编辑控件，是根据条件项对应的字段类型动态构造生成；条件项的数据格式、控件属性不同，比如：条件项可能是基础资料，文本，数字，下拉，复选框等等字段，每个字段都对应不同的字段录入控件，其绑定数据源格式不同，所以当切换不同字段类型的条件值时，对应条件值数据也无法保留，必须强制清空。

建议方案：系统支持，快捷过滤切换相同类型字段保留数值，当条件项切换成相同类型字段时，条件值保留原来值。列表插件开启样例：

this.View.GetControl("FQKFILTERPANEL").SetCustomPropertyValue("SameXTypeRowTakeValue", true);

五、单据体，列表等分组自动展开

说明：树形表格，或者单据分组等功能，都涉及到自动展开功能，内部经过和架构师以及设计师，多次沟通之后，均不支持默认全部自动展开功能，控件也不提供接口

原因：表格承载大数据渲染下，自动展开极其影响其渲染速度，导致卡死等现象问题，则影响性能等功能，暂不支持 不管是树形表格，还是单据体分组，本身就是一个树形结构数据，在控件渲染内部会组合树形结构，其控件渲染实例化构造多积的形式重复运算，所以控件会默认不展开，对父级进行优先渲染，提高渲染性能 当前是根据默认焦点所在行，会自动展开。

六、表格自带的Ctrl+F模态窗口进行查找

说明：表格自带的ctrl+F查找，是弹出了模态窗口，在窗口中输入搜索内容，按回车可以对当前表格内数据进行模糊搜索定位

原因：表格自带的ctrl+F查找必须是弹出模态窗口，由于实时查找是先固定数据源下进行数据精准查找，如果不是模态窗口，用户可以任意操作表格里的数据，那么无法精准到数据。再者修改了数据，就必须控制提交数据，那么对于简单应用的查找来说，影响了大数据下的查找性能。

七、甘特图控件应用

说明：甘特图控件应用，只是展示数据，不支持编辑功能

原因：甘特图作为任务排成的显示，实时数据可以用表单形式进行录入后，进行更新甘特图展示，如果需求如实时编辑等深入应用，就建议需要寻找第三方控件。排程应用本身是一个重量级的应用，一般都是通过专门的排程软件来实现的。比如微软的Project，XGantt等。

星空的甘特图展示应用参考文章https://vip.kingdee.com/article/39756

八、列表选择合计的交互应用说明

说明：列表选择合计，（点击列表选项，“列表选中行合计字段”页签，勾选合计的数字字段），交互是：在列表选中行之后，按住Shift键，鼠标滑动一下，就会弹出一个黄色的提示，里面会有根据勾选字段的合计

九、表格首行过滤行、列头漏斗过滤进行表格过滤只过滤当前页数据

说明：单据列表，单据体表格，报表，基础资料下拉列表、F8弹窗基础资料列表等所有表格控件的首行过滤行、列头漏斗过滤进行过滤时，只是过滤当前页数据，而不是过滤整个服务端数据库的数据进行过滤

原因：表格以上两个过滤只是处理当前数据，有使用过其他产品表格过滤的经验的人都明白这个道理，这样的过滤只是处理当前页所已经从服务端（认作是数据库）已经查询过后的数据，并不是实时查询数据库，其作用主要是快速针对当前页数据进行快速过滤。如需要针对要起到查询条件到服务端进行查询数据，则针对不同的功能场景，使用不同的过滤做法，如，列表操作使用过滤界面过滤，或者快捷过滤进行过滤数据，单据体过滤，可二开插件实现过滤条件的过滤数据等等。

十、启用本地配置“列表分组”，列表列头右键有分组功能，为何单据体右键没有

说明：单据启用本地配置的“列表分组”属性，打开列表，列表的列头右键有分组菜单功能，但是单据体右键列的列头右键却没有

原因：

1、本地配置“列表分组”，只是针对列表功能放开可以用户习惯和需求功能，增加列表对数据的需求处理。

2、单据体不包含这种设置，因为单据体本身设计是根据业务功能需求定义，可在BOS设计器里面单据体的“单据体分组信息”属性，设定分组，分组统计，合计等功能，以免造成冲突，所以本地配置的该属性不运用在单据体上。

十一、单据体编辑单元格不支持插件设置背景色

说明：单据体单元格编辑状态下，不支持差价设置背景色，某些列字段支持设置前景色，锁定单元格支持背景色已经前景色设置

原因：

1、前端表格控件复杂性的机制问题，标准前端对应的可编辑控件有很多如，文本，日期，基础资料，下拉列表，弹性域，时间，长日期，小数，整数等等，然而，这些编辑控件都有自身的业务特性功能，又运用在多个复合控件里面，如，快捷过滤，过滤表格，过滤高级表格，单据体，树形单据体，树形表格等等，与复杂控件组合使用，为了增加控件的复用性，表格单元格使用的控件与单据头单个控件是一个控件，然后表格限制的底层机制问题，如激活编辑单元格是通过点击进行激活，焦点离开则自动视为非编辑控件，所以其可编辑特性的背景色不仅仅是通过改变单个编辑控件改变而改变，然后锁定单元格不需要编辑，统一使用的近似的只读模板进行单元格的呈现，则统一处理背景色和前景色。所以编辑单元格不支持背景色处理

2、基于性能考虑，众所周知，只有锁定单元格的表格记载速度要快于带有可编辑性单元格的速度（如审核查看与修改对比），是因为表格自身就是非常复杂很重的控件，其单元格的个数由行X列数决定，单元格又挂载的实际是一个等同的单据头的可编辑性控件（第1点原因解释），当表格经常与服务端进行多次来回交互数据时，刷星整个表格，就会产生重复产生过多的内存消耗以及对象处理，为了减少可编辑性的性能影响的属性（如背景色渲染，换行属性）等，一般不建议使用，所以内部评估可编辑性单元格不支持背景色

建议方案：如果遇到需要行标识处理，1、改变为锁定单元格进行背景色设置，2、可编辑时，使用前景色的设置效果（有些控件也不支持前景色，正常文本，数字是可以的），3、增加特殊标识字段处理（业务需求而定）

参考知识：二开前景色与背景色的相关插件案例：

https://vip.kingdee.com/article/91482979196651520?productLineId=1&isKnowledge=2

https://vip.kingdee.com/article/160697075289073920?productLineId=1&isKnowledge=2

附：在产品的多应用场景下，为满足所有用户的使用习惯，兼容无数家客户，前端控件也是很艰难的事情^_^