How come you can't put a Tab in a Cluster?

[kmcdevitt]

Hello,

How come you can't put a Tab Control in a Cluster?

It looks like users have been asking this question
for years, and all the way back to LV versions 6.1.

Someday, please, pretty please, NI.
Please. Maybe by version 9.5 of LV?

Kevin.

[NIquist]

Just out of curiosity... Why would you want to do that?

[Sima]

I'm wondering that, too. I don't see why it'd be useful. The Tab control is more of an aesthetic feature, and isn't associated with data like a cluster is. Why not put a cluster in each page of the tab control? 🙂

[kmcdevitt]

Howdy,

If you have a large number of items within your Cluster, then your Clusters tend to get clustered up with clutter. It becomes difficult to arrange lots and lots of cluttered clusterable items within your Cluster. Things just get too cluttered up when you add more and more items to your cluster. One can make the Clustered items smaller is size or with smaller fonts, but then they become less readable if the cluster items are fed from a Control Cluster or fed to an Indicator Cluster. Remember, even an empty cluster, introduces clutter, and take up valueable viewable GUI space. If one cloisters one items into cluttered clusters that never feed to Cluster Indicators or from Clustered Controls, then I guess it would not matter. However, if you have a large number of items in a Control Cluster or an Indicator Cluster, then it would be nice to be able to put associated or related items on one page of a Tab inside the Cluster. Then you could Tab your way through the contents of a cluster Indicator or Control. Some have suggested Cluster of Clusters and programatically varrying their visibility. It makes me shutter at the thought of shuttling the visibility of cluttered clusters of Clusters. Tabs within a cluster would solve all the world's problems.

McKevin.

[agill]

Best Post Ever.

[tbob]

You are right about the clutter.  I use a cluster to hold a whole bunch of local varibles.  Ususally I will use a state machine structure and put the cluster inside a state called "local defs", and this state never gets called.  It is just wired to a shift register so that any local can be accessed in any other state.  Don't have to call the state, just the wiring defines it within the vi.  Then I can make the cluster as big as the entire case structure that holds the state machine.  Hope this helps.

[Sima]

Repeat this 10 times really fast:

A complex configuration of clusterable items can clutter ones clode, I mean, code.

:D:D

[Ben]

This idea just weirds me out!

I understand the cosmetic and GUI interaction part of it OK.

Its the "how would it code?" part that send my head spinning.

Would the tab control be available via bundle by name and unbundle?

If the cluster was an indicator and the tab value was "page1" would the user be able to select page2?

On the block diagram, would there be a relationship between the tab and the elements on each tab?

On the FP the tab control has a "pages" property and from those we can get an array of refs to the controls on the pages. Would we still be able to that within a cluster?

Aside from the above Q's I would guess that the tab in a cluster would only allow greater abuse of clusters i.e. "Super Clusters".

There was also until recently, limitations on the size of the type descriptors. Very complex FP's and large clusters would be hit by the problem that the type descriptor need more than the 16 bit allocated.

I do not pretend to know why NI did or did not allow this. In the end I can only share my guess and hope somone who does know will post.

Related story:

I had often been mystified by "Why I could not create a waveform datatype block diagram constant?". While at NI Week and talking to Jeff Kodosky I asked him (thinking that I would get a good under-the-hood explanation of the data type used blah, blah, blah... He said "I'm not sure. It ws probably an over-sight."

I noticed that in LV 8, you can now create a waveform data type constant.

Ben

[tst]

---

@tbob wrote:

You are right about the clutter.  I use a cluster to hold a whole bunch of local varibles.  Ususally I will use a state machine structure and put the cluster inside a state called "local defs", and this state never gets called.  It is just wired to a shift register so that any local can be accessed in any other state.  Don't have to call the state, just the wiring defines it within the vi.  Then I can make the cluster as big as the entire case structure that holds the state machine.  Hope this helps.

---

If I have a lot of values (or stuff which will be called in other places) I prefer to create the cluster as a typedef and then place it inside a stub VI which does nothing other than return the cluster typedef. Then, doesn't matter how many changes you make to the cluster, it will always be the same size on your diagram.

Of course, you can't say the same for the stub VI and it has the disadvantage of creating more files which you have to manage.

[kmcdevitt]

Ben wrote:  This idea just weirds me out!
Kevin:  Sorry Ben, but think how I must feel.
 
Ben wrote:  I understand the cosmetic and GUI interaction part of it OK.  Its the "how would it code?" part that send my head spinning.
Kevin:  We don't need to worry about that.  We'll let the NI LABview guiruis worry about that.  They know how to program for TABs and they know how to program for Clustors.  Now they just need to put them together.
 
Ben wrote:  Would the tab control be available via bundle by name and unbundle?
Kevin:  Yes.  It would simply return the value indicating which page is selected.
 
Ben wrote:  If the cluster was an indicator and the tab value was "page1" would the user be able to select page2?
Kevin:  Of course, the block diagram would simply pass the enum indicating which page to display.
 
Ben wrote:  On the block diagram, would there be a relationship between the tab and the elements on each tab?
Kevin:  None.  Or no more so than the relationship of any element on a panel or front panel.
 
Ben wrote:  On the FP the tab control has a "pages" property and from those we can get an array of refs to the controls on the pages. Would we still be able to that within a cluster.
Kevin:  Yes.  No Differrence.
 
Ben wrote:  Aside from the above Q's I would guess that the tab in a cluster would only allow greater abuse of clusters i.e. "Super Clusters".
Kevin:  It is not my intent to abuse any Super Cluster in any way shape or from.  In contrast, would help to spread out some clutter from ones front pannels and move the clutter into tabs within a cluster.  The beauty of it would be that it would come automatic, and handled by labview.
 
Ben wrote:  There was also until recently, limitations on the size of the type descriptors. Very complex FP's and large clusters would be hit by the problem that the type descriptor need more than the 16 bit allocated.
Kevin:  I would never suggest even coming close to putting more that 65535 items in a cluser in any fashion.
 
Ben wrote:  I do not pretend to know why NI did or did not allow this. In the end I can only share my guess and hope somone who does know will post.
Kevin:  Yes, somebody from NI might know something about why we can't put a Tab in a Cluster.
 
Ben wrote:
Related story:
I had often been mystified by "Why I could not create a waveform datatype block diagram constant?". While at NI Week and talking to Jeff Kodosky I asked him (thinking that I would get a good under-the-hood explanation of the data type used blah, blah, blah... He said "I'm not sure. It ws probably an over-sight."   I noticed that in LV 8, you can now create a waveform data type constant.
Ben
 
Kevin:
Maybe it was an oversite.  Maybe we can have Tabs in Clusters in 64bit Lab View 9.

Kevin's Disclaimer:  The variation in case usage, while referring to LabVIEW, should not be construed as disrespect, nor should it be interpreted as an indication of Kevin's LabVIEW programming skill or experience or knowlege.