lCan child classes that have the same function (e.g. set data) have a common VI?

[Basjong53]

Hello, I have a question regarding classes. I have several child classes that all have a few elements in common. As such they all need the same 'set element' to store some data. But my question is if I have to manual create the 'Bundle by name' etc. blocks individually for each vi? Is there a more elegant solution to create a vi that can be used for by all children but to store data in their own cluster? It seems a bit tedious to create the same vi over and over again for each child class.

[avogadro4]

It seems from your example that Name should be stored in the parent's private data, and you can create a protected accessor so the children can access it, assuming they really need it.

[Jacobson-ni · Accepted solution]

Also, assuming you have already defined Set Name.vi to do exactly what you want to do for the Square Root and Poly class, you don't need to define those methods in either class. If a method VI is defined as dynamic dispatch and doesn't override a parent's method, it will just default to calling its parent's method 

Data access for LabVIEW classes seems to be a common point of confusion for people learning so I also want to make sure you understand that if you have defined some string-typed data "Name" in File.ctl (data for File.lvclass), you will not be able to access that data from either child through the unbundle method but will instead have to create some accessor method as avogadro mentioned.

[Basjong53]

Thank you very much! I understand well now. What I didn't know was that children can acces methods of their parent (Set Name.vi) even if they themselves don't have this method in their class.

Could I ask you another question regarding classes?

If I want that Poly.lvclass does something specific with its data, I have to create a method for Poly.lvclass. In the block diagram, if I wire the parent class to that VI, then it will break. I solved this by addind a 'To More Specific Class' element before the new method. Is this the correct way to do it? Or am I missing some fundamental idea about classes?

[BertMcMahan]

The reason it breaks in your code is that there is a difference between the actual information carried on the wire and the color of the wire. In your code, the "File.lvclass" terminal you have means that, from the point of view of this subVI, you have a "File" object. When you try to call a Poly class method on the File wire, it throws an error, because this VI is only able to see the parent- since that's the control you used to make this VI.

"To More Specific Class" tells the computer that hey, I *know* this is actually a Poly class, so start treating it that way. You're giving it more information so it can determine what to do.

Basically, creating this subVI with File (parent) controls indicates that this subVI can accept *any* class of File or its children. As the Poly method only works on Poly children, the wire breaks. If you use this subVI in code where you only wire in a File object, you will throw an error at To More Specific Class. That function simply tells LabVIEW what the wire *already is*- it does NOT *convert* the object *to* the more specific class, just the appearance.

To fix it, change the File.lvclass control to a Poly.lvclass control. FYI that, very generally, needing to use To More Specific Class often (but certainly not always!) means there's a better way to do whatever it is you're trying to do, namely, by using dynamic dispatch overrides. Again, not a hard and fast rule, just a rule of thumb.