View Front Panel Clusters as Icons

[Jarrod_S.]

Simple idea: Extend the View as Icon mode for clusters constants on the block diagram to cluster controls on the front panel! Simply right click any cluster and select View as Icon to change it from this to this:

We all use clusters on our front panels of our subVIs, but as we add and subtract elements from them, they shift around and start to overlap other controls or they slip off screen. Many times the typedef cluster is used in dozens of VIs. I don't have time to go fix up the front panels of all those VIs everytime I add a new element to the typedef!

Most of the time the cluster is used in a subVI, and I don't care about being able to see the elements inside it. I would prefer in this case just to see the icon on my front panel. In fact, this is one thing I LOVE about using LabVIEW classes! So why not extend that clean view of subVI front panel controls to clusters as well!

[SteenSchmidt]

@Alex.T: Why only if the cluster is wired to the conpane?

/Steen

[KeithTK]

I've used a simple work around in the past: Make the typedef strict, hiding all controls inside the cluster and drop an icon image into the cluster.  I just open the icon editor, copy it and paste it into the cluster.  Autosize to fit then leaves you with just an icon on the front panel.

[Alex.T]

I think that it sounds like this idea is focussed on the situation (Admittedly the most common one!) when where we're using clusters as a way of passing data into a SubVI, rather than something that the user has to interact with. That's why it'd only make sense to be able to hide all of the detail in the cluster if it's capable of having data programmatically passed into it. ... Maybe there could be an option to automatically change the cluster's representation to an icon once it has been wired to the Connector Pane?

[DFGray]

While this would save front panel space, it would also make debugging a lot harder.  I always make my controls, of any type, big enough to be usable so I can use them when debugging the code.  I may be in a distinct minority, however.

[DanRichards]

Imagine adding and organizing several inputs to this front panel. Where do the error in and error out controls go? How do we intuitively place front panel objects to match terminal assinments for subVIs when everything is thrown off by a large object?

Handling this from the right-click menu seems reasonable enough after years of indoctrination on the block diagram side. See images below...

[bienieck]

For the non-user interface FPs LabVIEW Style Checklist suggests the following:

“If a front panel contains a large and skinny type definition cluster, size the panel to fit existing regular controls and include part of the type definition. With a large and skinny type definition cluster, only the width fits in the Minimum Screen Resolution, not the height.”

But it will be much better if there will be possibility to be able to select View Cluster As Icon property for these large clusters.

Another solution for big clusters (but not in all cases) is new FP controls suggested by altenbach. This will be good candidate for new FP standard IMO.

But anyway View Cluster As Icon property for the FP clusters is needed!

[User002]

I like it.

I've tried doing the wrap-it-in-a-class thing to clean up subvi front panels, and I do not think it is worth the overhead. It could make sense for some clusters to be classes, but not when all the developer needs or wants is a data structure.

Another thing I've tried for really large clusters is right clicking the cluster control/indicator and changing Autosizing to None and shrinking the border so it takes up less space, but this has the downside of hiding elements of the cluster. When glancing at a front panel with such a cluster, it sometimes isn't apparent what kind of cluster it is. If it could be shown as an icon it would be a lot easier to identify (assuming it had a good, nondefault icon).

[AristosQueue (NI)]

tannells wrote:

> but this has the downside of hiding elements of the cluster.

Speaking for LV R&D:

That's the same problem that viewing as icon would have. How is the idea a good idea but shrinking the borders is not? The contention between these two requirements is why there's been no motion on this idea.

Speaking for Aristos Queue personally:

Personally, I'm more in favor of scrollbars on clusters as a solution... but I'm really in favor of saying, "If your cluster gets that large, it is your problem, not LabVIEW's." Honestly, most of the time I believe LabVIEW is doing you a favor by making giant clusters hard to use. They are a sign of real code problems that are probably (based on reviewing lots of customer code over the decades) doing terrible things to your run-time performance and developer-time maintenance overhead. Given that, I have been reluctant to advocate for improvements here. It's like advocating for improvements on global VIs or making sequence locals more accessible -- it encourages more users down a dark path. Easy-to-use is good until it starts breaking other design virtues. At some point, it's time to grow up to better software architecture, and a cluster you cannot see is a big hint that you're there.

PS: A class with a giant private data cluster is also problematic but less so.

[wiebe@CARYA]

A class is (like) a cluster that displays as an icon on the FP (but much more than that).

Unfortunately not all big clusters can be avoided. Sometimes you need a pixmap in a class, and the pixmap by itself is huge. I would like to be able to view the pixmap as an icon. In this scenario it's even more complicated, as the biggest problem is in the probe window... So wrapping the pixmap in a class doesn't help.

Even for simple classes contained in a class, the small private data clusters can add up, so even proper separation can result in large clusters in the probe window.

[AristosQueue (NI)]

wiebe: And the probe window has a scrollbar. 🙂 Again, that's my preferred solution for this in the general case.