Add Option to Collapse (Shrink) Control on Front Panel to Smaller Icon

[LabViewSolutions.com_(Brian)]

Problem is that sometimes a front panel control is so big, that it takes up too much real-estate.  (Especially, if you are using a lot of elements within a cluster.)

One nice solution, would be to allow the control to be collapsed down to an icon of some sort.

This can easily be demonstrated by the similar behaviour of references that allow the option to "show control".

From this.....                      To this...  

[JackDunaway]

1. Can you show a specific example where this would be desirable?

2. Do you intend for this to be on UI Front Panels, or SubVI Front Panels (panels that are stripped in the executable)?

[tst]

To a degree, this already exists. The Control class has a private method called Convert to Stub which converts typedefs to icons. Presumably it could be extended to all controls, although I don't really see the point. Presumably, if your large control it is also a typedef, right? (RIGHT?) In that case you should be able to use this method, although keep in mind that it's unsupported and I wouldn't personally use it in production code.

I should also point out that LV does have an official way of converting clusters into icons - make them into classes. Classes have issues, but for large clusters, this will have some advantages.

[AristosQueue (NI)]

A) Not showing the control on a reference is fine because that control never changes -- there is no value update to display. Not showing the control in general just hides the value. If so, what's the point of the control? If you want that, just pop up and choose "Hide Control".

B) "Convert To Stub" does more than you think. The stub control does not have a current value. The stubbed out control simply serves as a placeholder for the connector pane, but it is not a control. In other words, after you run such a VI, if you read the control's value, you'd get the default value, not the last value to pass through it. The stubbed controls push performance up when the panel is open by not keeping a copy of the data that passes through (and before anyone reading this panics about "ohmigosh I'm using controls and they're copying data on all my subVIs!", you should know that all controls do not keep such a copy when the panel is closed [unless there is a local variable on the diagram for that control] and in general, when the panel is open, keeping a value is exactly desirable).

Last I checked (and this isn't a feature I have worked with in three versions of LV, so my knowledge may be dated), a stubbed control won't support the Value property and won't allow local variables. I'm also fairly certain that Copy Value, Paste Value and Make Current Value Default have some alternate behaviors for stubbed controls. There may be other side-effects that I haven't heard of.

All of these behavioral side-effects is why that method is private. It was designed to solve some very particular issues for one of LV's toolkits, not for general use.

[LabViewSolutions.com_(Brian)]

Wow!  Amazing to see all the advanced user feedback on this!  Thanks!

@JackDunaway…

1.  Sorry, my example was intended only to be a quick idea of how a control could be shrunk down into an icon.  Of course, I should have taken the time to make a real example.  Please see below.

2.  I had intended it for subVI Front Panels.

@tst & Aristos Queue

Nice info on the stub idea and the reference info.  I appreciate all your excellent knowledge and insight.  Still, neither idea really solves the issue I typically run into.  So let me expound a little....

Typically, I design and produce rather large, turn-key projects (primarily medical based systems and apps.)  I doing so, we usually end up with VIs that have many, many inputs that are difficult to break down into smaller subVIs with more manageable front panels.  Generally, I end up with rather large clusters, group of clusters, etc.  Of course, I routinely unbundle these larger controls and try to use only the elements I need for a specific subVI, but this leads to block diagrams that are very unruly and messy.  I am sure we have all written code that continued to evolve into subVIs that have so many inputs or a ton of wires running everywhere trying to get the single input wire you need.  Smarter to simply use the original complete cluster as an input, which leads to cleaner code and future subVI expandability.

One example that quickly comes to mind is a typical VI that reads a file containing program specific options.  These options (lets call them "Program Options”) are used in several subVIs, so you don’t want to just keep reading the values from file.  This is absolutely fine if you have only a handful of options, but I rarely do.  So, I end up with one or more clusters on my panel that is so big, it eats up all the real-estate.  My programs generally evolve with more and more options as the customer continues to ask for upgrades.  And since you may need different elements for each subVI, there is not always a logical, clean way to just breakup the options into smaller groups.  (Not to mention the unnecessary time and coding it would take to keep doing it over and over again.)

Of course, I do understand about the use of references.  But, that is not always a good idea.  Especially if you are the type of programmer (like I am) that likes to test every subVI we create to validate it’s dependability.  In testing, I like to make changes to a front panel, then see how that affects the code.  Too hard to do with references.  Also, in troubleshooting, it is really great to be able to look at a front panel to see what values were passed to it, etc.  Plus, occasionally, I may want to use local variables.

So again, here is my idea…

To allow the developer, during development, the option to collapse a control or indicator, on the front panel of a subVI, into an object that has a size considerably smaller than its expanded size, while maintaining all the functionality the control or indicator currently has.  The goal is to gain the real-estate lost from the control in its expanded state, while allowing the developer to expand the control (even temporarily) and utilize the control as we do now.

From something like this…                                                                                  Into something like this...

          

[tst]

Seriously, look into LabVIEW classes (LVOOP). This is the official correct answer for handling this issue. You should note however, that this will NOT allow you to test a VI by editing values on the FP.

If you wish, there's another idea about adding a scrollbar to a cluster which is closer to what you want. I suggest you vote for it and add a comment that you also prefer the tab-in-cluster idea I suggested there in a comment (assuming you prefer it. I would expect you would).

[AristosQueue (NI)]

> Seriously, look into LabVIEW classes (LVOOP).

Yup. I agree. You are a *prime* target user for LabVIEW classes. Everything you describe can be significantly improved by adopting LV classes into your designs.

> You should note however, that this will NOT allow you to test a VI by editing values on the FP.

Unless you take the time to build an XControl for your class. I wish that were easier to summon into existence (and, in theory, someone could create a scripting tool that, given a class, prodices an XControl for modifying all the fields of that class), but it can be done by hand.

The XControl that you create can draw small (either as icon or as the mini view that the earlier post proposes) but have behavior where double clicking pulls up a dialog for viewing and changing the values.

[mmoni]

I run into similar problems... and my solution:

1.Right-click on the cluster.

2.Set Autosizing to None.

3.Resize to your taste.

4.Save.

This might just suit you, 'coz you can 'temporarily' resize it to say Size to Fit, change the value of the control, test your subVI and done! Do the steps 1-4 again if you have changes in the subVI to save.

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.