Organization of Variant Attributes

[drjdpowell]

You'd be better off using the NI Data Type library, plus "Variant to Data", rather than follow the older OpenG library.  OpenG is in many ways a more full-featured library, but it is inherently much slower than the NI function (at least, after a performance improvement of the NI functions in LabVIEW 2013).   I used to use OpenG extensively, but now rely on NI functions.

[drjdpowell]

---

@CoastalMaineBird wrote:

So... How does this work, exactly?

if I deconstruct a variant BEFORE and AFTER I add an attribute to it, I get the exact same TYPE DESC and the exact same DATA STRING.

Is there some other place the attributes are stored?

---

The "Variant to Flattened String" function, with its I16 type descriptors are older tech, and don't support attributes (it says so in the help for this function).  The "Flatten to string" function is the newer way to flatten data.

[CoastalMaineBird]

The "Variant to Flattened String" function, with its I16 type descriptors are older tech, and don't support attributes (it says so in the help for this function).  

--- I realize that. That's why attributes are lost when you use it on a variant.

The "Flatten to string" function is the newer way to flatten data.

 --- My point is not to flatten the thing but to extract the parts.

[drjdpowell]

---

@CoastalMaineBird wrote:

 --- My point is not to flatten the thing but to extract the parts.

---

Use the newer Variant Data Type functions (along with the other Variant functions) to extract the parts.  

[CoastalMaineBird]

I'm stuck on LV2013 at the moment, what version do those appear in?

[CoastalMaineBird]

OK, the format is simple enough.  After the VALUE is stored, there is a U32 which indicates how many attributes follow.  This is true for all variants.

Then the attributes are stored  as variants themselves.  They're already sorted, so it's the insertion process which sorts them.

[drjdpowell]

They're off-pallet in 2013, but "Hidden Gems" adds a pallet for them. 

[CoastalMaineBird]

OK, the format is simple enough.  After the VALUE is stored, there is a U32 which indicates how many attributes follow.  This is true for all variants.

Then the attributes are stored  as variants themselves.

Correction:

After the VALUE is stored, there is a U32 which indicates how many attributes follow.  This is true for all variants.

Then for each attribute there is 

1) a LV String (U32 + N ascii bytes)

2) a Variant.

THAT is why there are TWO names, it stores the "external" name separately, possibly for sort / search purposes.

It is possible to separate out the two attribute variants and re-assemble them in whatever order you like.

HOWEVER

If I do that in the STRING domain, and UNFLATTEN the string back into a variant, the sort is applied again, so they still appear in alphabetical order.

[CoastalMaineBird · Accepted solution]

For the record, I solved this issue without resorting to diddling the order of things in the binary data of the variant.

It turns out that adding a VARIANT attribute doesn't really add an attribute of type VARIANT, it adds an attribute of whatever type the variant currently contains.

That lets me have a single VI with an array of VARIANTS for the parameters, and the user doesn't have to remember all this complication.

I copy the given NAME to the internal name of the variant (otherwise the internal name is "Procedure Name")  I then simply manufacture an external name in sequential order, so that all the sorting is done on that.  Otherwise the external name is not used, in my case.

That lets me offer choices in selectors in the order they were assigned, and deliver the results in the order they were assigned.

Thanks to everyone who contributed.

[kech]

Hi Steve, 

could you please upload the solution.vi 

Kevin