Provide a better way to implement a polymorphic VI

[DanyAllard]

Let’s take the Value Changed from OpenG, This polymorphic as 30+ VIs to support all data type and array size up to 2D. But basically it’s the same VI for all data type.

 I think it could be a “.vip” and when you define the connector pane you select constraint of the possible data type that can be accepted.

[tyk007]

If implemented this would be the most powerful feature to come to the LabVIEW (G) language since OOP. Doesn't look like we'll see this anytime soon though.

[ToeCutter]

Indeed tyk, can't understand why there's not more push for this one. Can anyone from NI comment if this is even on the current roadmap?

[Intaris]

NI is not ignoring this idea.  It's definitely on the roadmap but as yet, there has not been a sufficiently robust solution found.

I for one am quite happy to wait until it is matured before releasing.  I mean, just look at XControls.  With a bit more thought, they could have been SO much more.

[ToeCutter]

Thanks Intaris, that's good to know!

[Intaris]

Well, just remember it's my understanding of how things are, it's not an official stance.  I have no official R&D insight and have never met any of the LV R&D staff personally.  It's just information I have gathered over time, a combination of user posts and rumours.

[crossrulz]

The story I heard some somebody inside of NI (not in R&D) was that they had a solution for generics but then ran into a huge instability roadblock.  From there, it was back to the drawing board.  And what Aristos (from LabVIEW R&D) stated already in this thread is still the current status.

Yes, NI does want this implemented.  They just haven't found a good way to implement it yet.

[tst]

For what it's worth, I expect that even if this feature does manage to make it into LV, people will not feel its impact nearly as much as they think they will. Most code people write is not type agnostic (so you would only really feel it when you're actually developing such code) and poly VIs already provide the functionality (so we're not going to gain anything that we don't already have). The main difference would probably be for people who wouldn't have bothered to deal with poly VIs and now do decide to write some generic VIs.

That's not to say that this is a bad feature. Poly VIs have numerous annoyances and I would certainly welcome this feature and I know that NI would also be happy to be able to have it in LV. It's just probably not AS important as people think it is.

[pawhan11]

Any news on that feature?

Creating polly VIs to handle all data types can be very annoying. And at some point we will have to create ane more to handle specific data type like cluster. There are arleady XNodes and VIMacros that can solve that problem.

When will You make official solution for that problem?

[bean123]

Will VI Macros solve this problem?  See here for a potential work around for the data changed VI:

https://lavag.org/topic/19492-change-detection-vi-macro-vim/#entry117719

[PrimaryKey]

I love how this idea is from 2009 and the status is NEW 😄