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).

[crelf]

"If you delete that one invoke node, you have no indication on the BD whatsoever that the SubPanel still exists" - sounds like a bug to me - maybe you should file a bug report?

[AristosQueue (NI)]

The implementation you suggest was already rejected as part of the original design of the subpanel.

[JackDunaway]

Aristos,

Excellent conversation. Can you explain? I would love to hear the reasoning. Was it a split decision between the developers, or unaninimous to not have a terminal? Could enough support on this board sway future implementation?

Best regards,

Jack

[Darren]

It's been a long time, and I was relatively new to LabVIEW R&D when the subpanel was introduced (LabVIEW 7.0), but my recollection is that there was a fierce, vocal minority that insisted upon the lack of terminal.  Since its inception, I have often wished that subpanels had terminals, but usually, it's because of the annoying scripting code I have to write in tools like the VI Analyzer to account for controls on the front panel that don't have terminals on the diagram.  😛

-D

[JackDunaway]

I'm sure there was a legitimate reason to not have a terminal... I would just like to hear it!

I think the two reasons I gave above are compelling enough to overturn the lack of a terminal. Here they are again:

1. If you hide a SubPanel and delete all Property/Invoke Nodes for the SubPanel, you can't find it (without using a recursive Controls[] PN call)

2. We need a method that returns the reference of the currently inserted VI.

[JackDunaway]

Aristos,

We got a really good answer on this thread. Can you give us the history on SubPanel terminals?

Best regards,

Jack

[AristosQueue (NI)]

> We got a really good answer on this thread. Can you give us

> the history on SubPanel terminals?

Yeah... sorry for the brush off earlier... I've been trying to jump in quick on new ideas that aren't going to go very far just to head off excitement on them. It's difficult at the moment to give detailed explanations because LV is in the last gasps of a release at the moment, and any time a bug report comes in it is "drop everything and evaluate whether this is a showstopper or not and if it is fix it yesterday" priority. 

Anyway... on to the SubPanel...

I went back to the LV 7.0 design documents. Essentially it comes down to three points:

1) The putting of a VI into the subpanel needs to be done as part of the UI thread. The FPTerminal updates in the execution thread, which would create some really awkward timing situations, and require us to compile code into the FPTerminal that isn't normally there.

2) The ActiveX control has a terminal and "it has worked out badly" and we didn't want the same thing to happen with the subpanel. (I have never used ActiveX so I have no idea what the "badly" could be.)

3) Strangely, the use case of putting the subpanel in a cluster was considered important, without changing the type of the cluster... I didn't really think this would work, but I drew the VI pictured below in LV 8.6. Weird... I've never seen a subpanel in a cluster control, but apparently we thought everyone would be doing that someday.

So, there you go. 

[Intaris]

Subpanel in a cluster???

Is it possible to DO anything with it if it doesn't show up in the Unbundle?  Right-click on the FP and create property node?

Interesting.  If we do this does the content of the Subpanel get propagated on the wire with the cluster?

Shane.

[JackDunaway]

Aristos,

Your comment gives me hope, "sorry for the brush off earlier... I've been trying to jump in quick on new ideas that aren't going to go very far". From the mouth Scholar Jim Carrey: "So you're tellin me there's a chance... YEAH!"

You do not know what you have just created: mutiny. I can guarantee that the reason I am about to give is going to convince everyone that we NEED a terminal, and we NEED access to SubPanel elements in a cluster.

You can't create an array of SubPanels, but you can create an array of clusters, and you can put a SubPanel in a cluster, so...

We need the SubPanel to show up as a terminal inside the cluster so that we can create a grid of DYNAMIC INSTANCES of a SubPanel! (Related to the venerable Array of Graphs hack)

Comments:

1. I thought that the UI thread switch would be the main (only?) reason for not having a terminal. We are told writing to a terminal is orders of mag faster than writing to a PN, but it just needs to be in the documentation that in this one case, you're going to incur a thread switch on terminal writes. Your contention... but beginners won't understand thread swapping and why this terminal is different... my contention... beginners don't need to be using SubPanels then.

2. Worked out badly? There seems to be little connection between SubPanels and ActiveX Controls from the user-standpoint. Why should they even be compared?

Best regards,

Jack

[AristosQueue (NI)]

> 2. Worked out badly? There seems to be little connection between

> SubPanels and ActiveX Controls from the user-standpoint. Why should they even be compared?

The ActiveX container control is a display that can spawn its own events that the VI must respond to and broker back to the ActiveX container. A click on the VI when the mouse is over the ActiveX container must be passed through to the ActiveX subsystem for handling, not handled by the VI. The subpanel is a host for another VI and creates the same sort of event proxying requirements.

Again, I don't know or understand the issues that were experienced. I just relayed what the design docs said. The original author of those docs is no longer at NI, and since I wasn't working on that project at the time, I don't know who else to ask for further details. 

Let me as a question though:

Is the main complaint that you can accidentally delete the only Invoke Node for the subpanel? We could probably make that impossible with much less pain than refactoring the existing subpanel implementation (with the attendent problems of mutating all the existing VIs). How far would that go in answering your usability objection?