Creating a ploymorphic VI

[Alias user name here]

Can one create a VI with one or more polymorhpic inputs? I wish to create a Variant VI that will accept and prototype (polymorphic) to cast the variant.

The create poly VIs are quite useless....

[mikeporter]

Well, you can have variant controls and indicators, if that's what you mean. You will at this point have to convert the variant into a LV datatype yourself at this point as the low-level functions in LV are not yet polymorphic to the extent of accepting variant input.

What is the problem you are having with polymorphic VIs?

Mike...

[Jim_Kring]

Yes, there are many instances where PolyVIs just don't do the trick. It is impossible to create a VI for every possible data-type, and simply a waste of time trying to do so -- for example, a VI which tells whether an array is empty.

I suggest that you take a look at the LabVIEW Data Tools library of the OpenG Toolkit. Also, you might want to look at the LabVIEW Data Tools Presentation, which was given by Jean-Pierre Drolet at the May 6th, 2003 OpenG Group Meeting.

Good luck,

-Jim

[Greg_McKaskle2]

> Well, you can have variant controls and indicators, if that's what you
> mean. You will at this point have to convert the variant into a LV
> datatype yourself at this point as the low-level functions in LV are
> not yet polymorphic to the extent of accepting variant input.
>

If you make a VI that has a variant on the connector pane, the user of
the VI can wire anything to the connector, making it very flexible in
terms of datatype. The cost to be paid is that you will need to write a
more complex diagram that takes whatever actions you intend on the
variant. For tasks like adding to a database, this is no big deal.

For other operations, it is better to use the polymorphic VIs.
Polymorphic VIs aren't magic, but they are a way to put multipl
e
functions behind a common interface VI that can autoselect the
implementation based upon the inputs.

The benefit of the variant case is flexibility. The downside is that
this opens up your VI to accepting all types -- your user will have only
runtime errors indicating if the type is correct, and you need to deal
with them through casting or through parsing type descriptors. The
variant will also pay a price in performance.

The benefit of the polyVI is that it allows just the types you
want/need. The user gets edit time information about incorrect
datatypes, and the performance is equal to a subVI. The downside is
that you need to implement multiple VIs, and this runs into problems if
you wish to accept many types.

Both of these techniques are quite powerful, and keep in mind they can
be mixed. You can have variant inputs to polyVIs to handle the less
common types.

Greg McKaskle

[shoneill]

If I understand correctly....

You want to have a variant input, with the corresponding output?

Providing the user wires something (It can be a dummy control - the value can be disposed of) to the VI (U8, or String or whatever) the VI can then output the same data type after casting the variant type.

I also had a similar idea for a VI of mine, but found it easier to simply pass a reference for a control or indicator for which the Data is destined and using the information there (Classname and Typedescriptor for Numerics) for casting the Variant and setting the value via Reference. This has performance issues and breaks the data dependency a little, but it means you can have an input Variant, and the only output is an error cluster. The required indicator
/control value can then be updated without having to rely on polymorphism to ensure the correct data types.

Shane

[Alias user name here]

Greg
Thanks for the reply. I was attempting to create a VI which would act as a data buffer for variant datatypes.

The VI takes the input variant and attempts to perform a conversion. If the conversion fails the VI will return the last valid values or the values of the constant if there is no last valid (first time VI is run)

To convert a variant you need the type descriptor - which cannot be left undfined. The solution is then to drop this code in as code and not a VI.

Regards - Jack Hamilton