02-25-2010 01:07 PM
I want to get the reference to each cluster within an array of clusters and then go through its controls and record their values. I have attached the code I tried but it only gives me reference to one cluster that is currently under focus. The code should be work for any generic array of clusters.
Solved! Go to Solution.
02-25-2010 01:24 PM
Actually, it returns the reference to the elements that is at the location specified by the index display. Thus, you can change the Index Values property to iterate through the cluster and get each subsequent reference.
You said "record their values". Record them how? Record them to file? So the values can be recalled at a later time? If so, there are easier ways to do this. For example, you could Flatten to XML. Also, OpenG has a set of VIs to save clusters to file.
02-25-2010 01:24 PM
An array of clusters just won't let you do that. In an array, all the elements have the same properties, and there is only one refnum for the elements. Normally you could just index the array and unbundle each cluster. Are you trying to do this for a generic cluster? what are you trying to wind up with? Variants might be the way to go here.
02-25-2010 01:26 PM
blawson wrote:An array of clusters just won't let you do that. In an array, all the elements have the same properties,
Yes, but the user is trying to get the values, not the properties.
02-25-2010 01:29 PM
blawson wrote:and there is only one refnum for the elements.
Not exactly correct. The refnum is for the element specified by the index values.
02-25-2010 01:34 PM
oh neat. I bet that could be useful.
The refnum is for the element, and the non-value properties are copied across all the elements, eh?
I've used the OpenG VCluster tools before with success.
02-25-2010 01:40 PM
I did one of those and wrote it up as Nugget found here.
It take a bit more than
Ben
02-26-2010 10:25 AM
Thank you. This is exactly what I was looking for.
I have many clusters that define that parameters for my program. I want the user to be able to save those parameters to a file. Before, I was just flattening the cluster to a string and saving the string but this causes problems when later versions of the program have some modifications done to one or more of the clusters. Obviously the data types of the new cluster won't match the cluster stored in the file and Labview will generate error.
So I thought it would be better to take individual control's value from the cluster and save it to a file. When I'm reading from the file I can match the read control names with the ones that are present in the new cluster. If one of them is not present in the new cluster, it means it was added in the new version and then I do things accordingly.
Your suggestions about XML and especially OpenG look very promising. I'll take a look into both so I don't have to reinvent the wheel. I hope that are able to convert array of clusters (within a cluster) though. If not I guess I can add a layer of code to take care of that.
02-26-2010 11:03 AM - edited 02-26-2010 11:08 AM
This is a pretty standard problem of how to convert old versions of clusters. Here's the guts of a nice clean approach using OpenG VCluster tools. The "New cluster in" control is fed a default cluster of the new version. The first VI builds a list of the element names from the variant. The second one retrieves the value in the "Old Cluster" with that name, if it exists. If so, it assigns the value. The false case is empty. I don't recall testing this against clusters-of-clusters or arrays-of-clusters etc. I wrapped this subVI in another that was specific to the new cluster's typedef. It fed a default constant in, then converted the output back to a cluster, checked for blank required fields and popped up a dialog if necessary.
I've also goofed around with flattening to XML and seeing what happens when you try to unflatten to a different cluster. I think what I remember is that the unflatten depends on the element's order in the cluster and the data type and not the name. EDIT: you can unflatten to a cluster regardless of the label text of each item, but any mismatch of order, type, or number of elements will throw an error.
Ben's link shows an excellent example of the useful strategy of typecasting references "to more specific" and checking the error out to test the type of a control.
02-26-2010 11:29 AM
I should point out that my standard practice is to save the labview datatype directly to a binary file - no flatten to string. When I access it, I check the error output for a type mismatch, and then try again with old versions of the cluster.