binary switch changes state only after commits

[ElectroLund]

I have a single binary switch controlling four similar processes.  I'm using an EVENT_COMMIT to trap the change of its state.

However, I'm noticing that due to hardware lag on the output side, the state of the binary switch (from OFF to ON) takes a long while to change.  In fact, visually LabWindows is not updating the GUI state of the control until after all the stuff happens in its callback.

That seems odd behavior to me.  The Help topic for the control states:

If the control mode of the binary switch is hot or validate, a commit event is generated when the binary switch is active and you change its state.

Doesn't that imply that the GUI would drive the control in some other thread while the callback is processed?

I also tried EVENT_VAL_CHANGED, but that behaved the same way.  Is there some other event type or mode of operation that I could try so that when the binary is changed, the GUI gets updated immediately and the callback is processed concurrently?  I don't want there to be so much lag that my user tries to hit the binary a second time!

[RobertoBozzolo · Accepted solution]

---

ElectroLund ha scritto:

Doesn't that imply that the GUI would drive the control in some other thread while the callback is processed?

---

No: the visual representation of the control is updated at callback end so if the callback takes long to execute you won't see the switch changing state until processing terminates.

You may inform the user that something is going on by using SetWatCursor (1) at callback start and SetWaitCursor (0) at callback end, or force an update of the GUI calling ProcessDrawEvents () somewhere in your code (but if there are several GUI updates pending the time spent can slow down callback in an undesirable moment.

[ElectroLund]

SetWaitCursor is a very nice little solution.  Just enough visual feedback for my user.  Thanks!