Jeff Bohrer wrote:
Tbob-
I'm a bit uncomfortable with your solution. Putting sub vis in events should be practiced with caution. The event woun't complete until the sub-vi returns and the UI becomes unresponsive. Same with the case structure outside the event but in the while loop. you block the event structure from firing untill the case structure completes. You could dynamically lauch a vi and set wait for completion to False- but it better be a reenterant vi so it does not block itself and cause the same problem (since the invoke node won't return until the vi launches- or it returns an error if it waits too long (Hmmmm what's the time-out? is there one?)
IM(not so)HO, It's much more desireable to disconnect the event and the reaction to the event with a P-C archetecture.
You are assuming that the user wants to keep the event structure running while the subvi runs in the background. The original problem did not state this at all, so I gave a simple solution, which will work fine. I routinely put subvis in event structures because I purposely want the subvi to finish before taking any other action. Usually I am perfoming a test on some device, and I don't want any front panel activity until the test is complete. If I wanted my event structure to keep running, I would launch the vi dynamically and set the Wait Until Done property to false.
As for the "case structure outside the even but in a while loop", I don't have this in my solution at all. You must be making a general statement. So it really depends on the user's intentions whether to keep the UI open to activity while subvi's are running, or to not allow such activity until the subvi completes.
