Does the Event Structure force use of the User Interface thread?

[LabVU_Dog]

Hello All,

I've used queue-driven state machines in LabVIEW successfully for decades, part of the beauty being that I can assign them to a non-UI Execution System and then there's no interference. Recently I needed to troubleshoot a Windows executable, so modified a QDSM subVI (configured for DAQ execution system) to "Show front panel when loaded". Then I added various indicators as front panel probes so I could gain insight into the execution. Before long I had modified the subVI to include an Event Structure to capture the "Window close" button and also a couple of other FP button inputs.

After the troubleshooting was done I liked the "improvement", and since unit and release testing still passed, the possible consequences eluded me at first. The handling of those events are typically (always?) handled in the UI thread. Did I just completely undo my effort to run this code in thread(s) parallel to the UI? How can I find exactly how far I can go with an Event Structure before it forces execution in the UI thread? Does the existence of ES force the UI thread? What if I just have a single event, the Timeout? What about just "Panel Close?"?

Thanks for any help!

[avogadro5]

My way of testing this is to make a VI that just does the operation you wonder about the UI thread, and run the VI then open the menu bar to see if that blocks the operation. Based on this test I think an event structure with just a timeout does not use the UI thread, because it can execute while a menu is open. This approach may be flawed so curious if there are better ways.

[tst]

---

@avogadro5 wrote:

My way of testing this is to make a VI that just does the operation you wonder about the UI thread, and run the VI then open the menu bar to see if that blocks the operation.

---

I believe the menu only affects the root loop, which is a more specific component than the UI thread. What you can do for testing is create a small VI, compile it as a DLL function and then call that function in the UI thread:

         

The setup here is simple:

1. The top loop updates the indicator using the terminal, the value property or a local (in the case which has an event structure with a timeout case).
2. The bottom loop updates its indicator and calls the DLL function, which just waits for N ms and then returns.

What you can see from the recording is that having the event structure doesn't require the UI thread, presumably because it's just looking at its own queue. Calling the property node does, because that always executes in the UI thread.

I added the Panel Close? event, since it was mentioned, and actually pressing the close button does cause the top loop to freeze until the DLL call completes. The same is true for a value change event for a control on the front panel.

Edit: I forgot to show this in the recording, but opening the menu does not prevent the indicators from updating, including in the property node mode. However, once you lock the UI thread, you can't actually open the menu (presumably, like closing the window, it's an interaction which goes through the UI thread).

Edit 2: I'm attaching the code. I didn't include the DLL, so LV will probably complain when you load the project. You can use the build spec to build the DLL so that it matches the RTE of your LV version.