0

I've started to look at using Omnithread to improve my Delphi Application using multithreading. Creating one or more worker tasks are well covered by the documentation so that long actions that I invoke from button clicks can be replaced by this demo code (Async, CreateTask etc). Where I am having difficulty though is in how to replace my most 'messy' code which operates as follows.

I have a concept of a single class instance that corresponds to a hardware module. The class publishes one or more properties that expose current values and settings for the hardware. Properties might be read only or read / write. For each of these class instances there can be from zero to several display forms visible. A display form has a TTimer and a built list of the aformentioned published properties. This list is iterated to match up suitably named controls such as labels or edit controls and an RTTI mechanism is used to get and set values between the control and its property. The result is a form which provides a nice UI on to the actual hardware module with the side effect than multiple forms can be open, modifying data on one of them causes the others to show that data shortly after. This property monitoring is performed by the TTimer ticking at 300 ms intervals. Each tick causes it to scan through all properties of the class and to refresh the matching control on its form. The timer runs for the lifetime of the open form. Forms are created when needed and then freed (this has the useful performance optimisation that with no forms open to inspect the hardware, the Application must run as fast as possible because no monitoring tasks can be running).

Is there a better way of using threading to access my published properties, rather than using a TTimer in the UI thread? Or would synchronisation issues outweigh any advantages? If threading is useful, how would one create a repeating task such as to emulate the ticking timer?

Leonardo Herrera
  • 8,388
  • 5
  • 36
  • 66
Brian Frost
  • 13,334
  • 11
  • 80
  • 154
  • I think this would benefit from being two separate questions: Is threading a good idea when polling UI properties? How do I run tasks periodically with OmniThreadLibrary? [The latter has been asked before](http://stackoverflow.com/q/8412254/33732), although not specifically limited to OmniThreadLibrary. – Rob Kennedy Sep 06 '12 at 16:44
  • What specific problem do you need to solve? What performance constraints does your current version fail to meet? – David Heffernan Sep 06 '12 at 17:55
  • I saw rather interesting idea of UI polling, both for reading and setting values. There was a TAction assigned on Form and it had OnIdle handler set. And i can not say it was CPU hogger nor lagging. – Arioch 'The Sep 07 '12 at 06:21
  • 1
    Did you tried OTL forum ? OTL author frequently answers there questions and gives advices on program structure. – Arioch 'The Sep 07 '12 at 06:22
  • @David. I am having continual problems with re-entrancy due to the need to call Application.ProcessMessages elsewhere to get the timers to fire. – Brian Frost Sep 07 '12 at 19:49
  • @BrianFrost Yes, ProcessMessages is evil. I guess you want worker threads which can send messages of some sort to UI thread when updates are needed. – David Heffernan Sep 07 '12 at 19:51
  • The thing that makes me wonder, why people start on SO, instead starting on official forums and only going to SO if official forum fails ? People on forums are much more knowledgeable of those certain libraries, aren't them ? – Arioch 'The Sep 07 '12 at 20:02
  • 1
    First, get rid of the A.P calls! Move all long-running, message-handling-stopping code out of the UI. For your property changes, if the frequency is high, (high enough so that human users cannot keep up anyway), use a TTimer poll. If the frequency is low, use PostMessage(), (or some Omnithread wrapper of PM). – Martin James Sep 08 '12 at 08:38

0 Answers0