Reference casting dance sanity check

[todd]

I'm bundling FP control refs and sending them to subVIs (kind of like how I do AF actors: bundle the refs into the actor's private data).

In order to make the BD smaller and easier to read, I'm playing with putting the groups of controls in clusters, then sending a cluster ref to a subVI that produces the named bundle of control refs.

I'm looking at vdata and to-more-specific for the cluster-ref-to-bundle-of-control-refs conversion. Is there an easier way?

 

(By the way, very little VI server work is done in the subVIs. It's mostly dynamically registering for change value events.)

 

The image isn't much help, but here it is:

[hooovahh]

So this method is tricky in that it maybe harder to debug.  You can get references to the control programatically so you don't need to create all those references and bundle them.  Instead get all references on the front panel, then filter based on something.  The attached demo uses the Label Text and says find all controls with the label that starts with the text "Boolean" Then it sorts the references then it sets them where everyother is a True and False.

 

This same type of thing could be done but use some other attribute of the control to identify it.  Maybe you look for controls that have a tip strip that start with "Cluster1:" and the full tip strip could be "Cluster1:1" for the first item and "Cluster1:2" for the second.  Or maybe use the Control Description, or use the Label, but hide it and only show the Caption.  Then you'll have an array of Control references that you can then convert to a Cluster of references.

 

This issue I mentioned earlier with this technique is that a new developer may see the value of a control change, but when they right click and say Find >> There are no local variables or references.

Get References to Controls.zip

[QueueYueue]

I've recently started using variant attributes for this sort of thing. You can create an array of all of your controls that you'll need. Then feed that array into a for loop that will add them as variant attributes indexed by label text.

Now when you need one, you give the get Variant Attribute the class type and a name and you've got your ready to go already casted reference.

Obviously you're going to lose some type information when you put it in the attribute, which can result in runtime errors instead of design time errors. I've found this is usually something thats fairly easy to manange on small to medium implementations, but it's something worth thinking about.

[todd]

So this method is tricky in that it maybe harder to debug.  You can get references to the control programatically so you don't need to create all those references and bundle them.  Instead get all references on the front panel, then filter based on something.  The attached demo uses the Label Text and says find all controls with the label that starts with the text "Boolean" Then it sorts the references then it sets them where everyother is a True and False.

 

This same type of thing could be done but use some other attribute of the control to identify it.  Maybe you look for controls that have a tip strip that start with "Cluster1:" and the full tip strip could be "Cluster1:1" for the first item and "Cluster1:2" for the second.  Or maybe use the Control Description, or use the Label, but hide it and only show the Caption.  Then you'll have an array of Control references that you can then convert to a Cluster of references.

 

This issue I mentioned earlier with this technique is that a new developer may see the value of a control change, but when they right click and say Find >> There are no local variables or references.

I hear you. I'm sensing some kind of poly VI that outputs the correct reference based on a string. I don't want to do that in this project - I'd rather have one VI for each cluster that does the casting so the refs can be passed to the loops. It feels like a smaller maintenance choke point (one VI per cluster).

 

I've recently started using variant attributes for this sort of thing. You can create an array of all of your controls that you'll need. Then feed that array into a for loop that will add them as variant attributes indexed by label text.

Now when you need one, you give the get Variant Attribute the class type and a name and you've got your ready to go already casted reference.

Obviously you're going to lose some type information when you put it in the attribute, which can result in runtime errors instead of design time errors. I've found this is usually something thats fairly easy to manange on small to medium implementations, but it's something worth thinking about.

I like variant attributes. I wonder, though: when it's time to use the reference, it still needs to be casted, right?

 

 

At the moment, I'm thinking I'll use one subVI to "manually" step through the cluster Controls[] and feed them to the typedef'd cluster of refs.

[todd]

Like this:

 

I don't like the idea of picking refs off the FP from within any subVI because then I might as well be using a single-loop for everything on the BD. A single loop with access to everything seems to make it easier to cause unintended consequences. If smaller pieces of functionality exist in separate loops, the only difficult part may be "hmm, which loop was THAT part in?". And that seems easier to manage.

[QueueYueue]

I like variant attributes. I wonder, though: when it's time to use the reference, it still needs to be casted, right?

 

Yes.

I thought I had done this in the past and it worked well. I thought that you could use the "Default Value" of your get variant attribute node to do the casting for you. However this appears to not work. I'm less interested in my solution now, but I think it could be useful at times.

[drjdpowell]

 I thought that you could use the "Default Value" of your get variant attribute node to do the casting for you. However this appears to not work.

Seems to work, at least in LabVIEW 2012.

[todd]

Yes.

I thought I had done this in the past and it worked well. I thought that you could use the "Default Value" of your get variant attribute node to do the casting for you. However this appears to not work. I'm less interested in my solution now, but I think it could be useful at times.

 

 

Seems to work, at least in LabVIEW 2012.

2011 and 2013, too. Whether it's a downcast or a default value, I would still need the reference types, correct?