Add subpanel property: VI Ref

[soupy]

Currently, you cannot get the ref of a VI contained in a subpanel. When removing a VI from a subpanel, the VI ref is not returned either. Having access to this ref would be useful so you can access the VI and stop it after you remove it.

The solution would be to add a "VI Ref" property node (read only), and/or return the VI Ref when using the "Remove VI" method.

or

This forum article describes the issue in more detail: http://forums.ni.com/t5/LabVIEW/Given-a-VI-can-I-determine/m-p/790441?requireLogin=False

[AristosQueue (NI)]

> Do you know of any underlying reasons this was left out?

There's no technical reason it couldn't be done. Our APIs tend to be designed by "add each function when we can identify a need for it" rather than "add all functions we can think of in case there's a need for them." The upside is this tends to lead to simpler, more easily understandable APIs that require less development time and are easier to test. The downside is that edge case needs are not always served. Tradeoffs.

As far as violating rules of the LV environment, any time we create a "place where you can store a value and then retrieve that value later", that's a gateway for users to create potentially serious race conditions in their code. You'd be amazed at how the simplest code can develop a bug that is only seen on one run in 10000 because it depends upon the timing of the surrounding code. So we tend to shy away from such unless there's a good reason to include them. So it is the type of feature we would shrink away from, but we would include it if there's a good driving need. That's why I was pushing you for a use case.

The "stop VI on remove from subpanel" might qualify. We'll see if the Kudos push this idea higher. Even if it doesn't, low kudos ideas can still get implemented the next time that feature of LV gets revisited by the developer that owns it.

[soupy]

I totally agree. Adding features tends to add tech support overhead.

We'll see who else finds this useful. For now, i've got a work-around that is getting the job done.

Thanks AQ, your input is always appreciated!

[eximo]

Add a boolean property node that is "is VI inserted?"

There isn't a programatic way to know if a VI is loaded in a subpanel, from the subpanel or from the VI.  VI's should have it listed under their execution state, and subpanels should have it listed under their  property node

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/subpanel-amp-gt-amp-quot-Is-Vi-loaded-amp-quot/idi-p/1...

[PaulLotz]

"AQ, just as a side point - the Remove method does currently exist...."

True.  It isn't sufficient, either, in the case of nested subpanels.

[PaulLotz]

AQ wrote:

"Out of curiosity, why are you writing VIs that behave  differently when  they are inside a subpanel vs when they are not? That's  a fairly  strange way to program a user interface."

My thought: If a VI is running stand-alone, it can respond to a Panel Close? event.  It has to do something different (unfortunately) when it is running inside a subpanel.

[mike_nrao]

Also, if a VI is running stand alone, then users have a run-time menu available.  If a VI knew it was running in a sub-panel, it could make run-time menu functionality available by some alternate means.

[G-Money]

Available in LabVIEW 2012

[Intaris]

The current (LV 2012 SP1) method will actually terminate a top-level VI if no references to it are open elsewhere.  This could be remedied by removing the "remove from memory" functionality of the "Remove" invoke node and instead return the reference and let the user decide what to do.

LINK.

I don't know if this requires re-opening this idea (since part of it is not implemented and could solve a current problem) or a new idea is required.

[AristosQueue (NI)]

Intaris: The problem isn't exactly unsolved. It has a viable work around. Instead of calling remove, you can use the property "Inserted VI" to get the refnum and use that to open a new reference before calling "Remove VI". The idea will not be reopened. You are free to submit a new idea to modify the "Remove VI" method.

[AQ takes of LV R&D hat, puts on LV user hat]

... and if you do create a new idea, I'll kudos it, although I'd like it to be something that adds a "Remove And Keep Open" method, not something that deprecates the existing method. Sometimes I want to keep the VI alive... sometimes I don't. I'd rather not do it with an input parameter. And... no, I'll wait until you post the idea to discuss it further.