06-22-2006 02:25 PM
06-22-2006 03:07 PM
06-22-2006 03:19 PM
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? 🙂
06-22-2006 04:45 PM
06-22-2006 04:51 PM
06-22-2006 04:52 PM
06-22-2006 04:58 PM
Repeat this 10 times really fast:
A complex configuration of clusterable items can clutter ones clode, I mean, code.
06-22-2006 05:35 PM
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.
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.
06-23-2006 01:18 AM
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.
11-14-2008 03:29 PM