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!

[User002]

"How is the idea a good idea but shrinking the borders is not?"

The developer can customize the vi icon so that the cluster icon indicates what type definition it is. Even without customization, the cluster icon indicates that it is a type definition, which the developer (or whoever is reading the code) can go look at to know what's inside. Since it is a type definition, the reader does not have to open the type definition every time to know what is inside (assuming it has its own discernable icon; if there are a bunch of type definitions and they all have default icons, then that does not work so well).

Shrinking the borders of the cluster is worse because it is harder to (1) see that the cluster is a type definition and (2) which type definition it is. If it is not a type definition, shrinking the borders is even worse than that because the cluster itself is the only place where the reader can see which elements are inside.

Coming from the other side, why are cluster icons a good idea on the block diagram, but not on the front panel?

[User002]

"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... At some point, it's time to grow up to a better software architecture, and a cluster you cannot see is a big hint that you're there."

That seems like a hasty generalization. I can see the dangers of letting large clusters get out of control, but what if they are used carefully, in a way that does not hurt run-time performance or maintainability? LabVIEW making it difficult to use large clusters is like having training wheels on a bicycle: it is useful to help beginners figure out how to ride without falling, but it also limits what an experienced rider can do.

[User002]

I like the idea of scrollbars too. They would be useful for navigating, and would provide a visual queue to the reader to know there are more elements in the cluster and roughly how many more. They would also work for clusters that were not type definitions (not that I would generally recommend using clusters that are not type definitions).

I think (well-made) icons would do a better job of identifying which type definition a cluster control or indicator is linked to.

[AristosQueue (NI)]

> LabVIEW making it difficult to use large clusters is like having training wheels on

> a bicycle: it is useful to help beginners figure out how to ride without falling, but it

> also limits what an experienced rider can do.

Clusters ARE the training wheels. You'd prefer that we ship without them? 🙂

> why are cluster icons a good idea on the block diagram, but not on the front panel?

On the diagram, there's a reason to have a cluster constant where you never need to see the values. You just need it to initialize a shift register or set the type for Unflatten From String or something like that.

If you need to see the values, don't use icons. I argued hard to prevent making icons out of non-default value constants. I was overruled. In the years since, I have come to see users who use icons for non-default values as evil monsters who hate me and want me to spend hours debugging their claim that the LV compiler doesn't compile correctly, only to find that there's a 2 hidden inside a consta... oh... sorry... bit of a sore point there. 🙂 

The indicator values on the panel change on every execution. We all type into control values frequently when debugging, trying different values. If you're going to bother using a cluster (as opposed to a class), that's one of its big benefits. Iconifying it removes the single biggest advantage.

> I can see the dangers of letting large clusters get out of control, but what

> if they are used carefully, in a way that does not hurt run-time performance

> or maintainability?

I know of zero non-trivial code bases where this is true. I am not convinced it is possible. I may be wrong, but at this point, I would consider a counterexample to be statistical noise. That's my particular observer bias... I have not measured this with any sort of scientific survey of users.

[wiebe@CARYA]

>wiebe: And the probe window has a scrollbar.

The scrollbar doesn't work for an array of classes. It will scroll through the array elements, not the vertical space.

[m3chtroid]

A stupid trick that does the same thing: Just make it a VIM!  I've done this with extremely unweildly 30+ element clusters so that the front panel wasn't a godforsaken mess.  It's a vim that only accepts one input without breaking the circuit diagram, while allowing you to quickly mess with the defaults.

(NOTE: Don't actually do this.  This is stupid.  I have regrets using it even while prototyping.)

> I know of zero non-trivial code bases where this is true. I am not convinced it is possible.

Large classes?  I mean, the collection of private members aren't exactly clusters, but for all intents and purposes people usually use them similarly...

[AristosQueue (NI)]

Not large classes. Large clusters. And there's a world of difference, particularly in the conversation about FP real estate.

[m3chtroid]

I concede the FP real estate point, but I was more positing that classes with many, many members are often analogous to large clusters, yet often manage to be used "in a way that does not hurt run-time performance or maintainability".  After all, that's one of the things they were made to do.

[AristosQueue (NI)]

m3chtroid: I concede large classes do a better than raw clusters, but they are still problematic. The classes with lots of private data generally end up violating most of the SOLID principles unless that data is divided into a few smaller, nested classes, in which case the cluster size is less of an issue.

[wiebe@CARYA]

>smaller, nested classes, in which case the cluster size is less of an issue.

Except in an array in the probe window 😉.