Allow VI’s from a polymorphic VI to have different connectorpane’s

[WG-]

Example case: 

I created 2 variant VI's on the "Emtpy String/Path.vi". 

• "Empty String/Path variant1.vi", has 2 string inputs and returns true if one of the two strings is empty.
• "Empty String/Path variant2.vi", has 1 array string input and returns true if one of the strings in the array is empty.

Both VI's have the same functionality as you can see, check if strings are empty if so return 1 boolean constant. You now might want to combine these VI's in a polymorphic VI for several reasons:

1. They have the same purpose
2. If you want to put this VI on your pallet (like me) you don't want to have 2 instances on your pallet because of the first reason.

Sadly enough you can't create a polymorphic VI out of this. Because LabVIEW won't allow you to add VI's with different connecterpane's to a polymorphic VI. Hence I say remove this limitation, since a polymorphic VI is more or less just a selector to use one of the VI's which are added to the polymorphic VI. 

[crossrulz]

They work if you have the same connector pattern (4-2-2-4, 5-3-3-5, etc.).

[WG-]

True but then I have to do this for all VI's also for the ones who only have 1 input and 1 output...

[GregR]

The intent of the polymorphic VI is to adapt to the correct instance based on how well the wired inputs match the instances. If one instance has 1 input and the other has 2, how many terminals should we show for the user to wire to? If we show 1, then how do we know which input of the 2 input version that might be? If we show 2, how does the user know which one to wire to for the 1 input version? What names do we put on the inputs if the instances don't have common names? There is aren't really clear answers for these situations so we err on the side of simplicity.

[WG-]

I disagree with you on that GregR, imo that is not the only intent, maybe in the beginning but not nowadays. Look for example in the Control&Design toolkit. National Instruments uses the above technic also to combine VI's which have the same goal or fall under the same category, for example the "CD Construct Transfer Function Model.vi" or "CD Create Pade Delay Model.vi". The only difference is is that they (nearly) always use 4-2-2-4 connector pane's and therefore can merge them into one polymorphic VI. Note that if you didn't already knew this but the VIs in a polymorphic VIs (currently) do need to have the same connector pane but do not need to have all the same connector pane's to be I/O, this may vary from VI to VI. Futhermore, as does NI, VIs which use this should have the polymorphic VI selector turned on by default, but that is a job for the programmer not for NI imo. Hence I think your arguments are not valid in this case because when you drag the polymorphic VI on the blockdiagram it just puts out the terminals for the first VI in the polymorphic VI. Then if you want to have another one you just select it. In this case there is no such thing as adapting to its datatype, of course it is nice that the error wires would wire automatically but other wires which do not match just get broken. It merly goes about being able to merge VIs with the same functionality/goal/purpose in one polymorphic VI in which the VIs could have different connector I/O's (as NI uses them) and for the future also can have different connector pane's  

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.