How to add a VI to all children classes for dynamic dispatch

[TheStrangeQuark]

Hello,

I have a LVOOP parent class that has dozens of children classes. I need to add a VI that will be called via dynamic dispatch to all the children classes. I first created the VI in the parent class called `Get Class Name.vi` which just gets the name of the class so I can see what class an object belongs to. After that, I tried going into the parent's properties, then under Item Settings, I clicked on `Get Class Name.vi` and checked the `Require descendant classes to override this dynamic dispatch VI` thinking it would put this VI into each child's VIs, but it did not. Is there a way to automatically populate this into all the children classes?

[prettypwnie]

I don't know of a way to create override VIs for multiple classes at once. But you can do it one class at a time by right clicking on the class: New >> VI For Override. Since you will have to open up each VI one by one to add the functionality you want to it, it doesn't seem like it would save that much time to generate them all at once anyway. Unless, do you not want the children to implement this method differently from the parent? If that is the case, you don't need to do anything, or add VIs to the children. Just uncheck the "Require descendant classes to override..." box and it will automatically run the parent method if the child doesn't have one.

Sidenote: I generally avoid any form of a "What class is this?" method for classes. I think you should try to program your architecture so things using the classes don't need to know what type of child it is. They should just be able to use it and the class takes care of anything specific to that class. If needed, maybe have a "Display Name" method that returns a string, but I don't think this should be necessarily tied to the actual type of the class. But I don't know all the details of your application, so it's possible it makes sense for you, that is just my opinion based on the small amount of information I have.

[Ben]

---

@HopeH wrote:

...

Sidenote: I generally avoid any form of a "What class is this?" method for classes. I think you should try to program your architecture so things using the classes don't need to know what type of child it is. They should just be able to use it and the class takes care of anything specific to that class. If needed, maybe have a "Display Name" method that returns a string, but I don't think this should be necessarily tied to the actual type of the class. But I don't know all the details of your application, so it's possible it makes sense for you, that is just my opinion based on the small amount of information I have.

---

Say I am loading dynamically instance o of classes that descend from a single parent and I want to let the user choose which child type to use...

Example:

Parent : I/O Device

Child1 : Analog in

Child 2 : Digital in

How would you recommend I populate a drop down with the available options if I can not ask them what they are?

Ben 

[prettypwnie]

Yes, that's the exact situation I would recommend having a "Display Name" method. I'm just saying that I think that should not be fundamentally connected to the actual class type itself.

I just think it's better because if you explicitly call the method "Get Display Name" or something like that, then it is much more clear that this method is only meant for getting that text and displaying it and not for doing something like, getting the type of the class, putting it in a case structure and doing different things based on which type it is, which I don't think is usually a good plan.

Maybe it is just a silly point in terms of names/definitions, but I feel like it promotes better programming habits, at least for me.

[tyk007]

GOOP Development Suite (either the NI variant of the open source GDS) provides a higher level of IDE automation then vanilla LabVIEW. You don't need to use the GOOP frameworks the suite comes with; the IDE enhancements are worth the price of admission. If I recall correctly there is a way of adding a member to every class in a hierarchy.

[TheStrangeQuark]

Knowing what class the object is is actually because I'm trying to track a bug that I think is arising in a dynamic dispatch and I'm not sure what class's VI is causing the problem. The class name won't be actually used anywhere except as a probe type of thing