Allow clusters to have "pages"

[tst]

Have you ever created a cluster like this?

I have. Numerous times. It's fairly easy to create clusters which get out of hand. The magic number is usually around 10-15 elements, assuming some of them are clusters as well, but even if those numbers are manageable, I've also created larger ones, and those aren't manageable.

Using LVOOP mitigates this to some degree, but does not solve it completely.

So, it would be great if we could divide the cluster into "pages" or "categories":

This will allow us to logically divide the cluster into manageable areas.

The names of the pages will appear in the selection list and in the unbundle node, as shown in the example (although you could hide them in the node by unchecking the full names option), but they will NOT actually be part of the element's name. Changing the name of a page or moving an element from page to page will NOT require you to change code which already uses that element.

Notes -

1. In my mockup I used a tab control. I understand that LV R&D has some aversion to the concept of tabs inside clusters, so I would like to make it clear that I'm NOT asking for a tab inside a cluster. This is purely a cosmetic and organizational feature.
2. I already posted this as a comment on this idea, but I figured it was worth posting as a separate one.

[elset191]

Some of my XControl State controls are about 3 stories high.  Kudos

[Mark_Yedinak]

While I understand the request I am not sure I think it would be a good idea. The reason I say this is super clusters are not the best programming idea for many reasons. One, too many thinkgs get bundle together and generally when you see stuff like this the items are unrelated as well. Two, you can run into memory issues depending on the size of your elements if you branch the wire. Also, simply from a complexity view point very large super cluster are not that easy to understand. Rather than encourage the behaviour of creating the super cluster steer people to use better programming techniques to keep clusters more focused on specific related data and better use of modularization. Super clusters make it much more difficult to reuse code simply because of the extra baggage they carry with them.

[tst]

Mark, that's very good in theory, but in practice there are times you need large clusters. Simple example - think of LV's VI server hierarchy. If you look at the Control class, for instance, it has a couple of dozen properties, and that does not include the additional private data it carries.

So yeah, most of us don't need to write things which are as complicated as LV's VI server hierarchy (to make an understatement), but we do have cases where something needs dozens of pieces of state information. I don't think that this makes it a super-cluster, just a large cluster which needs to be managed.

[Mark_Yedinak]

I defintiely understand what you are saying. I just think that if this were available it would be something that would get abused by novice programmers. As you say, there are times that large clusters would be required but hopefully that is the exception and not the rule. What could possibly be a compromise and may exist now that they are adding to show clusters as icons would be to extend that to typedefs. The problem for large clusters really comes into play when you have multiple clusters. If these were displayed as icons that would significantly decrease the size on the front panel.

Edit: I wish you were allowed to remove a kudo. At least for a few minutes after giving it. Click in the wrong place and you give a kudo you didn't intend.

[Darin.K]

Edit: I wish you were allowed to remove a kudo. At least for a few minutes after giving it. Click in the wrong place and you give a kudo you didn't intend.

Idea Options -> Revoke my Kudos.  No timelimit that I am aware of, might be too late once the idea is implemented in LV...

[tst]

Mark, personally I think that the whole issue of features which would get abused by novices is often given too much consideration. I'm not against protecting novices (and those of us who later have to deal with their code) from their mistakes, but when it comes at the expense of something that advanced users need (and this is exactly the kind of feature that becomes necessary when you have larger and more complex code) I'm of the opinion that the new users should not be the reason why such a feature isn't implemented.

In any case, LV already has two distinct options for converting typedef clusters to icons:

1. LVOOP, naturally and officially.
2. The private Convert to Stub method which I never used and which apparently has its issues (see the comments here).

As I said in the idea, this only mitigates the problem. It does not handle the situation where you have many non-LVOOP values, which can be a real situation.

Incidentally, even if you do have objects as part of your cluster, this would probably still be desirable, as you still might wish to get a single view of the data in your cluster (see the old "classes should have an XControl display" idea) and this makes it manageable.

[tst]

Just to better illustrate, here's a real world example (with the names obviously scrubbed. The majority of them were actually longer than here, so the cluster was bigger) -

This is the worst case I had to deal with. Roughly 200 controls in nested clusters. In my defense, I wasn't the one who created this code originally, but I did finish and expand it considerably and I can say that all of those controls were actually needed to keep the data that was required, and keeping them together was relatively important, because the data was later also serialized. I could probably have split them up, but that would have been artificial split without any proper justification.

As I'm sure you can tell from the style of the controls, this is pre-LVOOP, but even that would only help to a degree, because some of those classes would still have too many elements (as, indeed, do many of my classes today).

[Chris_H.]

I the past my cluster were looking similar and they were hard to handle.

Then I started to implemented my application in Object Oriented style which helped a lot.

Therefore I rather recommend to use OO instead of additional features like taps in clusters.

[tst]

OK, so here's another real world example, this time with OO.

This is one of the classes in the project I currently have open, again with names scrubbed:

If you include the elements in the subclusters, this comes up with close to 30 elements, and it will most likely gain some more as time passes. I could set it up in a grid pattern, but I'd rather not do that, and that still won't help in cases where I include this class as a member of another class and I want to see everything together (assuming that classes will have a data view).

[Ray.R]

I like it...

I can see where LVOOP would also benefit from this idea.