Jump to content

Variants and References: Extracting Numeric Value


mje

Recommended Posts

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:

post-11742-126342359875_thumb.png

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?

post-11742-126342438664_thumb.png

Edited by mje
Link to comment

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:

post-11742-126342359875_thumb.png

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?

post-11742-126342438664_thumb.png

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.

post-10515-126342486206_thumb.png

Link to comment

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:

post-2399-126345118383_thumb.png.

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

Link to comment

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?

Link to comment

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?

Link to comment
  • 2 weeks later...

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.

  • Like 1
Link to comment

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.

worshippy.gif

Where DO you get this information?? ph34r.gif

Shane

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.