Cannot add button to a sub panel

[GerdW]

Hi Richard,

---

@RichardE wrote:

Probably should not be using sub-panels in this way, but it works, so I am going to leave it.

---

No, you should NOT use subpanels this way!

It makes your VI unreadable to other developers (as can be seen in this thread) because it leads to false assumptions.

• When you need a simple decoration on your frontpanel then you should place a decoration (and maybe group items).
• When you need a "grouped datastructure" then you should use a cluster (which brings its own border).
• When the decoration doesn't serve any purpose then you should not place any decoration at all. Modern UIs seldomly use them: keep in mind what your users might expect from an UI…

You should also learn LabVIEW basics, even your simple small VI shows room for improvements! (Like using radiobuttons instead of two single booleans, using the Select node instead of the case structures, placing a wait inside this greedy loop…)

[Bob_Schor]

---

@RichardE wrote:

Probably should not be using sub-panels in this way, but it works, so I am going to leave it.

---

I'm a little confused.  You appear to be taking a LabVIEW "Operator", a sub-Panel, that has a particular purpose and "use case", and are ignoring the functionality that NI has built into this, and instead appear to be using it as a kind of "Decoration" to "visually bind" a bunch of controls and indicators on your Front Panel.

I strongly urge you to not do this!  Some day, you (or someone else) will need to modify or "re-use" this functionality, and will forget that this is an active part of your LabVIEW code (complete with sub-Panel operators on the Block Diagram).  If you really want to construct a "visual binding" of Controls and Indicators on the Front Panel, do consider using Front Panel + Decoration, and keeping them "bound together" by using the Reorder button on the Front Panel Menu Bar to Group these elements so that they move as a Group.  I believe this will achieve the functionality that you want (keeping Controls and Indicators "together in a recognizable sub-section of the Front Panel" without "perverting" a LabVIEW Front Panel component (the sub-Panel) whose functionality you are not using.

Bob Schor

[RichardE]

Bob, I take your point, and if I was starting again from scratch I would certainly avoid using sub-panels in this way. But the fact is the massive multi-paged VI that I have inherited has used it in this way again and again and I simply cannot risk breaking the code by going through it and weeding out all the sub-panels that have been used in this way.

I am not a LabView expert (as you can no doubt tell) and it has taken me days to make what should be a simple modification. All I had to do was add a button which switches the power to an altimeter. The complication is that there is a diagnostic page that also features a button that does exactly the same thing, and the two buttons have to be kept in synch. But that's another story.

I can see why previous developers have used the sub-panel in this way. If you have any familiarity with Window Forms programming you will know that there is a Panel control that may be dragged on to any form. Any controls may then be dropped within the visible boundaries of this panel and the code that is generated by the form designer adds these controls to a collection within the Panel object. In other words they become "children" of the panel. I imagine that previous developers assumed the sub-panel would work the same way.

[Bob_Schor]

---

@RichardE wrote:

I can see why previous developers have used the sub-panel in this way. If you have any familiarity with Window Forms programming you will know that there is a Panel control that may be dragged on to any form. Any controls may then be dropped within the visible boundaries of this panel and the code that is generated by the form designer adds these controls to a collection within the Panel object. In other words they become "children" of the panel. I imagine that previous developers assumed the sub-panel would work the same way.

---

What you are describing is what I would call (and create as) a LabVIEW Cluster TypeDef.  You create a Cluster with Controls (or Indicators, but not both), placing them as you want them to appear on a rectangular grid, and them make this Cluster into a TypeDef to allow it to be "defined" and used in multiple places.  TypeDefs can also be edited for appearance, if you really want to get fancy with your Control designs, but I rarely indulge.

It is too bad that the long-departed original Developer was so Windows-Forms-centric that the notion of a Cluster to bind Controls together and a TypeDef to allow them to be "reused" were mixed up with the completely-different notion of a sub-Panel in which the Front Panel of another executing VI could be displayed.  If this wrong-headed construct is never used correctly in the Project you are working on, replacing them all with appropriate Cluster TypeDefs should be safe, as well as "saving" the next person to "inherit from you" who might actually know what a sub-Panel is, and wonder why it is never invoked.  Oh, well, let the next guy worry about it.

P.S. -- if you open your Top-Level VIs and do a search (^F) for the function "Invoke Node" in Function "Application Control", you'll see if any so-called sub-Panels are being "invoked" (by "Insert VI" or "Remove VI"), and if not, they are "safe to replace" as they are not being used as a sub-Panel.

Bob Schor

[RichardE]

OK. That seems like a better approach.

The Windows Forms Panel is slightly different in that, although all the controls are children of the panel, they also remain as entities independent of the Panel, and can be accessed directly. There isn't any need to access them through the Panel. I assume that with a cluster you have to extract the control from the cluster before using it. A cluster actually sounds more like a Windows Forms user control which is  a control that the user designs and can be used in multiple places. In fact I suspect that most of the LabView controls are in fact user controls. I believe you can use them in the same way in a C# Windows Forms program.