How can I embed Variant To Data in a subVI and pass in the Type input?

[cpuwzd]

If I use Create Control on the Type input of Variant To Data, I get an undefined type error unless I insert a control of a specific type into the cluster control that was created. This seems to prevent passing a parameter into a subVI for this purpose.

[Jim_Kring]

Yes, you are correct. If you want to use "Variant to Data" in a subVI, that VI will need to interogate the type of data in the Variant and programatically choose between several implimentations that convert to specific types. This is not rocket science, but it is a little tricky until you get the hang of it.

Check out this ==> presentation <== on the LabVIEW Data Tools library of the OpenG Toolkit. You will need to use one of the LabVIEW Data Tools library VIs called "Get TDEnum from Data.vi" which parses the type descriptor of the Variant data to determine its type. Then inside of a case structure you can convert to and handle specific types
. You will also need to do some error checking and output an error if the variant data is not a type that you are expecting. The above mentioned presentation shows examples of this.

Best of luck,

-Jim

[cpuwzd]

Thank you. I am aware of this option, but it is not the direction I wish to go. I'm interested in extending the functionality of Variant to Data, such as using it or not based on an additional input. Clearly, LabVIEW will not allow this with the current design.

As to the existing documentation on the type data returned by Flatten to String, I find it rather incomplete. I have created many types that cannot be decoded using the available documentation. This alone, makes an analytical solution difficult. Adding LabVIEW version dependency really makes this solution fragile.

[Jim_Kring]

> I'm interested in extending the functionality
> of Variant to Data, such as using it or not based
> on an additional input. Clearly, LabVIEW will not
> allow this with the current design.

I do not see what you mean by "using it or not based on an additional input". What would the output of this function be, if it were "not used"? What exactly are you trying to do?

Personally, I have long wanted a polymorphic data type. If a polymorphic control were connected to a VI's connector pane, it would be defined by the calling VI. Once a calling VI wired a data-type to a polymorphic input of a subVI the type would propogate into the subVI.

> As to the existing documentation on the type data
> returned by Flatten to String, I find it
rather
> incomplete.

With the release of LabVIEW 7, NI has updated App Note 154 to include some more data types (and subtypes). If you haven't seen this, I suggest you take a look.

> I have created many types that cannot be decoded
> using the available documentation. This alone,
> makes an analytical solution difficult.

Do you mean compound data types like clusters and arrays? Almost all data types can be decoded just fine with the available documentation. The only types that are not very straight-forward are the waveform data type, refnums, and typedefs. If you give me an example, perhaps I can help.

> Adding
> LabVIEW version dependency really makes this
> solution fragile.

I don't agree. LabVIEW may add new types in new versions of LabVIEW, but fundamentally the typecodes and structure of flattened LabVIEW data types have not changed at all (even though NI does reserve the right to change this in future releases of LabVIEW). Do have specific examples of t
his?

Cheers,

-Jim

[shoneill]

You can of course create a variant control on the front panel. Coupled with the type descriptor, you can programmatically handle basically every data type in LabVIEW.

For a function "Variant to Data", the conversion must be constant (Cannot be passed as a parameter). The reason for this is that the data exiting the function will then change depending on the input, which LabVIEW cannot handle.

You could use a case statement (Based on the information in the Type descriptor) to handle all of your required data types.

Shane.

[cpuwzd]

Jim,

I don't want to get bogged down in details, but in classical terms, the useful output of the VI would be considered a side effect. Imagine, for example, modifying the content of a database.

I have already implemented an alternative solution to this particular problem, but the fundamental issue remains. LabVIEW is able to use polymorphic inputs and outputs for its own purposes but does not extend this ability to user-written VIs. There is already a conformal unit hack using $x notation that addresses a minuscule portion of this general issue.

I have not seen the revised version of App Note 154 yet. My observations about undocumented type codes are centered around data received through an ActiveX interface from a VB application.
I found that the actual types received were undocumented, although they could be coerced to the expected types. The types I was passing were scalars, one-dimensional arrays and two-dimensional arrays of 32-bit integers, doubles, booleans and strings, all embedded in VB variants.

It is specifically the reservation of the right to change the typecode structure that causes the fragility to which I referred. Of course, the alternative is to say that the implementation is frozen for all time, then change it anyway. The real solution is to provide tools to pick the typecode appart in such a way that internal changes are isolated from applications. These tools really need to be part of LabVIEW itself, not an add-on. This way, upgrading to a new release is not tied to a third party.

I consider this matter closed unless you have something earthshaking to add or are dying of some curiosity.

[cpuwzd]

Thanks for your response. This ground has already been covered in a parallel thread.

[parimala]

I too agree with this.I have tried coomunication with Vb from labView using winsock.Some encoding is there.Lv is flexible for Lv not for other languages.