In anticipation of the upcoming meeting, here's the code I will be discussing.
It's a config dialog where you specify an array of VIs to use as configuration categories modeled after the LabVIEW configuration dialog. Each VI runs asynchronously and is hosted in the main window's subpanel when you click on the category name corresponding to the VI. The code can be run by executing Config\Example.vi in the supplied zip file.
The pattern I used here is one I have moved to in recent years: object encapsulation with a high level non-object oriented interface. This allows a high level single VI interface which can be used by anyone even if they don't know object oriented design, the Show.vi is an example of this. It wraps the more advanced object oriented interface. For this simple example, the Config.lvclass doesn't expose anything the higher level Show.vi method doesn't already handle, but imagine enough advanced configurability being added to the class to the point where the connector pane on Show.vi would become overwhelming, never mind the possibility of inheritance.
Getting back to the topic at hand, there are a few subtleties here which demonstrate how I often work with subpanels: Generally speaking I rarely have the host insert a running VI into a subpanel, rather I pass the subpanel refnum into a running process and allow it to take appropriate action. One reason I do this is to allow the hosted panel time to initialize. Rather than inserting a VI which may not be ready to be shown and having the screen flicker as things are updated, the hosted VI can do what it needs to do behind the scenes, and show itself only when its ready. Another reason is when considering more complex architectures the host may not have any idea of what needs inserting into the subpanel. By passing the subpanel refnum to the other task, the decision about when and what to dump into the subpanel can be delegated to a context which likely has more relevant data to make the decision.
Another caveat about asynchronous tasks that comes into play is event registration and race conditions. Generally speaking I'm skeptical of blindly adhering to the adage of registering for events on the same diagram that uses the registration. If I pass a user event to a task and I'm going to control that task via that user event, I need to make sure that the task has registered the event before I send any data through the event. If I leave registering the event as the responsibility of the task I'm spawning, I then need another layer of hand shaking so I can be sure the registration is complete before I send any data through the event. I generally find it much cleaner to instead perform registration of mission critical user events in the host that spawns the task. This pattern can be seen in Start Categories.vi, which pre-registers a pair of events for each category VI it spawns (the events used to tell the VI to exit and to insert itself into a subpanel).
Finally note I'm using the call and collect option for running the asynchronous VIs. Even though the category VIs in this example don't return anything I'm still interested in waiting for them to return such that I can be sure they've recorded any changes before the hosting VI moves on. It's also conceivable that the example could be re-worked such that the individual category VIs return data by value, but this detail is really something that's application specific.
