关于“比较判断，数值比较”构件，这两天一直在想更好的实现方法，经过与一个搞开发的朋友反复的测试交流想出了很多种方案，从中选了一个方法，既符合《搭建》思想，又能简化实现方式，阅读性更强些，思路更明了一些：

其它开发工具，是用 if then enif 或易**中是： 如果（条件值）这样的实现方式

实际上，这个流程控制的语句，结果只有两个，即：为真事件；为假事件

所以，在搭建中可以这样来实现，我们暂把这个构件取名：“条件比较”

1、需要增加逻辑比较运算：等于，大于，小于，大于等于，小于等于，并且，或者，不等于，近似等于

2、“条件比较”事件：为真/为假 /////这里只在两个事件就够用了。

我们还是以0=<X<10为例可以这样实现(大概简单写一下思想)：

参数>自定义.数字:"X"

参数>自定义.数字:"0"

参数>运算.大于等于

参数>自定义.数字:"X"

参数>自定义.数字:"10"

参数>运算.大于

参数>运算.并且

执行>条件比较

{为真}-----------------为真时的事件

{为假}------------------为假时的事件

---------------------------------------------------

上面这种方式应该是比较简单的，思路比较清淅，事件比较简单，当情况复杂时，事件设置为更加清淅明了，可以应对各种各样的判断。如果做一个这样的构件，完全可以代替现在的“比较判断”“数值比较”两个构件。

希望李老师能重点考虑一下这个。很期待。

你这个并不简单，大家可以讨论（一定要认真思考后，再说）；

现在的“数值比较”构件的一个问题是：“在两值之间”事件的触发中包含了两“值”；目前我们考虑增加一个“开关属性”，来进行选择，以满足不同情况的需要。

原来这么设置，是基于一个“使用概率”的结果。

不太知道你说的“并不简单”是什么意思，

但我上面写的方式思路会很清楚，事件也简单只有两个就可以：

增加了阅读性，通过这么长时间对搭建的使用，发现了一个这样的事情，当开发时容易，思路也非常清淅------我这里单指“这种流程控制----比较判断，数值比较这样的构件”，但是当隔了有段时间后，对软件的升级，或功能的增加或功能的调整，查起来特别费劲，思路很难顺清，特别是嵌套了多个比较判断时或有数值比较时，或者更准确的说，当出现三个比较判断或数值比较时，现在的方式就显得有点力不从心了，而这两个构件是开发过程中使用非常频繁的构件。

比较判断和数值比较：因为现在有多个事件，对于比较判断有：相同，不同，大于，小于；对于数值比较有：等于A，等于B，大于B，小于A，两者之间。当找命令时要打开一个关闭一个，再打开再关闭等等，才能把所有的思路顺一次，里面还涉及是或者关系，还是并且关系，所以感觉很吃力。

“并不简单”就是“复杂”的意思。

你的这个设计，不符合“构件”理论，“大于、小于”等，这些是“结果”, 应属于触发事件的范围。

《搭建》的事件处理内容“并不等同于代码”；《搭建》肯定要按”搭建“路子走，否则就不统一了。

我不是想改变搭建路子，这一点是肯定的，而且我也没有改变搭建的路子，//“大于、小于”等，这些是“结果”, 应属于触发事件的范围//，另外，“相加”“相减”“取模”这些都是结果啊，他们应该都属于“运算”，范畴的，不同的是：“相加”“相减”“取模”是数学运算，而“大于、小于”等属于“逻辑关系运算”，怎么能是触发事件的范围，

实际上搭建不就是用结果来处理结果的吗？

如：

参数>自定义.字符:"搭建"-------结果或叫反回值:搭建

------------------

执行>列表框.得到当前项内容-----返回"列表框当前内容"

--------------

参数>自定义.数字:"100"-------返回“100”

参数>自定义.数字:"200"-------返回“200”

参数>运算.相加-----------返回"300"

-------------------------------------------

为什么搭建在查错的时候会容易呢,优势就在这里，每执行一个命令都会有一个结果，以结果处理结果，用结果参与命令执行，而传统的编程方式不具备这样的优势。

我提到的处理方式，并不违背这个道理啊。。。。。

“大于、小于”等，这些是“结果”, 应属于触发事件的范围

这句话，我明白是什么意思，现在搭建是把这个当做“触发事件”来处理的，

实际上：

参数>自定义.数字:"X"

参数>自定义.数字:"10"

参数>运算.大于------搭建里是把这里作为事件处理，而我这里是把他作为运算处理，而我这里不管是什么事件都会出现在{为真}{为假}

执行>条件比较

{为真}-----------------为真时的事件

{为假}------------------为假时的事件

上面实际和搭建的思想并不违背，只是处理方式上有出入。

在上面的例子中，搭建中是执行的{大于事件}或{小于事件}，而我这里是{为真}还是{为假}，这样不管出现什么结果，最终结果只有两个即：{为真}还是{为假}。就不会为有那么多的事件而出现差错或其它问题了。另外出现多联式的假设（比较）嵌套时，也只是在：{为真}还是{为假}中进行。

楼主的这段话倒是实情（也就是上面引用的这段话）。遇到时间久了，想要查清自己编写的程序流程，实在是很有些头晕！有时还不及重新设计制作来得快！

但是，要用楼主的方法也未必能实现。

嗯，现在遇到时间久了，想要查清自己编写的程序流程，实在是很有些头晕！有时还不及重新设计制作来得快！----这个问题确实让人头疼。

确实我说的这种方式只是在一定程度简化增强了“比较的功能”

要想解决“查清自己编写的程序流程”这个问题，还需要把流程控制的构件里面的事件放到一起才行，而不是像现在遇到分支事件就要分开来写，这样的构件有：比较判断，数值比较，条件选择，计数循环，记录循环，对话框等构件。

--------------

这个问题按现在的状况来看，只能等，不敢奢望啊！

要想解决程序语句流程的可读性，我认为也并不一定就是奢望。

现在是可以从“调试”和“打印”这两个功能输出流程语句，但是输出的还是按照构件放置的先后顺序来输出的。

建议——是否可以从“调试”功能着手来解决呢——增加一个功能选项：调试运行时，后台按照程序运行流程输出命令语句至一个特殊的文本文件——这样，不管是在修改、升级中还是在申请软件备案注册时都是能让人读懂接受的。

希望公司能从这个思路想想办法哦！