Cast a variant by TypeDescriptor

[candidus]

Hi there,

we have a piece of code, developed in LV6.1 which also worked fine in LV7.1.

It is used to "typecast" a control RefNum to a strict one via "Flatten To String",

changing the type descriptor to the target RefNum type and "Unflatten String To Variant":

The example above works in LV7.1 but not in LV8.0, at least not with a XYGraph control:

If you change the control and depending RefNum in the cluster to something

that already existed in LV7.1 it works even in LV8.0!

I think it's something about the deprecated TypeDescriptor in LV8.0,

perhaps the newly introduced types (like XYGraph, which was WaveformGraph before)

don't return valid TDs.

How to work around this issue? What is the preferred way to do type checking

in LV8.0 without using old style TDs?

[Rolf Kalbermatter]

QUOTE (candidus @ Apr 24 2009, 04:26 AM)

Hi there,

we have a piece of code, developed in LV6.1 which also worked fine in LV7.1.

It is used to "typecast" a control RefNum to a strict one via "Flatten To String",

changing the type descriptor to the target RefNum type and "Unflatten String To Variant":

The example above works in LV7.1 but not in LV8.0, at least not with a XYGraph control:

If you change the control and depending RefNum in the cluster to something

that already existed in LV7.1 it works even in LV8.0!

I think it's something about the deprecated TypeDescriptor in LV8.0,

perhaps the newly introduced types (like XYGraph, which was WaveformGraph before)

don't return valid TDs.

How to work around this issue? What is the preferred way to do type checking

in LV8.0 without using old style TDs?

Hmm, you definitly mix up something here. XY Graphs exist as far back as LabVIEW 2 and in the form and dataformat they have today since LabVIEW 3.

Rolf Kalbermatter

[Francois Normandin]

XY Graphs can have two types: Cluster or Array(of Clusters)

Of course, they give out a different Type Descriptor.

[Rolf Kalbermatter]

QUOTE (normandinf @ Apr 24 2009, 11:16 AM)

XY Graphs can have two types: Cluster or Array(of Clusters)

Of course, they give out a different Type Descriptor.

http://lavag.org/old_files/monthly_04_2009/post-10515-1240586175.png' target="_blank">

Actually they can have at least two formats for single plot and multi plot waveforms each and I believe even more if you get fancy.

Rolf Kalbermatter

[candidus]

QUOTE (rolfk @ Apr 24 2009, 05:42 PM)

Actually they can have at least two formats for single plot and multi plot waveforms each and I believe even more if you get fancy.

Rolf Kalbermatter

Thanks a lot!

So their RefNum types also depend on their style, don't they?

But what's about the change in the class hierarchy? In LV8.0

XYGraph seems to be a subtype of WaveformGraph, at least

the RefNum looked like that and I noticed it changed when just

opening the VI in LV8.0 .

QUOTE (candidus @ Apr 24 2009, 07:44 PM)

In LV8.0 XYGraph seems to be a subtype of WaveformGraph

I'm correcting myself:

In LV7.1.0 XYGraph seems to be a subtype of WaveformGraph.

[Rolf Kalbermatter]

QUOTE (candidus @ Apr 24 2009, 01:46 PM)

Thanks a lot!

So their RefNum types also depend on their style, don't they?

Well for strict typedefed refnums yes, which can be recognized from the little star in the refnum icon.

QUOTE

But what's about the change in the class hierarchy? In LV8.0

XYGraph seems to be a subtype of WaveformGraph, at least

the RefNum looked like that and I noticed it changed when just

opening the VI in LV8.0 .

I'm correcting myself:

In LV7.1.0 XYGraph seems to be a subtype of WaveformGraph.

Not sure about this one. A change in the location inside the class hierarchy should not have an influence on the datatype but only on the inherited properties from its ancestor classes.

Rolf Kalbermatter

[candidus]

Thanks, I didn't know that.

But what about TDs in LV8? I know they're deprecated now but what's the preferred

replacement?

[Rolf Kalbermatter]

QUOTE (candidus @ Apr 24 2009, 02:37 PM)

Thanks, I didn't know that.

But what about TDs in LV8? I know they're deprecated now but what's the preferred

replacement?

Nothing. The new 32 bit typedescritors LabVIEW uses internally are not exposed in any way.

Rolf Kalbermatter

[candidus]

QUOTE (rolfk @ Apr 24 2009, 09:52 PM)

Nothing. The new 32 bit typedescritors LabVIEW uses internally are not exposed in any way.

Rolf Kalbermatter

Oh, that's bad.

Is there any other way to cast a generic RefNum to a strictly typed one

like in the above example? I know I could use "To More Specific Class"

but the problem is that I want to get the target type from the RefNum, not hardcode it.

Sounds weird, I know, but the piece of code above wasn't developed by me and it

took me some time to understand what it should do...

I know I could do something similiar using VI scripting (I tried it)

but unfortunately my application shouldn't run in the IDE so that's not really an option...

[Aristos Queue]

QUOTE (rolfk @ Apr 24 2009, 02:52 PM)

Nothing. The new 32 bit typedescritors LabVIEW uses internally are not exposed in any way.

vi.lib\Utility\VariantDataType

[candidus]

QUOTE (Aristos Queue @ Apr 24 2009, 10:37 PM)

vi.lib\Utility\VariantDataType

Thanks, I already looked at these but in my opinion they are less useful than TypeDescriptors were.

OK, I can use the type enums returned by them and wire the values to case structures.

But I'd prefer a generic solution which works with any type. This seems no longer possible.

Or do I miss something?

[Aristos Queue]

QUOTE (candidus @ Apr 24 2009, 03:54 PM)

Or do I miss something?

I think you miss something. This library covers all LV types.

[Rolf Kalbermatter]

QUOTE (Aristos Queue @ Apr 24 2009, 09:03 PM)

I think you miss something. This library covers all LV types.

He probably means that it is not anymore possible to drop in a single node that does the entire conversion for all datatypes automatically. With those VIs you might have to create a VI that makes explicit conversion in a case structure based on this enum and that will then not work for a new datatype in the next LabVIEW version without modification.

Rolf Kalbermatter

[candidus]

QUOTE (rolfk @ Apr 25 2009, 07:53 AM)

He probably means that it is not anymore possible to drop in a single node that does the entire conversion for all datatypes automatically. With those VIs you might have to create a VI that makes explicit conversion in a case structure based on this enum and that will then not work for a new datatype in the next LabVIEW version without modification.

Rolf Kalbermatter

Thank you! That's exactly the point.

Your answers, especially the first one, pointed me to another issue:

My code example definitely mixes thing up, in a dangerous way:

I mixed up "Flatten to String" and "Flattened String To Variant".

These ones don't play well together, I just verified that they

don't have the same representation for data string... :headbang:

[candidus]

Unfortunately this topic hasn't come to an end...

I still think there's something wrong with XYGraphs RefNums in LV8.0 .

I thought the following was supposed not to return an error:

But it does and it's error 91 again:

The data type of the variant is not compatible with the data type wired to the type input.

But it can be fixed: Just change the type of the RefNum from XYGraph to Waveformgraph

(the type it had in LV7.1...). No broken wire, no error, everything is fine.

It seems there is no way in LV8.0 to wrap a XYGraph RefNum in a variant

and flatten/unflatten it via type descriptor and data string.

Maybe this problem is a candidate for the LV8.0 buglist... :question:

Any ideas?

[Rolf Kalbermatter]

QUOTE (candidus @ Apr 28 2009, 06:36 AM)

Unfortunately this topic hasn't come to an end...

I still think there's something wrong with XYGraphs RefNums in LV8.0 .

I thought the following was supposed not to return an error:

http://lavag.org/old_files/monthly_04_2009/post-15449-1240917817.png' target="_blank">

But it does and it's error 91 again:

The data type of the variant is not compatible with the data type wired to the type input.

But it can be fixed: Just change the type of the RefNum from XYGraph to Waveformgraph

(the type it had in LV7.1...). No broken wire, no error, everything is fine.

It seems there is no way in LV8.0 to wrap a XYGraph RefNum in a variant

and flatten/unflatten it via type descriptor and data string.

Maybe this problem is a candidate for the LV8.0 buglist... :question:

Any ideas?

I think first of all that this is not even doing what you think it does or want it to do. The value

of an object refnum is the refnum itself (a 32 bit identifier that identifies the object in the current

LabVIEw context), not the data the object contains so what you try to do is assigning the refnum

to itself really.

Now why the flattened variant of the refnum doesn't convert (unvariant) easily to the refnum again

I'm not sure but it may have to do with the fact that a variant does not define the exact datatype

as strictly as this function expects.

Variants are very dynamic and can in fact represent the same data logically in different ways with

different levels of type containement.

You would have to analyze the typedescriptor that is returned from the Flatten to String function

and compare it with the flattened typedescriptor of the newly created variant to see if there is

something special.

But considering that this does anyhow not what you want I really wonder if you want to spend more

time on this.

Rolf Kalbermatter

[candidus]

QUOTE (rolfk @ Apr 28 2009, 01:58 PM)

I think first of all that this is not even doing what you think it does or want it to do. The value

of an object refnum is the refnum itself (a 32 bit identifier that identifies the object in the current

LabVIEw context), not the data the object contains so what you try to do is assigning the refnum

to itself really.

I know that I try to assign a RefNum to itself,

I broke my problem down to this simple piece of code.

My real program tries to assign a RefNum of another control to a RefNum

as in my initial example. The only reason why I spent some more time on it

was that I wondered whether this could be some kind of unexpected behaviour in LV8.0,

because it didn't happen in previous versions of LabVIEW and, as

I verified on a PC of a colleague, it seems to be fixed in LV8.5.

Thank you very much for your explanation about variants!