LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How dynamic dispatch method was called? Detect dynamically.

Dynamic dispatch method can be called directly or using node Call Parent Class Method placed in overriding method of sub-class.

Can the method itself recognize how was it called? I.e. can code of overridden method check if Call Parent Class Method was used?

_____________________________________
www.azinterface.net - Interface-based multiple inheritance for LabVIEW OOP
0 Kudos
Message 1 of 4
(875 Views)

What about checking the call chain?

0 Kudos
Message 2 of 4
(847 Views)

@tyk007 wrote:

What about checking the call chain?


It was my first idea but it does not work in all cases. For example there are two classes: parent P.lvclass and child C.lvclass

Hierarchy.gif

Both have method M.vi

 

BDs.gif

 

Run this MAIN.vi

 

Run.gif

 

Both calls of P.lvclass:M.vi give the same call chain:

Chain.gif

 

And very important: If C.lvclass does not inherit from P.lvclassC.lvclass:M.vi can call P.lvclass:M.vi directly resulting in the same call chain.

 

_____________________________________
www.azinterface.net - Interface-based multiple inheritance for LabVIEW OOP
0 Kudos
Message 3 of 4
(830 Views)

I’m sure there can be cases where this information could be handy but in most cases where I found myself to look for this or similar solutions, if turned out to be a design problem, and a kludge to try to fix that.

Dynamic dispatched methods simply should not need to know that nor want to try to know that.

 

You could try to parse the class type descriptor and see if the lowest class is the same as your current class but that only tells you half of the story. It can tell you if the actual class in the wire is your own class or a child (or child-child-…) class but if that child class has no overwrite for this method, it was not invoked through the Call Parent Method but simply normal dynamic dispatch method resolution.

 

I believe therefore that it is not really possible and most likely is the need for this a design problem in your class hierarchy or a thought that sits there and doesn’t let you see the much more elegant solution that almost certainly exists.

 

In my programming experience I often came across this when having to solve a complex problem. You start down a certain path only to find yourself at some point in a rabbit hole that seems to require very convoluted techniques to get further. If you then step back a bif and dare to question the choices gou made so far, you suddenly see another path that leads you much more easily to your goal and you realize that those “unnatural” solutions you were trying to find were a strong sign that you got yourself cornered.

Rolf Kalbermatter
My Blog
Message 4 of 4
(792 Views)