The most elegant way to open a modal dialog from an event loop

[Ian2]

A good point. Very straightfoward if the dialog/vi doesn't need to do anything except allow some data entry. My only reservation is that its always running through the dialog vi, even if it isn't displayed, not that its doing much.

[Randy Riggs]

I think the resources required to run through a vi with an empty case statement turn out to be pretty much a non-issue in most cases. Besides, if the alternative is to have another loop running, which would be most wasteful?

You'd be suprised what you can get with this scheme, I certainly don't limit it to only simple data entry. That said, one simple yet effective use is to post user messages that you don't want to block the rest of your program.

Randy

[DFGray]

Your modification, Shin_MainVI4.vi, is a common pattern but is usually only appropriate for simple applications. I tell people to avoid it because it combines the task handler and event handler into the same object. This usually results in harder to maintain code because a lot of tasks get duplicated in different events. For example, how do you close the application? In Windows, you can hit the X on the upper right of the window (System Close), select the file menu item File->Exit, or hit the key sequence Alt-F4. All of these cause the same action - Exit - but all have different events in the event structure. If your exit sequence is at all complicated, like most data acquisition systems, you really don't want to duplicate it. A good alternative is to never have more than one VI in any event - the "task handler" is a single VI for every task. This achieves the same purpose, although I shy away from this solution as too easy break ("fix" a problem by adding code in one event, not the subVI, and forget the other events).

That said, this is almost a religious argument (did you see the foam escaping the corners of my mouth?). You should use what makes sense for your application and what is easy for you to maintain. Good luck.

[Ian2]

I beg to differ (this could be interesting): I agree that if each UI event were handled directly by an event loop case, then duplicated code would be the result (the exit example being a good case in point). However what I have done with the modification is to replace the functions handled by the original queue with a single user-defined event, using an enum to select the required function. This has effectively swapped the outer case statement and event loop around. I have retained the separation of task handling and event handling, its just that task handling is now dealt with by the user-defined event (or events). Using your example of file exit etc, each of these UI events would have its own event case, which in turn generate a user-defined cleanup event. This is handled in one place in the case statement.

Surely this is essentially the same as the queued version - it just uses a different mechanism to implement the task handling?

[DFGray]

You are correct. I missed the true meaning of that user defined event, and I like the pattern. You described the difference between the two approaches very well. I think I still prefer the queue based approach, though, because it allows you to have several independent task handlers in the same VI (LabVIEW recommends no more than one event structure per VI). I admit this is not a common use case, but I do a lot of large scale UI/data acquisition work. However, both approaches allow you to put multiple task handlers in other VIs, which is how you should probably handle multiple task handlers anyway.

Thanks for keeping me honest!

[DFGray]

Your approach is simple, and works, but I have problems with it.

1. If you are looping doing DAQ and your DAQ hangs, your UI is also locked since it is in the same loop. The inverse is also true - if your UI hangs, so does your DAQ. As such, this pattern is not suitable for an application you plan to distribute or sell. It is not robust.


2. An event structure in a loop controlling your UI consumes no CPU time until the user actually interacts with the program. You are correct that running through a no-op VI consumes negligible resources, but it will still be more than an event loop.

Your pattern is great for simple VIs used in-house and developed by one person. You could easily get into trouble if someone else touches the VI and doesn't understand that the UI and DAQ must not hang. The DAQ loop - UI event structure loop pattern avoids this particular problem.