建议增加组合框/单选按钮/组合复选框等单元格插件的获取文本公式

以组合框为例，再页面设计时，可以拖入组合框，设置健值对应，例如 A--一级，B--二级，C--三级。 值对照数据库代码，显示的文本易于展示。这个很方便。
在其他单元格想获取到这个组合框的内容时，通常的需求时要获得组合框当前选项的值，即A，B，C。可以在目标单元格直接编辑公式 =A2即可，这个也很方便。
但是有时候存在另外一种需求，即现在想在其他单元格获取组合框当前的文本，而不是值。如果不通过js的话，能否增加一个简单的公式函数来实现？
例如编辑公式 =getCellText(A2)  这样？
在单选按钮，组合复选框也同样。

等等哈~
老铁，您为什么需要获取这个显示值呢？

不应该把所有的判断的值，都判断成值而不是显示值呢？
你要是实在需要的话，直接给他设置一个单元格名称（如，“combo”），然后使用代码就可以

1. var combo=Forguncy.Page.getCell("combo");
   
2. combo.getControl().getSelectedItem().DisplayText;

复制代码

就可以取到了

用代码时可以获取到的，但是就是不满足我们“低代码”的理念不是？ 如果有个公式指接用应该更方便不是
场景是： 有个组合框，用来给用户选择，当选择了后，再页面的另外一个区域，恰好需要把当前选择的这个文本（而不是值） 再次显示出来。 有时页面设计会遇到这样分区域显示同样信息的情况。其实是个很小的功能，再去用js又显得很鸡肋~ js应该去更需要他的地方

那你就在那个地方使用一下ODATA就行啊

Simon.hu 发表于 2019-9-30 13:44
那你就在那个地方使用一下ODATA就行啊

是的。这也是另外一个可以达到目的的方法。
但是对于重度强迫症患者来说，ODATA的使用访问了一次数据库，略微影响了一丁点性能（可能是0.000001%），就总觉得很不舒服。 因为这个文本之前的组合框已经获取过了，那为什么还需要再访问一次数据库呢？

这个不是迫切和紧急的需求（因为胡总都至少提供了两种解决方案），更多的只是多走几步就到了但是就是懒得走的心态下萌生的需求，但是对非代码的使用者来说，这样的功能就是让他能集中和节约0.1%的精力去思考业务逻辑，也就足够了。

by the way， 跑题一下。 是否开发团队有计划考虑加类似excel里自定义公式函数的功能，然后再单元格中可以直接用等号来带出自定义函数？ 当日，我们活字格的自定义函数脚本可以是用js来写。例如对页面的N个数字取最大，一般再另一个单元格直接写公式 = Max(A1:F1) 这样。 如果有个特殊需求，需要取次大值，那么假设写了个js的函数SubMax，
这时候直接再单元格写公式=SubMax(A1:F1) 就好。

这个你想想，即使能能够自定义函数了，你还是要写一个的逻辑的啊，你这个从ID取数值应该怎么做？  我估计大概率还是ODATA

Simon.hu 发表于 2019-9-30 17:50
这个你想想，即使能能够自定义函数了，你还是要写一个的逻辑的啊，你这个从ID取数值应该怎么做？  我估计大 ...

1. OData解决的是和数据库交互方面的需求。自定义函数解决的是相对复杂的逻辑操作的需求。当然，从理论上说，我完全可以用其他隐藏的单元格来过渡，存储中间变量和计算过程（包括ODATA从数据库查询到的结果），但是这样造成的问题就是页面的中间变量和公式较多容易引起混乱，而且不利于复用。基本是一物一用。 而自定义函数正好能弥补这个空间。 不过我觉得你们对自定义函数的支持的主要纠结之处不是在这方面，而可能是在自定义函数的触发时机的问题？因为excel这方面做的也不是很完美。
2. 对于本文提出的问题而言，因为我在使用组合框的时候已经得到过一次值和文本的组合了，再再同一页面再获取一次明显是有些冗余了。而且如果只是涉及到页面的交互问题，再获取一次就很有回到asp.net的服务端权威的感觉了

OK，其实我们之前很久就在规划自定义函数了，但是，总是觉得需求没有那么多；
目前对于自定义函数，我这边只是想到这个这么几个用例：
1.表格中，数字转汉字大写
2.根据某个格子设置的公式，计算相应的结果
3.获取下拉框的显示值；

不知道，老兄您那边还有没有别的需求可以使用这个解决的？ 我一起整理一下
还有这个功能即使做了，很可能第一个版本不支持打印和导出Excel，这个我提前给您说一下哈~

Simon.hu 发表于 2019-10-8 12:12
OK，其实我们之前很久就在规划自定义函数了，但是，总是觉得需求没有那么多；
目前对于自定义函数，我这边 ...

哈，我所理解的自定义函数的使用范畴不一定非是那些固定的场景，因为严格上说，如果是固定的场景，说明使用的人多，那官方或者非官方插件开发者就很可能将其插件化，而不是自定义函数化。
所以更多的应用场景是具体的业务逻辑，因为需要多步跳转/判断/选择，如果公式写在一个单元格公式里面会抓狂，但是分开来又会占用太多的过渡单元格，整个页面都是过渡用的计算单元格显得凌乱，这时候就用上自定义函数。
举个例子，假设再某个页面功能需要有这么一个特定的逻辑，根据 图中1的位置 ，从页面的表格数据中搜索到对应匹配的值（这个可以用VLookup公式，在图中2的位置），然后需要根据得到的这个结果进行判断，如果是A，则显示123，B则显示456，C则显示789.。。  这时候就要再用个过渡单元格，再写个公式if嵌套，如图中3的位置。如果情况很多，这个公式还需要很长，当然如果还需要其他的处理，还需要更多的过渡单元格来搞定。

这时候，在一些情况下，就可以把这个过程写个自定义函数，假设命名为compute(str), 在3的位置就可以写公式 =compute(D4) 就可以了
ps：这时候，就有人会提问了：要想实现这个效果，活字格现有的功能就完全可以做到呀？ 在位置1的文本框的单元格命令里面去编辑具体的命令不就好了。
那个，好吧，的确如此。 但是如果输入的参数 不只是位置1， 而是如下的1，4，5，后续的计算是根据这三个输入值得出的呢？如果用单元格命令，就需要1，4，5三个单元格都要去触发同样的命令（当然，咱们官方最新出的共享命令就是可以解决这个问题了）。但是从结果（位置3）来说，去写个自定义函数公式却是最直观最便捷的一种思路。

其实这个功能更多的是换一种思路思考和解决问题，并不一定是非此不可的功能，仅作参考。