New SubPanel Implementation: Use Terminals

[JackDunaway]

SubPanels are the life of the party for scalable HMI projects. I use SubPanels inside of SubPanels inside of SubPanels. Currently, when you drop a SubPanel, all you get on the BD is an invoke node:

If you delete that one invoke node, you have no indication on the BD whatsoever that the SubPanel still exists! If you have hidden that SubPanel and have no references to it on the BD, it's a nightmare trying to re-show it through the VI server (especially if it's nested, or in a Tab Container). Further, there is no method that allows you to query the SubPanel what VI is currently inserted into it.

Here's a suggestion for updating the implementation. The "datatype" of the SubPanel is a VI reference, so you can directly write to it or read from it without an Invoke Node. This also allows the parent to query what VI is currently inserted. The "Insert VI" and "Remove VI" Invoke Nodes could go away (wire null ref for "Remove).

[Intaris]

One problem is finsing the sub-panel after accidentally deleting the property node....

I often make the subpanel itself blend in woth the background and finding THAT after deleting the PN is kind a pain in the rear.

I still maintain we need an object tree for the VIs.  We could then just click on the sub-panel entry (event hough we can't see it) and right-click -> create PN

Shane.

[Intaris]

Duplicate post, didn't realise there were multiple PAGES of comments.....

Message Edited by Intaris on 06-16-2009 09:11 AM

[JackDunaway]

Your explanation of the host container draws the connections for me for similiarities between ActiveX/SubPanels. Still, I don't see why this is a preclusion, or is even related, to making SubPanels have a terminal!

1. I have very little complaint about the fact that you are able to delete all property and invoke nodes, hide the SubPanel, and forget about it. I have never done that, but I just wanted to point out that a terminal would fix this issue.

2. It is really nice to be able to click on a FP terminal and say "Show Control" or "Hide Control". This must be done via property node for SubPanel, so that was one reason I wanted a terminal. I regularly toggle visibility of a SubPanel, and must abort the program with the SubPanel visible in order to work on it (or, more painfully, show it through the VI server).

3. The other reason I wanted a terminal was to have access to a ref of the VI currently inserted. Currently, no such method exists! Sure, you could make a PN, but a terminal is a more "natural" way to get the "value" of the SubPanel. It would be so simple to, under the hood, always have a register that was bundled with the SubPanel to store the ref of the currently inserted VI. Today, we must create a variable that is "linked" to the SubPanel that gets written the same ref as the "Insert VI" and emptied when using "Remove VI".

4. Having a terminal/available element in a cluster allows the ability to have an array of clusters that contain a SubPanel. You could "write" the VI to insert directly to the terminal/element in cluster.

Going back to my #3, if you had a "register" that you write and read the ref of the VI currently inserted, you could defer the insertion/removal of the VI into the SubPanel until execution would have updated the panel anyhow. Is it a REQUIREMENT to make insertion of a VI as a synchronous PN? Or could the ref be written in memory, then insertion take place a few ms later?

In regards to "mutating existing VI's": this is the only compelling reason I hear to *not* give SubPanels a terminal. On the other hand, look at the SubPanel to VI's ratio in your project. We have - literally - a hundred or more VI's without a SubPanel for each VI with a SubPanel in our project. The breadth of "fixing" SubPanels for a future LabVIEW release would not be difficult. Further, the implementation does not run "deep". Just take the two most common methods of a SubPanel - Insert and Remove - and replace them with the terminal/locals/Value property.

Best regards,

Jack

[JackDunaway]

Continuation from Add SubPanel Property: VI Ref...

Let me preface by saying that even if Subpanels get implemented with terminals, I still want a property to access the currently-inserted VI...

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.

...but I disagree with this statement. 3D Pictures have terminals, ActiveX and .NET containers have terminals, Tab Controls have terminals, Clusters have terminals... is there any other programmatically interactive object or container on the FP that doesn't have a terminal other than the SubPanel? THIS does not intuitively jive with LabVIEW protocol.

---

On a different note, I just thought about this for the first time: there may be ambiguity when trying to classify a SubPanel as an Indicator or Control. The androgynous FP Object?

---

Finally, the design spec allowing a SubPanel in a Cluster without changing the cluster datatype is still baffling. Could someone speak up and share an experience where you placed a SubPanel in a cluster with the explicit requirement of not having the SubPanel element in the cluster?

[AristosQueue (NI)]

> is there any other programmatically interactive object or container on the FP that doesn't have

> a terminal other than the SubPanel? THIS does not intuitively jive with LabVIEW protocol.

a) Read comment I posted here for why no terminal is on the subpanel control.

b) The ActiveX control and Tab control having a terminal are both regarded as a mistake, one fixed when we made the subpanel.

c) I've never used the 3D picture control. No comment.

d) The cluster having a terminal is because the cluster is data, not a UI presentation element.

> Could someone speak up and share an experience where you placed a SubPanel in a

> cluster with the explicit requirement of not having the SubPanel element in the cluster?

It turns out to be a feature much requested when subpanels were designed that no one uses in practice... evidence, perhaps, that highly kudos'd features are not necessarily ones that should be implemented.

[Britoa]

I just tried using a subpanel in a cluster (that part worked) so I could use it in an action engine and repanel that way.  Didn't work.  You can't pass the subpanel through to another diagram.  (this cluster was a string and a subpanel)

I would guess no one uses the ability to put it into a cluster because it can't be passed out of the VI anyway.