Variants and References: Extracting Numeric Value

[mje]

Let's say I have a variant which is holding some type of refnum. The refnum class can not be known ahead of time, it must be determined at run-time. I'd like to be able to extract the numeric value of the reference, but I'm running into an absolute roadblock in how to deal with the fact that my refnum comes in as a variant. Usually I'd just cast a refnum to a U32 (or U64 I suppose if in LV64) and go from there. However, the variant is throwing a wrench in my plans...I can't directly go from a variant:refnum to a U32:

And since I don't know the class of the refnum before hand, I can't use the same Variant to Data primitive to change to a refnum, can I?

I've been playing with the VariantDataType.lvlib VIs for an hour now, and can't quite put my finger on it.

One possibility is to use VariantDataType.lvlib:GetRefnumInfo.vi to get the general class, then assemble a large case structure for each possible enumeration...but surely there's an easier way?

Edited January 13, 2010 by mje

[Francois Normandin]

Let's say I have a variant which is holding some type of refnum. The refnum class can not be known ahead of time, it must be determined at run-time. I'd like to be able to extract the numeric value of the reference, but I'm running into an absolute roadblock in how to deal with the fact that my refnum comes in as a variant. Usually I'd just cast a refnum to a U32 (or U64 I suppose if in LV64) and go from there. However, the variant is throwing a wrench in my plans...I can't directly go from a variant:refnum to a U32:

And since I don't know the class of the refnum before hand, I can't use the same Variant to Data primitive to change to a refnum, can I?

I've been playing with the VariantDataType.lvlib VIs for an hour now, and can't quite put my finger on it.

One possibility is to use VariantDataType.lvlib:GetRefnumInfo.vi to get the general class, then assemble a large case structure for each possible enumeration...but surely there's an easier way?

I think you'll have to restrict a little the classes you're looking because refnums are not all the same type. There is no common ancestor between a VI Ref and a Control reference.

If you know it's gonna be a VI reference (or other refnum type), then you can do it with OpenG.

[Ton Plomp]

NI has provided quite some VIs to get info from variant data.

This is placed in vi.lib\utility\Utility\Variant Data Type.

The VI 'GetRefnumInfo' returns an enum with the type of the actual refnum. Here is some code I used to get a VI and control refnum extracted:

.

You say that you don't know the refnum type beforehand. But I can imagin you can exclude a large deal of the possibilites?

Ton

[Aitor Solar]

Well, this seems to work, though you'll need to transform the string into an U32 (the string is the hex value of the reference number).

Saludos,

Aitor

[Aitor Solar]

Now, to complete the job:

Saludos,

Aitor

Edited January 14, 2010 by Aitor Solar

[mje]

Ah, very nice! Thanks everyone. I had been browsing the Variant Data Type VIs for quite some time as Ton suggested, that's where the library I was referring to lives.

I never thought to look at the data string, Aitor.

Does anyone know if references indeed become U64s when running in the 64bit IDE/RTE?

[mje]

Upon closer examination of the documentation, I found this in the Flattened Data part:

LabVIEW stores the majority of flattened refnums as flattened 32-bit integers, which represent an internal LabVIEW data structure.

Though I wonder if the docs are up to date?

[Rolf Kalbermatter]

Upon closer examination of the documentation, I found this in the Flattened Data part:

Though I wonder if the docs are up to date?

While there is no consistent implementation of refnums in LabVIEW there is one specific thing an LVRefNum has always been, and most likely stays in 64Bit too, and that is its implementation as a MagicCookie as shown in the LabVIEW CINtools headers.

Here you can see in extcode.h

typedef uInt32 MagicCookie;

completely independant of the bitness of LabVIEW so it seems to be a safe assumption for now that the data part of refnums correspond always to a 32Bit value. There is of course a wrench with this, since the so called Tag based refnums, like VISA, DAQmx, etc refnums also consist of a string part identifying the actual resource a refnum refers too, but even those refnums use internally a MagicCookie too.

[shoneill]

While there is no consistent implementation of refnums in LabVIEW there is one specific thing an LVRefNum has always been, and most likely stays in 64Bit too, and that is its implementation as a MagicCookie as shown in the LabVIEW CINtools headers.

Here you can see in extcode.h

typedef uInt32 MagicCookie;

completely independant of the bitness of LabVIEW so it seems to be a safe assumption for now that the data part of refnums correspond always to a 32Bit value. There is of course a wrench with this, since the so called Tag based refnums, like VISA, DAQmx, etc refnums also consist of a string part identifying the actual resource a refnum refers too, but even those refnums use internally a MagicCookie too.

Wow.

Where DO you get this information??

Shane