LVOOP "call parent method" doesn't work when used in sibling VI

Question

It seems to me that the "call parent method" doesn't work properly according to the description given in the LabVIEW help.
I have two basic OOP functions I am doing examples for. I can get one to work easily and the other one is impossible.
Background
There are 3 basic situations in which you could use the "call parent method"
You are calling the parent VI (or method) of a child VI from within the child VI
You are calling the parent VI (or method) of a child VI from within a sibling VI
You are calling the parent VI (or method) of a child VI from a different class/object.
From the LabVIEW help system for "call parent method":
Calls the nearest ancestor implementation of a class method. You can use the Call Parent Method node only on the block diagram of a member VI that belongs to a class that inherits member VIs from an ancestor class. The child member VI must be a dynamic dispatching member VI and have the same name as the ancestor member VI
From my reading of that it means situation 3 is not supported but 1 & 2 should be.
Unfortunately only Situation 1 works in LabVIEW 2012.
Here is what I want
And this is what I actually get
What this means is that I can perform a classic "Extend Method" where a child VI will use the parent's implementation to augment it's functions BUT I cannot perform a "Revert Method" where I call the parent method's implementation rather than the one that belongs to the object.
If you want a picture
Any time I try and make operation2 the VI with the "call parent method" it shows up for about 1/2 sec and then turns into operation.
So there are only 3 possibilities I can see
Bug
Neither situation 2 or 3 are intended to work (see above) and the help is misleading
I just don't know what I am doing (and I am willing to accept this if someone can explain it to me)
The downside is that if situation 2 above doesn't work it does make the "call parent node" much less usefull AND it's usage/application just doesn't make sense. You cannot just drop the "call parent node" on a diagram, it only works if you have an existing VI and you perform a replace. If you can only perform situation 1 (see above) then you should just drop the "call parent node" and it picks up the correct VI as there is only 1 option. Basically if situation 2 is not intended to work then the way you apply "call parent method" doesn't make sense.
Attachements:
For the really keen I have included 2 zip files
One is the "Revert Method labVIEW project" which is of course not working properly because it wants to "call parent method" on operation not operation2
The other zip file is all pictures with a PIN for both "Revert Method" and "Extend Method" so you can see the subtle but important differences and pictrures of the relavant block diagrams including what NI suggested to me as the original fix for this problem but wasn't (they were suggesting I implement Extend Method).
 If you are wondering where I got the names, concepts and PIN diagrams from see:
Elemental Design Patterns
By: Jason McColm Smith
Publisher: Addison-Wesley Professional
Pub. Date: March 28, 2012
Print ISBN-10: 0-321-71192-0
Print ISBN-13: 978-0-321-71192-2
Web ISBN-10: 0-321-71255-2
Web ISBN-13: 978-0-321-71255-4
 All the best
David
Attachments:
Call parent node fault.zip ‏356 KB
Call parent node fault.zip ‏356 KB

Answer 1

Hi tst,
Thankyou for your reply. Can you have a look at my comments below on the points you make.
1) Have to disagree on that one. The help is unfortunately not clear. The part you quote in your reply only indicates that the VI you are applying "Call Parent Node" to must be dynamic dispatch. There is nowhere in the help it actually states that the call parent node applies to the VI of the block diagram it is placed into. Basically case 2 in my example fulfills all that the help file requires of it. The dynamic dispatch VI's operation are part of a class that inherits from a given ancestor. Operation 2 for Reverted behaviour is a child VI that is dynamic dispatch and has the same name as the ancestor VI (operation2). The help is missing one important piece of information and should be corrected.
2) True it does work this way. I was trying to build case 2 and had not yet built my ancestor DD for operation so the function dropped but wasn't associated with any VI. I was able to do this via a replace (obviously once the ancestor Vi was built) so this one is just bad operator
3) Keep in mind this is an example not my end goal. I have a child implementation because this is a case where I am trying to do a "reverse override" if you like.
3a) The point of the example is to override an objects method (operation2) with it's parent's method NOT it's own. The reason there is a child implementation with specific code is to prove that the parent method is called not the one that relates to the object (child's VI). If I start having to put case structures into the child VI I make the child VI have to determine which code to execute. The point of Revert method is to take this function out of the method that is doing the work. (Single Use Principal and encapsulation)
3b) The VI I am calling is a Dynamic Dispatch VI. That means if I drop the superclass's VI onto the child's block diagram it will become the child's implementation. Basically I can't use Dynamic Dispatch in this case at all. It would have to be static. That then means I have to put in additional logic unless there is some way to force a VI to use a particular version of a DD VI (which I can't seem to find).
Additional Background
One of the uses for "Revert Method" is in versioning.
I have a parent Version1 implementation of something and a child Version2. The child uses Version2 BUT if it fails the error trapping performs a call to Version1.
LabVIEW has the possibility of handling the scenario but only if both Case 1 and Case 2 work. It would actually be more useful if all 3 cases worked.
The advantage of the call parent method moving one up the tree means I don't have the track what my current object is and choose from a possible list, if, for example the hierarchy is maybe 5 levels deep. (so V4 calls V3 with a simple application of "call parent method" rather than doing additional plumbing with case structures that require care and feeding). Basically the sort of thing OOP is meant to help reduce. Anything that doesn't allow case 2 or 3 means you have to work around the limitation from a software design perspective.
If at the end of the day Case 2 and case 3 don't and won't ever work then the help file entry needs to be fixed.
All the best
David