07-29-2014 06:34 AM - edited 07-29-2014 06:47 AM
I bet this has been asked before... So the thing is that I pass a reference of a cluster into a subVI. In this subVI I'd like to manipulate the properties of the controls inside the cluster, eg background color. But it is really hard to access those properties from a reference of the cluster. I need to call the controls[] property of the reference which gives me back an array. I either need to check the names of the controls, or I need to believe that the order of the cluster never changes. Both of these are very counter intuitive.
What would the best way to attack this problem?
Thanks.
07-29-2014 06:49 AM
I would do the checking of the name. Nothing ever stays the same throughout its lifecycle.
If this is something you do a lot, you could create an Action Engine to hold your references and their names. So you initialize by getting the array of references and reading the name. Store both of these in your uninitialized shift registers. So when you want a specific control, you supply the name and use Search 1D Array on your names. Then use the returning index to get your control reference.
07-29-2014 06:53 AM
Well... when I change the name of a control in a cluster then all the bundle/unbundle nodes adopt. Similarly if I change a value of an enum, the case structures adopt. I am not here to argue the reality, but what is the problem creating the same for references? Is there any techical difficulty to simply get the controls[] and then somehow unbundle them by name?
Even I could accept a solution where I need to put the same cluster as a constant into the subVI (eg a typedef instance) which magically does the job for me.
07-29-2014 07:01 AM
07-29-2014 07:11 AM
*sigh* Such a stupid limitation *sigh*
07-29-2014 09:27 PM
As the idea exchange page suggests, you can get a reference to one of the contained controls. Why is this not a valid solution in your case, since it sounds like you have a very static configuration you'd like to apply?
07-30-2014 01:02 AM
Because the idea is not implemented. Getting the individual references of the controls is not an option when we are talking about 20+ elements in the cluster.
07-30-2014 04:28 AM
Can you show code where you have tried yourself to get the references via the "Controls[]" property?
It's not actually that hard, I've done it on many occasions.
07-30-2014 05:03 AM
I think you may have misunderstood me. I can work with the existing possibilities, the issue is that I cant think about a solution which is actually safe.
If I change the order of the elements in the cluster then the order in the controls[] array will change as well and that can remain completly hidden. So referring to the controls by their index in the controls[] array is not optimal. Also referring the control by their name isnt optimal as you may change the name of the items after a while.
(the probelem is somewhat similar to how to work with clusters: I always use the unbundle by name and never the simple unbundle node as the first gives me an immediate feedback about any changes, while the other may hide them.)
The workaround I have found: http://lavag.org/topic/11351-cluster-of-references/
07-30-2014 05:22 AM - edited 07-30-2014 05:26 AM
You do know about the ability to get the ClassID of any control reference, right?
You can easily distinguish a slider from a numeric from a graph and so on.
This is the only other way I can think of to maintain a relationship with any given control reference given that both name and position within the cluster can change.
Or phrased differently, based on which criteria do you propose LabVIEW maintain a unique and safe link between your input cluster reference and your required unbundle functionality?