LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Showing results for 
Search instead for 
Did you mean: 

Malleable Classes

Status: New

OK, using Malleble VIs is cool. Imaging being able to not only wrap code around a variable datatype but wrapping an object around a variable datatype.


I personally have quite a few classes which do pretty much exactly the same thing but which only differ by the precide datatype contained within its private cluster.  No changes in the number of elements, no changes in methods, only the datatype of the specific data.


Obviously, the datatype would have to be compatible with all methods and VIs of the class which use that data field or we would have broken code.

Proven Zealot

So what in C++ is called a template class? Or was is a class template? Never can tell them apart...


That would be very cool. It would be also very difficult to make, but that's not the concern here. So, I'm all for it!


In C++, you specify the 'variable' variable types in\with the template. With .vims that's handled differently, adapting automatically. The way it's handled in .vims won't work in entire classes. How would a class know what type to adapt to?

Proven Zealot

Wiebe, I have no idea how it would work.  The only thing I can think of is a Class "constant" with a datatype input.... or a "special" type of class method before the wire becomes valid? Kind of like an incomplete object, run an "Adapt" method on it with a type input and out comes the correct type of Object (assuming the type and the class are compatible of course).


For me, though, I would want it to work more like malleable VIs than anything else.  Take an existing version, wire up a different datatype and it just adapts.  I suppose it's like templates? I have too little detailed knowledge of those things to accurately refelct on any similarities / differences.  My description above starts sounding more like Traits to be honest. Others have more experience than I do.

Proven Zealot

In C++, there can be a number of types in the template (class or function). It would be swell if LV could do that. So for me, add that to the wish list!


Traits are useful for 'polymorphism' over classes that are not in the same hierarchy, AFAIK. They won't work when the connector pane of those classes is different, which is what malleable classes would get us. We'd get one template class, that gets instantiated several times with different data types in private data and\or CP input\outputs.


I think a class constant to instantiate an instance would give problems with controls\indicators. Those would need to be of a specific instance of the class (I think?).


Maybe it would be better to go for a DVR look and feel? Where you can switch from icon to 'show control' (for our classes 'show controls'). Then the class would somehow need to know where to apply those controls, and where done!


Scripting could get us 70% there. As usual Smiley Frustrated... It wouldn't be too hard to copy classes from a template given a few data types. But it would only be workable when a fair amount or work is handled by LabVIEW internals automatically. Perhaps provider framework\referrer construct will be up to the task, but better leave that to NI.

Proven Zealot

I've played around with putting additional type terminals on an FP terminal and on a class constant. Something like this:


The notation works, but it looks funny. And, to be emphatically clear, those are type inputs, not value inputs. All they're doing is setting the type used internal to the class.


This is just something I've sketched on in spare time... no working code, and definitely not a priority right now. Bigger fish to fry... 😉

Proven Zealot

Originally I was going to have the type inputs be on the front panel -- you'd drop the control then drop subtypes into it to fill in the Mad Libs. But I think the diagram is more appropriate, especially since it allows for type propagation for use of malleable classes within malleable VIs. Works for both the FPTerms and the constants.


The downside is what happens when you copy the control or create control from terminal -- stuff has to be carried along that is more than just the control, which means there's a fair amount of scripting code that would be seriously confused very quickly, among other problems.

Proven Zealot

And those type inputs can\could\will be extendable to get 0..n types?


1 type will only please the crowd for a while...

Proven Zealot

@Weibe 1..n, but, otherwise, yes, obviously. Zero is what we have today. 🙂



Proven Zealot

@AQ: @Weibe 1..n, but, otherwise, yes, obviously. Zero is what we have today. 🙂


Just keeping the momentum from 0 to 1 going! Once you're at 0..2, you probably get >2 for free anyway Smiley Very Happy.