如何最好地使用Omnithread转换多个Delphi TTimer后台扫描任务

我已经开始考虑使用Omnithread来改进使用多线程的Delphi应用程序。文档中很好地介绍了创建一个或多个辅助任务，因此我通过单击按钮调用的长操作可以被此演示代码（异步、CreateTask等）所替代。但我遇到的困难是如何替换我最“混乱”的代码，其操作如下

我有一个与硬件模块相对应的单类实例的概念。该类发布一个或多个属性，这些属性公开硬件的当前值和设置。属性可以是只读或读/写。对于这些类实例中的每一个，都可以看到从零到多个显示形式。显示表单有一个TTimer和一个上述已发布属性的构建列表。迭代此列表以匹配适当命名的控件，如标签或编辑控件，并使用RTTI机制获取和设置控件及其属性之间的值。结果是一个表单，它为实际硬件模块提供了一个良好的UI，其副作用是多个表单无法打开，修改其中一个表单上的数据会导致其他表单不久后显示该数据。该特性监控由TTimer以300毫秒的间隔滴答声执行。每个勾号都会使它扫描类的所有属性，并刷新其窗体上的匹配控件。计时器在打开窗体的生命周期内运行。表单在需要时创建，然后释放（这有一个有用的性能优化，在没有打开表单检查硬件的情况下，应用程序必须尽可能快地运行，因为无法运行任何监视任务）

---

有没有更好的方法使用线程来访问我发布的属性，而不是在UI线程中使用TTimer？或者同步问题是否会超过任何优势？如果线程是有用的，那么如何创建一个重复任务，例如模拟滴答计时器？

我认为这将受益于两个独立的问题：在轮询UI属性时线程是一个好主意吗？如何使用OmniThreadLibrary定期运行任务，虽然不限于OmniThreadLibrary，但您需要解决哪些具体问题？您当前的版本没有满足哪些性能约束？我看到了一个非常有趣的UI轮询思想，用于读取和设置值。表单上分配了一个战术，并设置了OnIdle处理程序。我不能说这是一个占用CPU或滞后的问题。你试过OTL论坛吗？OTL的作者经常回答这些问题，并就程序结构给出建议。首先，摆脱A.P呼叫！将所有长时间运行的消息处理停止代码移出UI。对于您的属性更改，如果频率很高（足够高以至于人类用户无法跟上），请使用TTimer轮询。如果频率较低，请使用PostMessage（），（或PM的一些全线程包装器）。