VisionPlus_V3.0/VisionPlus/Docs/Thinking.txt

【Thinking】

1. 关于并行工具的设计【需要提前创建线程，而不是在运行过程中临时创建线程】
   （1）将并行工具与Pou中其他工具，以及加入并行工具集的子工具都视为平级处理；
   （2）这样在绑定的场景中，直接跳过并行类型的工具即可；
   （3）在link的场景中，其他工具和并行子工具之间由于是平级关系，link不会被影响到，让goto连接到并行容器的Top接口即可；
   （4）加入并行工具集的子工具，由于是平级关系，所以要保留原始序号，Pou执行时同样还是按照序号来执行，
   如果执行到子工具则跳过，执行到并行工具则将其下所有子工具并行启动；
   （5）将并行母线设计为并行工具的输出Top接口，这样就可以从输出接口连接线出去连接别的Tool了

2. 关于并行母线的缩放策略【已完成】
   （1）并行母线的缩放的核心代码是写在了 WindowAppItemInterface::updateParallelPosition() 函数中；
   （2）因为并行母线本质上是Parallel功能块的一个输出接口（Top类型，用于下联功能块），只是采用了不同于普通接口的特殊绘制方式
        就类似于Goto功能块的输出接口（是一个三角形）类型
   （3）并行母线的缩放机制就是遍历其下联的所有link连线，选出其中最左侧和最右侧的连线，如果两者的位置
        超出了并行母线的左右两侧的最小位置，则将并行母线按照这两个参照位置进行调整大小，需要左右各延长出 PARARREL_LINE_EX_LEN 个长度

3. 关于接口的同步机制【已完成】
  （1）普通工具的接口同步：是在工具Execute的时候进行批量同步的，不需要在dll的代码中增加任何操作，
       在 POU::ToolPostExecute()函数中，会自动识别被连接的工具接口，自动加入到同步通知列表中，
	   然后通过 POU::syncValuesToUi() 函数向UIManager发送消息，完成到UI界面的同步

  （2）硬件工具的接口同步：由于硬件工具没有Execute的动作，所以接口需要更新的话，需要单独发送变量消息通知
      在硬件工具的dll中，调用 syncHdValueToUi() 函数即可方便的完成硬件工具dll接口向exe中的UI的同步
	  （本质上是通过发送 SyncHdValueEvent 消息到UiManager中统一进行处理，HDVALUE_EVENT_TYPEID类型 ）

4. 关于硬件组态配置与项目工程文件的结合【已完成】
（1）初次创建硬件组态的时候，自动生成一个硬件组态的方案ID，此ID 可通过用户手动修改
（2）使用一个全局变量，来存储这个ID
（2）在保存工程文件的时候，需要将硬件组态的文件打包进去（加入压缩包）
（3）软件每次打开会自动加载 default.hw，加载的硬件组态，会读取到方案ID，来标识当前这个硬件组态方案
（4）在软件加载工程文件的时候，需要首先检测当前方案依赖的硬件组态ID，如果匹配，则继续后续的加载
（5）如果检测到当前工程文件与依赖的硬件组态不匹配（ID对比失败），则提示，让用户选择是释放工程里备份的硬件组态（覆盖 default.hw）重新加载，还是退出加载当前工程
（6）用户在备份工程文件（*.vpp）时候，vpp中自动包含了硬件组态的（*.hw）,省去了让用户自己匹配的麻烦
（7）硬件组态与vpp分离的初衷。（硬件加载慢，在有频繁的工程文件切换场景下，可提高工程文件加载速度。避免硬件加载导致的意想不到的结果）

5. 关于Link连线的拖动以及其他线段的联动【已完成】
（1） 这里用了比较巧妙的简化方法，对于普通link连线，所有都是固定的5段线，从link起点开始编号0 1 2 3 4
（2） 其中0号和4号线段由于分别连接了功能块的输入与输出接口，所以是不允许拖动的；
（3） 而1和3号线段又只能左右拖动，2号线段只能上下拖动，这样就大幅简化了算法了设计；
（4） 并且在线段生成的时候，让每一个线段都保持固定的方向，例如从左到右，从上到下等；
（5） 所以只需要根据具体的拖动线段编号，把相邻的两个的坐标设置一下即可。

6. 关于功能块拖动时，Link线段的联动【已完成】
（1）此处参考的是visio中的效果，如果是起点功能块拖动，那么只调整0号线和1号线；
（2）如果是终点功能块拖动，那么只调整4号线和3号线；
（3）如果起点功能块拖动时，0号线小于了最小长度，那么所有线条重置；
（4）如果终点功能块拖动时，4号线小于了最小长度，那么所有线条重置

7. 关于Task等待变量变化时的触发执行机制【已完成】
（1）首先为Interface类型（也就是VARIABLE类型）添加一个用于执行触发动作的ToolEvent结构；
（2）在创建DB类型变量时，增加是否触发的选项，如果选择了需要触发，则默认为此变量初始化一个ToolEvent；
（3）然后在创建Task的界面，可以选择此DB类型的ToolEvent作为Task的触发事件，建立绑定关系；
（4）然后在表格中的变量数值变化时，会自动调用 GvlManager::updateValue() 进行变量数值的更新
     在数值更新的同时向TaskManager发送此ToolEvent，触发到对应的Task进行执行

8. 关于Tool等待变量变化时的触发执行机制【已完成】
（1）首先专门创建一个内置的Wait工具，专用用于等待变量触发；
（2）为TOOL数据结构增加 QWaitCondition（ToolActivator）结构，用于Wait工具或者其他工具等待变量触发使用
（3）然后还是以TaskManager为统一的变量触发Event接收处，在CustomEvent()中统一进行处理
（4）每一个Wait工具选定了需要绑定的变量Event之后，都需要把 Event-Tool 的触发对应关系，到TaskManager中注册一下
（5）然后TaskManager收到了变量触发的Event之后，首先到Task列表中去查是否有对应的Task需要激活，然后再继续到Tool
     列表中查是否有对应的Tool需要激活，如果有的话则激活这个Tool，使得Wait工具继续执行
（6）在系统退出的时候，需要把所有处于等待状态的Task和Tool都激活一遍，然后再停止执行，防止卡住

9. 关于UI控件的等宽线绘制机制【已完成】
（1）首先等宽线只有在控件拖动尺寸的时候才会出现，而移动控件的过程中不会出现，所以需要在控件拖动的时候进行判断；
（2）需要注意的是，除了被拖动的主控件之外，其他参考控件的等宽线只会固定出现在右侧和下侧；
（3）而主控件的等宽线是根据拖动位置的不同，需要绘制到不同位置的，优先会出现在右侧和下侧，但是右侧和下侧如果正处于
     拖动变动的过程中，会改到左侧和上侧出现；
（4）设计 WindowAppIsometricLineManager 类来统一管理所有的等宽线，在UiScene收到控件被拖动的消息时，WindowAppIsometricLineManager
     就会启动检查所有的控件是否有宽度相同的控件需要绘制等宽线，而在鼠标抬起时，无论当前处于什么情况，都需要清空所有
     等宽线；
（5）WindowAppItemIsometricLine 类是用来完成单条等宽线数据结构的存储与线条显示；
（6）等宽线的判断逻辑：比较主控件和其他参考控件的右侧和下侧长度，如果有相同的，则绘制对应不同的线条，参考控件直接在右侧或者下侧绘制，
     主控件需要根据拖动的位置计算对应的等宽线绘制位置。