第十三个需求 测试代码运行时间
有些测试，不仅需要判断是否可行，还需要判断运行效率如何。
测试前保存一下当前时间，测试后再保存一下测试后的时间，然后输出两个时间的差，就可以看到程序运行时间。增加的代码量不多，但是判断运行效率一般要比较多个方案，每个方案都添加这些代码，总量就多了。
这种三明治代码可以通过函数类型的参数，改变中间的代码。通用测试时间的部分写成一个函数放到根窗体中，把需要测试的代码写到一个函数中，然后把这个函数作为参数，传递给那个通用的函数。
测试程序把测试代码放到了Action中，所以把Action作为参数传递给那个通用的函数更加方便。
一般判断运行效率，都需要运行很多次，取平均值，所以通用的函数可以增加一个参数，表示运行多少次。
最终，只要把每种方案的测试代码写到对应的Action中，然后再写一个Action，用那个通用的函数去执行前面那些Action，就可以完成效率测试。
避免了重复输入代码，也避免了重复点击鼠标。
第十四个需求 探索新组件
有时需要测试新的组件，最直接的办法，放置组件，设置属性；再增加一些Action，调用组件的功能；然后运行，看组件的运行状况。
有的组件很复杂，需要设置很多属性，并且要考察不同属性之间的配合。这时候需要重复设置属性并运行，效率比较低。如果能在运行时设置属性，直接看到组件的变化，省去了编译运行工作，效率会提高不少。
实际上，窗体设计器就是运行时设置属性。能够在窗体设计器中使用的组件，都需要先安装，安装的组件成为Ide程序的一部分，才可以在窗体设计器中设置属性。
网上搜索了一下，已经有不少人做了很多工作，甚至写了组件，类似Ide的属性编辑器，可以设置关联的组件。
把这个组件放置在新窗体中，然后在根窗体中增加一个Action，显示这个新窗体，并将子窗体中的组件与这个组件关联，就可以在运行时设置属性，同时看到设置结果。
很好！
第十五个需求 不同版本IDE共用工程
在不同版本的Ide中，相同的代码不一定能够运行。还有时候虽然能够运行，但是结果不同。切换到新版本的Ide中，可以通过修改代码适应新版本，但是再切换到原来的Ide时，还需要把代码改回来，浪费了时间。
为每个版本的Ide创建一套独立的源代码，是一种可行方案。但这种方案需要在修改代码的时候，每个版本都修改一遍，很多工作是重复的。
条件编译
仅创建一套源代码，通过条件编译，适应不同版本的Ide，是一种更好的方案。仅适用于特定版本的代码，用条件编译包括起来，就不会影响其他版本Ide的编译。
Ide版本（实际是编译器的版本）信息不容易记忆，需要重新定义成容易记忆的符号，这个工作可以放在一个独立的Inc文件中，哪个单元需要使用版本信息，就插入这个inc文件。很多第三方组件，都包含一个类似的文件，可以直接拿来用。例如rxlib中的Rx.inc，jcl中的jedi.inc。
也可以为不同Ide版本创建一个工程，所有工程都共用单元文件，在不同版本的工程设置里设置一个特殊的符号，用这个特殊符号触发条件编译。这种方法更适合创建不同目的的可执行程序，或者创建组件。
Delphi5窗体处理工具
条件编译仅适用于单元文件，不适用于窗体文件。一般来说窗体文件可以通用，除非其中包括中文等非Ascii字符。Delphi5是一个分水岭，Delphi5以上使用另一种格式。
高版本的窗体文件需要转换一下非Ascii字符的编码，Delphi5才能打开。CnWinzard有一个功能可以转换，但一次只能转换一个，测试程序的窗体有很多，而且都含有中文（Action的标题），有点麻烦。
做一个命令行工具，可以批量转换，然后放到path路径中，转换版本时，在TotalCommander中按Ctrl+G，调出CMD终端窗口，键入这个程序名并回车，一次完成所有窗体的转换。
方便多了。