Automated creation of polymorphic VIs

[Mads]

Creating polymorphic VIs is extremely tedious work. Until the day such VIs are made obsolete (generic data type) it would be very nice if LabVIEW could automate parts of the job.

In many cases creating the different instances of a polymorph VI only involves changing the data type of one or multiple inputs and outputs of a VI. No changes in the underlying code (other than those who happen automatically already). For such cases it would be nice if LabVIEW offered an option to automatically generate the polymorph VI.

You would then just select the "template" VI, and for each of the input and outputs (listed in a table for example) you could then choose which data types the polymorph VI should support, and then click OK to generate the polymorph VI.

I'm sure we can create such a tool ourselves using VI Scripting, but it would be better to have it integrated into the shipping IDE.

[PaulG.]

One of the reasons I usually don't bother creating a polymorphic. I only need the one data type now. Too much work to create a vi I *might* need later.

[Mads]

I just found a similar idea here. The difference is that I'm proposing a "Polymorphism Wizard" that can be implemented without really changing anything else in LabVIEW, so less reasons not to implement it

[X.]

You are referring to native data type. I can't see how this can be done in a foolproof manner with custom datatypes (or classes, although I am venturing in unknown territory for me here).

[Mads]

Native datatypes are simpler yes, but for custom datatypes the "Polymorphic Wizard" could accept paths to saved controls (type defs). Several people have made such tools for themselves already so it is definitely doable.

[David_Staab]

I'm not giving this a kudo because I'll settle for nothing less than real generics. Until then, Open-G's variant functions serve that purpose well enough.

[Mads]

Variants do not really fill the role of a polymorphic VI, that's why OpenG consists of  a huge amount of polymorhp instances.

Sure, we can all wish for a Carerra GT, but it's still nice to upgrade to a newer model of the old family car every once in a while 😉

[HarrySa]

I also would be happy with a possibility to use something equivalent to #include for the generic part of the several vis in a polymorphic vi. I do not mean a inline subvi because that also have strict definition of inputs and outputs and does not remove the problem. Copying the vi and only changing the input definition is a lot of work and in case of an error you have to fix the error in every vi of the polymorphic vi and is therefore error prone by the best. I would prefer the common part of a polymorphic vi on only one place.

[RnDMonkey]

What I think would be really cool is a special type of case selector for case structures: a "data-type case selector" if you will. The way I'm imagining it is that you wire up a variant input then your cases are the possible LabVIEW data types, so that the inside of the case selector is the variant data type-cast to the data type of the case. This way you just put your generic code in the case, sort of like an in-place element structure with to/from variant type casting input and output nodes.