LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Easy way to work with array of control references?

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.

0 Kudos
Message 1 of 13
(3,898 Views)

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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 13
(3,889 Views)

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.

0 Kudos
Message 3 of 13
(3,884 Views)

Unbundle cluster reference


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 4 of 13
(3,876 Views)

*sigh* Such a stupid limitation *sigh*

0 Kudos
Message 5 of 13
(3,868 Views)

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?

0 Kudos
Message 6 of 13
(3,832 Views)

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.

0 Kudos
Message 7 of 13
(3,813 Views)

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.

0 Kudos
Message 8 of 13
(3,794 Views)

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/

0 Kudos
Message 9 of 13
(3,787 Views)

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?

0 Kudos
Message 10 of 13
(3,780 Views)