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.

[tst]

There's some additional discussion on this issue in this thread - http://forums.ni.com/t5/LabVIEW/A-Class-s-Private-Data-and-A-Tab-Control/m-p/2192464#M702870

[Himanshu_Goyal]

Completely agree with tst idea,

This feature can help us to clean and manage code and develope application with less control.

[DailyDose]

Seriously, why hasn't this been implemented?

[AristosQueue (NI)]

> Seriously, why hasn't this been implemented?

Answer for R&D: Other priorities. There are always good ideas to work on.

Answer for myself: I don't think it is a good idea. Oh, I agree there's a problem, I just don't like the proposed solution.

Let me be very clear on this one -- I am not expressing a view of R&D. A large swath of R&D, maybe even a majority, would look at something like this and say, "The screen got messy in the course of the user doing something perfectly legal. That's bad... LV should be offering features to make it unmessy." My personal view is, "The screen got messy... that should be a big red flag that you're doing something inefficient, unmaintainable, or otherwise suboptimal, and the pain you are feeling toward LV's editor should be channeled into changing your design, not into changing the editor."

We've all heard the advice "don't create diagrams larger than one screen. Use 'create subVI from selection' if your diagrams get too big." The reason for that is your code becomes ever more deeply interconnected such that you can no longer debug effectively (because the only thing you can run is the giant monolith) and you can no longer edit effectively (because it becomes less and less clear what the role of each wire on the diagram is with respect to the overall goal of the VI). We can show a pretty good track record that mangeable VIs lead to manageable code.

The same thing applies to these mega structures.

Tst, in the original idea, asks for categories. In my view, if your code is well designed, then you already have categories -- the nested typedefs and classes that are within your megacluster. Instead of creating some sort of tab/folder/flipbook view within the megacluster, I'd suggest some sort of collapsed view for the nested typedefs, just like we have on the block diagram, and just like you get with LV classes -- instead of dropping as a block of elements, you get a single icon.

Drawbacks to this approach are obvious -- can't see your data while debugging (there's a litany of complaints about debugging LV classes). But some sort of combination of "easy, local toggle of individual elements" and "quick view the data in a tipstrip/context help/break-out-view-of-some-sort" strikes me as a better overall solution to the issue. Injecting a tab structure within the cluster just makes it ever easier to construct a single megacluster without fracturing groups of elements out to their own APIs. And that, in my experience, is bad software.

So, I'm open to ideas to manage the megaclusters, but not this particular idea.

[tomlawton]

I just had "a great idea", went to drop a tab in a cluster, found it didn't work, and wound up here...

This was my use case: I wanted a cluster which described an instrument, in some detail. The default tab would have the normal user view, but additional tabs would contain more obscure detail- serial number, last calibration date, yada yada... Easily accessible, but normally not on view. The cluster would then go in an array, for a rack of similar instruments...

Yes, there are other ways I could capture and store this- and I'll have to.

Yes, this probably is crying out for OOP- but I'm not going there. This is software by engineers, for engineers- not computer scientists.. 😉

[AristosQueue (NI)]

> This is software by engineers, for engineers- not computer scientists.. 😉

Go hire a fresh-out-of-school engineer. Most of the EEs and MechEs today have a fairly good base in software. Moreover, in my experience, most of them will be totally boggled by your raw cluster complexity. Their first day of work they'll be asking, "Why hasn't this been refactored long ago?" (The youngest ones won't be able to understand why it was ever written so "badly" in the first place and may question whether they want to continue working for you.)

In responding to your statement, I can't find an emoticon that expresses an appropriate level of "lack of sympathy"... I'm old enough to remember engineers saying similar things about C code versus assembly code. "Sure, I could use one of those structured languages, but I'm not a computer scientist." I rolled my eyes then, and I roll my eyes now. Classes in LV were new 10 years ago... there was a lot of "CS-only" aspects at that point because the training and mentoring didn't exist. But the community and environment have come a long way since then. Engineers are tool users. Use the tools.

[crossrulz]

> This is software by engineers, for engineers- not computer scientists.. 😉

And to add what AristosQueue has said...My background is Electrical Engineering.  I was not taught CS concepts in college.  Even my first job, where I did a lot of programming, taught me CS concepts.  I figured it out on my own that in order to be successful with writing any software, regardless of language, requires CS concepts to be learned: source code control, requirements management, using the right tools for the right job, etc.  I have worked with many engineers.  Almost all of them instantly pick up OOP as soon as you show them how it is done.  And, yes, I was one of those who avoided LVOOP like the plague for a long time.  I now use them everywhere and my code is much better because of it.  Even those who do not know OOP find my code easier to read than the "old" way.

[Steve_Block]

Please add this feature. I have some really large clusters written by people other than me that I would like to be able to organize onto a single screen without having to make major modifications to the code.

[weitong]

I vote for this feature. I just face the same problem.

[crossrulz]

weitong,

You did not vote for this feature.  You have to give it a Kudo in order to vote for it.