Convert an Array of Variants into a Cluster

[drjdpowell]

It is common, in writing reusable code, to handle arbitrary clusters in variants.  To access the elements of the cluster, one wants to convert the cluster into an array of variants containing the individual items.  After access, one needs to convert the array of variants back into the original cluster.

There are several examples of packages that use this on NI.com and in the LAVAg.org Code Repository.  They mostly use functions for working with Variant Clusters from OpenG; however, these can be quite slow.   Recent LabVIEW versions have had the ability to do much of the functions quicker, however, there is a very imortant missing native ability: to convert an Array of Variants into a Variant Cluster.

The other direction, Cluster to Array of Variants, works like this:

But trying to reverse the process breaks:

So my idea is make the second image work; make an Array of Variants interchangable with a Variant Cluster in the "Variant to Data" LabVIEW primative. The interchangability should apply to contained subclusters/arrays also.  The matching of array to cluster elements can be by cluster order rather than element name.

This would greatly aid the performance of reuasable packages that operate on arbitrary clusters.

[drjdpowell]

I've been experimenting with possible ways of substituting for a lack of this functionality in LabVIEW, and I have to admit that AQ might have the best idea.  Here's the function:

Yes, that's a case structure with a separate case for every size of array one wants to support (I've done up to 50).  The Array to Cluster primitive has the be configured for a different number of elements in each case.  This is about an order of magnitude faster than the OpenG function.   It can't be made to work with an arbitrary array size, but can work with the largest clusters I could conceive using.

[fabric]

Interesting!

James, would you mind posting the code (2012 or earlier) to save me recreating all those cases? 🙂

[tst]

---

@drjdpowell wrote:
The Database Toolkit this primative is from...

---

Not that it really matters, but it's not a primitive. It's an XNode (which is presumably locked).

[drjdpowell]

Here is the function:

Wait... How does one attach files here?

[AristosQueue (NI)]

> Wait... How does one attach files here?

Not possible within the Idea Exchange. Have to post somewhere else and then link.

[fabric]

Or post a snippet...

[drjdpowell]

VI is posted on this LAVA conversation.

[Hooovahh]

I made an XNode that does this and posted it in that thread.  It uses your method of Array to Cluster >> To Variant >> Variant To Data.  Must more simple than the database one.  All the XNode really does is change the terminal types, and sets the cluster size.

[crcarlin]

I just wanted to offer my real world use case for this feature.

I'm writing a serializer/deserializer that can save a cluster to a text file or load it from a text file.

We have a few different cluster types to save/load, so it would be nice to send the cluster as a variant to one serializer or receive the cluster as a variant from the one deserializer. The transition to and from variant happens in the calling VI.

Even including AristosQueue's array to cluster function in the calling VI, right before variant to data, is a little hassle as it means an extra thing to update if the cluster typedefs are changed. drjdpowell's workaround is funny, but I'll go with it 🙂

[wiebe@CARYA]

I got this functionality by flattening the individual elements and then concatenating and unflattening. This is especially hard for classes, as the flattened data is empty for default values. You need to get the data from somewhere else, which is terribly slow.

The proposed solution work is hard to apply to recursive clusters. For instance a cluster that has a cluster and is converted to an array of variants where each element in each cluster becomes an variant in the array. Flattening\unflattening still works. I might have to reconsider my approach...

This would be so much easier if LV did this for us.