Passing properties from subVIs

[Brino]

Hi,

I am trying to pass a cluster control(using a reference) to a subVI which will update the properties(i.e. value, text color and bg color) in the main VI. I have tried using a reference node and can't get it to work. II probed the refnum in main and the subVI and seems to pass ok as long as I do not update a property. When I do add to update a property I get an error (Error 1055 occurred at Property Node in ... LabVIEW:  Object reference is invalid) and Not a Refnum on the probe.

Also how would I reference cluster elements to update only the element properties and not the whole cluster.

Thanks,

Brino

[Dynamik]

Hi Brino,

      Can you create and attach two VIs (caller&sub-VI) that exhibit the problem?  (sounds like "operator" error)

Message Edited by Dynamik on 12-09-2005 11:20 PM

[Brino]

Hi DynaMik

Thanks for your quick response. I did find the problem. I had a few of the sub VIs being called and did not have the reference wired to all. Even though the first one in the data flow was wired it would still throw and error. When I wired the rest it worked ok. The other question I still have is can I and if so how do I access element properties of a cluster. I have attached a simple caller and subVI and would like to know if I can control element properties on the main VI from the subVI. i.e. text color and bg color of each of the SMs in this cluster.

Thanks again for your quick response.

Brino

[MartyS]

You can get at cluster elements by reference. Any cluster has a property called Controls[ ] which is an array of references to the elements.

If you know the elements are all strings, as in your example, you index Controls[ ] according to which element you want (you have to know the ordering of the elements, too), then typecast Controls[i] to a reference to string. The string reference (output of Type Cast) will give you string properties such as the background color, which you can set the way you want them.

Caveat: You have to explicitly close all references that are part of Controls[ ]. You should do so each time you access Controls[ ], immediately after processing. LabVIEW automatically closes some types of references, but I've learned the hard way that it doesn't close Controls[ ] references automatically. If you don't close them, the application will hoard the memory, which can be (in my experience) 30 to 50KB per reference. So every time you take the Controls[ ] property of a cluster, you may effectively leak as much as 50KB per cluster element.

::Marty

[Dynamik]

Hi Brino,

      Given MartyS's tip about control-references - thanks Marty!, I didn't know that  -  there's another approach that might work for you.  If you create a typedef for each object in the FP cluster and pass them as a cluster of type-defs, you can access the objects directly from their references in the Sub-VI.  It will make the Sub-VI-diagram more readable too.

Either way, beware the affect of changing the FP cluster.  With the control-refs-array approach, there may be indexing-considerations in the Sub-vi, with the cluster-of-type-defs approach, that cluster may need to be modified!

cheers! 

Message Edited by Dynamik on 12-12-2005 02:37 PM

Message Edited by Dynamik on 12-12-2005 02:38 PM

[MartyS]

Dynamik said: >

      Given MartyS's tip about control-references - thanks Marty!, I didn't know that  -  there's another approach that might work for you.  If you create a typedef for each object in the FP cluster and pass them as a cluster of type-defs, you can access the objects directly from their references in the Sub-VI.  It will make the Sub-VI-diagram more readable too.

Either way, beware the affect of changing the FP cluster.  With the control-refs-array approach, there may be indexing-considerations in the Sub-vi, with the cluster-of-type-defs approach, that cluster may need to be modified!

**********

Yes, because of such difficult maintenance, getting at cluster elements by reference isn't necessarily the best strategy to solve a given problem. But I've often found it useful.

There are all kinds of kludgy conventions that can minimize the risk of changes. You can have an array of buttons ordered to correspond to the ordering within the cluster, so that if you click button #N, cluster element #N is processed. You can have conventions about labeling cluster elements to identify them for a certain kind of processing; that kind of thing. The TypeDesc (type descriptor) property can be used to identify data types. Of course, it's risky to have to remember conventions like that 8-).

What I often do is to make an action engine that's initialized with a reference to a cluster (copied to internal shift register), with at least "get" and "set" actions for the different elements. (I usually have "get all" which just passes the input shift register values to shift-reg. outputs and to indicators.) The actions work by dereferencing. If the cluster is a typedef, changing the typedef may break the action engine. However, if the action engine is the only entry point for modifying the cluster in any way (good practice: reduces wiring clutter since you don't have to pass in a reference except on "initialize", and makes it easy for subVIs to modify the cluster), you only have to fix the action engine when you change the typdef.

::Marty

[Brino]

Thank you both Dynamik and Marty.

Works great and thanks for the tip about closing the control references to stop memory leaks since I will use the subVI about 8 different times in the main and with 32 different control elements this probably cause some problems.

Brino

[Brino]

Hi,

Because of the indexing considerations, I tried creating typedefs for each object in the FP cluster and passing the whole cluster to the subVI but they would not change the properties in the FP VI only in the subVI even though they were linked to the same typedefs as the FP VI. 

How do you access and change the properties in the FP from the subVI this way?

Thanks again,

Brino

[Dynamik]

Hi Brino,

sorry for the wait ...

Note/after-thought - since there will be 8 (or so) sub-VIs, you'll probably want to make a typedef of the Cluster-of-Typedefs

Here's an example

BTW, if this example doesn't work, or doesn't suit your needs, please post your VI(s)! (thanks  )

Message Edited by Dynamik on 12-13-2005 09:19 PM

Message Edited by Dynamik on 12-13-2005 09:24 PM

[Brino]

Hi Dynamik,

Thanks, your examples helped a lot and the program is working well.

regards,

Brino