LabVIEW 8.2 control refnum type descriptor missing

[cinsight]

In LabVIEW 7.1, the control refnum had a type descriptor property, I do not see it in LabVIEW 8.2.1?  How do you get the type descriptor from a control refnum in LabVIEW 8.2.1?

Respectfully,

Robert

[rolfk]

---

@cinsight wrote:

In LabVIEW 7.1, the control refnum had a type descriptor property, I do not see it in LabVIEW 8.2.1?  How do you get the type descriptor from a control refnum in LabVIEW 8.2.1?

Respectfully,

Robert

---

You don't! The old typedescriptor has been obsoleted with LabVIEW 8.x. The reason is that the old typedescriptor was using 16bit lengths internally and could overrun those for very complicated typedefs. The solution was to modify it to use 32bit lengths and since that is an incompatible change to the previous format, completely hide the typedescriptor in newer LabVIEW versions.

The only function that still can give you an old style typedescriptor is the Flatten to String when you select the Pre-80 compatibility mode in the right-click popup menu.

Rolf Kalbermatter

[Ben]

Rolf wrote "The reason is...."

This is what i always loved about your postings Rolf. You not only answer the "what" but also the "why".

"Hats off to you!"

Ben

[Matthew_Kelton]

Is there a way to get to the new version of it?  I am using control refs and the type descriptor to determine if the control is a U16, DBL, etc.  The Class ID and Class Name does not discern between those two for example (18, "Digital").  I was using the first and second element of the type descriptor to determine the precise type.  Is there a way to do this now?

[rolfk]

---

@Matthew Kelton wrote:
Is there a way to get to the new version of it?  I am using control refs and the type descriptor to determine if the control is a U16, DBL, etc.  The Class ID and Class Name does not discern between those two for example (18, "Digital").  I was using the first and second element of the type descriptor to determine the precise type.  Is there a way to do this now?

---

You can wire the control to a Flatten to String and enable the 7.x compatible mode and will in that way get a type descriptor array that is formatted like the old version. The 32 bit type descriptor is nowhere exposed as far as I could conclude. Of course I might have missed something.

Rolf Kalbermatter

[Matthew_Kelton]

The problem I have is that I have a generic control reference, so I don't know the type.  That is why I was using the descriptor to determine the type to properly use variant to data on the Value Property.  As it stands now, 8.5 still supports the Type Descriptor if it exists in VI I upgrade, but how long before it disappears?  I use this in a generic VI that is used in every project I do, saving me hours per project.

The least NI could have done was just name is TypeDescr16 and TypeDescr32 or something.

[rolfk]

---

@Matthew Kelton wrote:
The problem I have is that I have a generic control reference, so I don't know the type.  That is why I was using the descriptor to determine the type to properly use variant to data on the Value Property.  As it stands now, 8.5 still supports the Type Descriptor if it exists in VI I upgrade, but how long before it disappears?  I use this in a generic VI that is used in every project I do, saving me hours per project.

The least NI could have done was just name is TypeDescr16 and TypeDescr32 or something.

---

TypeDescr32 is NOT exposed and on purpose too so there can't be such a property. And yes there is a chance that the old TypeDesc property disappears at some point. However it won't be tomorrow. The 4.x compatibility mode for the Typecast function (necessary for the boolean size change from 4.x to 5.x) is still there but for the Flatten/Unflatten it had to make place for the 7.x compatibility flag. And it might disappear with LabVIEW 9.x since as I have found out today, LabVIEW 8.5 is the first version that refuses to load 4.x VIs directly.

So the TypeDesc property will probably work until around LabVIEW 12.x when it will cease to support loading LabVIEW 7.x VIs. (Note, this prediction is just a very wild guess and should be taken with a big grain of salt).

Rolf Kalbermatter