Add an event that would fire when a spawned subVI exits

[Mark_Yedinak]

When designing large applications it is normal that the top level VI will spawn background tasks to perform specific tasks. It would be nice if the top level VI could receive an event when the subVI exits. I realize this is possible if you specifically add code to the subVI to post a message to a queue or fire off a user defined event. However, it would be nice if the event were available without the need to add code to the subVI. This would make it easier to design top level applications that could spawn tasks and not palce any additional coding requiements on the subVI. The "Panel Close" event can be used with callback however it will only trigger when the subVI exits via the Window Close button (X in the upper right corner). This is too restrictive and will not allow the top level VI o be informed the subtask exited programmically.

[JackDunaway]

The sister Idea can be found here: Dynamically Launched VI. In the comments section, Jarrod mentions a similar notion of a callback to properly handle outputs of an asynchronous child process.

Perhaps this Idea could be implemented with a new type of "VI Output Queue Ref" that can be wired from the CBR Node into a Dynamic Event Registration node? This would provide a clean interface to the output data as Event Data nodes in an Event Handler case. Scalability for multiple child processes would feel natural since Event Registration nodes already accept arrays of refs.

Historically, only a fraction of the time I use the output of a dynamically-launched process - most instances are "fire and forget". Even though an Output Queue can be constructed with the tools we have today, I'm giving this Idea Kudos because this pair of Ideas could significantly reduce maintenance and up-front development for asynchronous frameworks.

[tst]

So what you want is effectively something like this?

This would be fired every time the VI stops running, even if it doesn't actually go out of memory. You might need some additional events, such as VI start run, VI unload, or the execution change event suggested here, which rolls them into one.