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

[Intaris]

I've missed this on occasions

Spoiler

I always thought I was too thick to find it.  Is this really currently not possible (without scripting?)

[JackDunaway]

A while back I suggested SubPanels be implemented with Terminals. Bullet item 3 in a comment on that thread, I point out no method exists to retrieve the ref of the currently inserted VI. I'm going to Kudos this Idea to bring awareness to the issue, and possibly we can drum up more discussion on whether users like the idea of a Terminal for SubPanels.

[soupy]

I think that NI is correct and methods are the best way to interface with subpanels. Using terminals don't really intuitively jive with the way a subpanel operates.

It sucks that you can delete the subpanel property node without deleting the subpanel, but once you realize this behavior it really isn't a surprise anymore. It is really only an extremely small inconvenience. The lack of access to the VI ref is a huge inconvenience.

I'm currently getting around the lack of this feature by using a "subpanel manager" functional global that keeps track of the subpanel & VI pairs.

Thanks for the kudos!

[JackDunaway]

---

@bazookazuz wrote:

I think that NI is correct and methods are the best way to interface with subpanels. Using terminals don't really intuitively jive with the way a subpanel operates.

---

Continuation here...

[Intaris]

Not giving a subpanel a terminal (even for using property nodes) is ridiculous IMHO.

[AristosQueue (NI)]

Regarding the original idea:

Asking a subpanel for the VI ref contained within it just turns the subpanel refnum into yet another unsafe global data passing mechanism instead of keeping it focused on the singular task of displaying a VI.

Remove VI is achieved by setting the panel to Not A Refnum. We don't need a separate remove VI method, though we could add one if that helps readability, but it wouldn't return the outgoing VI refnum.

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.

Regarding the lack of a terminal comment:

> Not giving a subpanel a terminal (even for using property nodes) is ridiculous IMHO.

Your statement makes no sense. You can create property and invoke nodes for subpanels. The lack of a terminal does not get in the way of this. And not having a terminal is key to the subpanel's functionality. I have posted this before, but, once again, from the original spec document, here are the reasons for not having a terminal on the subpanel control:

• Having an Invoke Node instead of a FPTerminal properly flags that the act of setting the subpanel must occur in the UI thread, just like all property nodes but unlike all terminals.
• Might be problems where data is written to a terminal but not processed by the UI yet and a property/method is called that has the implicit assumption that the UI is up-to-date.
• Terminals exist mostly to put them on connector panes and this doesn't make any sense to put on a connector pane -- it would be an output but you're not generally passing this out of the VI hosting the subpanel.
• The ActiveX container has a terminal and it works out pretty badly (type is strange, leads to confusion among users, evidenced by CARs filed)

[tst]

AQ, just as a side point - the Remove method does currently exist, so the request was to add the ref.

When I voted for this idea, I was actually anticipating you posting and saying something like "The subpanel is always used in a single VI. You don't need it to do the bookkeeping. Do it yourself and let it focus on its simple job, which is displaying an FP. Your code will be better off as well".

I do agree with that sentiment, but I voted for this idea (and probably for the other one for the same reason) because I like symmetry. I don't like putting something somewhere and then have no idea that it's there unless I always keep track of it. I don't know that I actually would use this (leading to your comment from the other thread about popular requests), but it's something that just feels missing.

[soupy]

---

@ Aristos Queue 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.

---

I've made a bunch of data display VIs. I use a tab structure with a subpanel in each pane so that the user can add/remove whatever display they want. My users prefer to navigate using tab structures over floating windows because floating windows tend to get lost on the desktop with the other software that is running. Fast switching between data displays is very important because we are testing rockets.

[AristosQueue (NI)]

bazookazuz:

I'm not sure how the requested methods play into this. You have a tab control with N subpanels, one per tab. Each subpanel gets loaded by a given VI. At what point do you need to ask the subpanel, "Hey, subpanel, what VI do you include inside yourself?" It seems to me that you only need this function if you have some VI that changes its behavior depending upon whether or not it is inside the subpanel or the VI that is hosting your tab control has different behaviors depending upon which VI is loaded into the subpanel. I'm curious to learn what that behavior change is.

[soupy]

AQ:

Yes, the VI changes its behavior when it is removed from the subpanel. I use the VI ref to progromatacially press the "STOP" button on the VI fp and gracefully shut down the VI. Since i cannot get the VI ref directly from the subpanel "Remove VI" method, i have to keep track of it using other methods. I think that being able to the VI ref directly from the subpanel method would help my code be more future-proof.

The "VI ref" property node would be useful to ask "Hey subpanel, is there a VI inside of you?". Not sure of an exact case where i would need to use this, but it seems like a logical question to ask.

Just curious. Do you know of any underlying reasons this was left out? Does this violate some rules in the labview environment?

Thanks for the response!