Add property to a class to get parent and children classes in the inheritance hierarchy

[mikemattball]

I'm shocked that this doesn't exist, but via help ticket verified that there is no way to do this (or they couldn't figure it out at least).

The following snippet shows what seems like would be close, but they are actually referencing VI's (none of these work):

What I'm after is figuring out the entire heirarchy above the current class level.  I solved this by making a method that passes out it's name and forcing overridden methods below the class.  This works well, but I'm annoyed that I have to create code for what is obviously available somewhere in memory already.

[CMal]

Have you tried the ParentClass property?  This should allow you to figure out the class hierarchy from the bottom up.

This property looks like it was introduced in LabVIEW 2011, so you may not have access to it in 2010.

[mikemattball]

That is exactly what I was looking for. I didn't consider this to be part of the scripting properties and didn't have that turned on in my environment.

P.S. What couldn't NI tell me this?  Arg....

[mikemattball]

Unfortunately that property is not available at runtime, however, so it looks like I'll have to stick with my solution.  That is semi-understandable since the .lvclass may be removed somehow under the hood at runtime.  I still think there should be a solution that is available at run-time, so maybe this idea can get traction as that.

[CMal]

Just to clarify, this property is available at runtime, but it is not available in the Run-Time Engine.  This means you can use it in VIs that are running in the LabVIEW development environment, but it would not work in a built executable (or on LabVIEW Real-Time).  So, I agree that your method of creating a dynamic dispatch VI that constructs a call chain is probably the best approach if you want to run this in a built executable.

[tst]

This is basically a duplicate of this, at least for the parents - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-a-new-VI-Class-Hierarchy-From-Path/idi-p/1214775

[mikemattball]

Thanks, tst.  I did search for about 2 minutes before submitting.  I'm glad to know I'm not the only one who's wanting this.  I've kudo'd yours.

Mike

[AristosQueue (NI)]

>This property looks like it was introduced in LabVIEW 2011, so you may not have access to it in 2010.

The property has existed since LV 8.2. It just wasn't public until recently. If you have a 2010 VI with it on it and you save for previous, the property will still work.

As for being available in the run time engine, none of the reflection API is available there. It is rare that this is a problem -- do you have a specific use case for needing it outside of the dev environment other than the "test if a class inherits from another class without loading the class into memory for plug-ins" (mentioned in the other idea)? The vast majority of the time, the To More Specific primitive handles all interesting questions of inheritance.

[mikemattball]

The To More Specific does work great when you know what the more specific class is.  The problem is I'm making a generic top level class that is needing to know the name(s) of the classes below it for the particular object instance.  Since the Target Class in the To More Specific class method  is required, I can't use it.

I guess I'm in the "rare" case scenario.  I am, after all, making a referenced object architecture, of which I know you aren't a fan of, Aristos. 🙂

[AristosQueue (NI)]

Even a reference object system doesn't typically require dynamic casting like this... can you share details? Are you trying to build some sort of dynamic type registration mechanism for registering callback VIs based on child type?

[mikemattball]

I'm maintaining a single named reference to the object based on the top layer object just below the referenced object (which the lower objects inherit from).  I have a mechanism to lookup all objects of a type.  In an example, a square is a shape is a referenced object.  The reference is name-spaced (using the function in question) at the shape level.  I can get all shapes and find anything that is a shape or square, or any other child of shape for that matter.  I can get all shapes that are squares by getting all the shapes and filtering down to squares.  I'm leaving out some details and unfortunately can't ship an example, but the use case is that the top level "Referenced Object" needs to find out the next level down for a given object.

I solved this by making a required method for every level, but it would be nice to have a way to do this without making that method, and it would need to be supported in the runtime engine.  Since I have a solution it's not a big deal, but I do beleive that this is a method that would be available as natively supported.