Dynamic Dispatch Does not Invoke Call Parent Method

[cirrusio]

Hello all,

I have a funny little problem easily worked around but thought I might ask why this is the case.  Below is an implementation of the Actor::Stop Core method.  Below is a shot of the code along with an error.

The current actor is a twice removed from the core Actor class (that is why the parent is not directly the core class).  The parent does invoke the call parent method unconditionally.  The problem is that if I place the Stop Core VI in a flat sequence structure, I get the "dynamic dispatch does not unconditionally invoke the Call Parent Method" error.  And, if I remove the sequence structure above, this error goes away.  So, my question is - what gives?  The flat sequence structure is not conditional and any code in it is guaranteed to execute, so why is this being thrown? 

Cheers, Matt

[Craig_]

That error was intended for when the call parent method is located within a case structure. You're right that it doesn't make much sense in the context of it being in a sequence structure.

My guess is that LabVIEW is making sure that the call parent method is not within any structures. Lots of structures can be conditional, so this is a simple way to verify that it's placed correctly.

If it did account for sequence structures it would have to acount for nested sequence structures, which sounds much more complex than just making sure the call parent is on the top level of the diagram.

[AristosQueue (NI)]

This behavior was my decision. I had a decision to explain to users in the documentation "this feature makes it so the call parent node cannot be inside structures" or "this feature makes it so the call parent node has to be unconditionally executed but only once" -- because otherwise a While Loop would be acceptable. And then you get aruments about a While Loop wired with a constant so it only executes once. And so on. At the end of trying variations, I decided that the loss of the sequence structure was not a great disaster, it dramatically simplified the compiler code (checking for "is this on the top-level diagram" vs "keep checking owning structure and as long as all of them are the sequence structure, let it go"). It also dodged conversations about the Diagram Disable structure (I have the call parent in two different structures, but only one is enabled at a time), which, while theoretically legit, is a very unusual behavior to explain.

So -- one call parent node, must be on root diagram. No ambiguous cases.

[cirrusio]

Thanks, AQ.  You ought to change the error it throws at compile time though - "unconditionally" implies some kind of case structure...

[AristosQueue (NI)]

I thought all the details were spelled out in the help for the error. Is that not true? Click the help button in the Error List Window and see what it tells you.