Any way to show a subvi's frontpanel within its parent with out the cumbersome "subpanel"?

[id]

Shane...I like that idea of embedding the insert vi method within the actual subVI instead of the parent VI with a subpanel by passing the subpanel reference into the subVI. I have to load several user selectable SubVI Panels one at a time as the user clicks on a button.  If you have to stop the subVI to free up the subpanel window and keep from increasing memory when you need to load a new VI, how do you entertain accomplishing this?  Do you have a way of stopping the existing subVI from the Parent VI ?  Any ideas on this would be appreciated..Thanks 

[Intaris]

You don't actually need to stop a VI to remove it from a subpanel.  The subpanel has a "Remove VI" functionality which also works with a running VI.

I generally use events to communicate between by asynchronous processes and I incorporate an "unload" event between parent and child VI to allow for controlling exactly this behaviour.

There is no memory leak (that I know of) because only a single VI can ever be visible in the subpanel.  Putting a new VI in there is only possible after you have removed the old VI.

Note that you can swap out VIs being shown in the subpanel WITHOUT stopping the VIs themselves.

Shane

[id]

After digging further and talking with a few folks at NI, they recommend stopping the VI by using the SetControl method executed by the parent VI for a "stop" button in the SubVI.  A typical example would be to have an event handler in the subVI and the "stop" button on the while loop would be remotely executed form the parent VI....I personally have to do this because my datasets being handled by the SubVIs are quite large and cumbersome in terms of their memory and what it can do to the speed of execution of the program.

[cober]

---

@id wrote:

After digging further and talking with a few folks at NI, they recommend stopping the VI by using the SetControl method executed by the parent VI for a "stop" button in the SubVI.  A typical example would be to have an event handler in the subVI and the "stop" button on the while loop would be remotely executed form the parent VI.

---

How would you get the reference of a control in the subVI to the parent VI? (I can imagine the other way round)

I'm using a separate queue for each of the subVIs. Often they are needed anyway for other communication, but in some cases the only use of the queue is only to receive a "stop". Even SubVIs that run on their own pace (i. e. not waiting for commands by queue) check their queue (with a timeout of 0 ms so they are not blocked) every iteration.

The only thing that's a little bit messy: because some subVIs can get commands with different parameters, I made all queues use the same element, a cluster containing a "action"-enum and a "parameter"-variant. I don't really like all the "to variant" and "from variant" casting I have to do for this, but on the other hand I can e. g. use the same simple subVI for all of queues, to check if a stop-"action" was sent.

[Intaris]

---

@id wrote:

After digging further and talking with a few folks at NI, they recommend stopping the VI by using the SetControl method executed by the parent VI for a "stop" button in the SubVI.  A typical example would be to have an event handler in the subVI and the "stop" button on the while loop would be remotely executed form the parent VI....I personally have to do this because my datasets being handled by the SubVIs are quite large and cumbersome in terms of their memory and what it can do to the speed of execution of the program.

---

I don't know who recommended that to you but it's certainly not how I would do it.

[crossrulz]

A user event would be so much better.

[id]

I agree with you on the UserEvent strategy.  It will make coding much more universal and non SubVI specific.  Thanks

[mikeporter]

Something to remember is that at times the "folks at NI" will give not the ultimate, best answer, but rather the one that is easiest for them to explain to you.

Put simply there is a (perfectly valid) tendency for people answering questions to "scale" their answers based on the perceived skill and understanding of the person asking the question. You will notice that as you become more knowledgeable the answers you get from NI and here will be more complex, or advanced.

The more you know, the more you can hear. 

Mike...