Mechanism for LVOOP Parent VI to Prevent Child Override VI Execution

[NathanJD]

I'm working with LVOOP and have my "controller" represented as an object.  The parent class contains the "powered" state private data and along with a "Process" VI.  The "Process" VI can be overriden by the child object and is required to call the parent's implementation.  So, what I would like to do is check the "powered" state in the parent's implementation of "Process" and if the controller is not powered, don't continue executing the child's implementation.

I would like to do this in the parent's implementation so that I don't need to re-write this functionality in each child object's "Process".

So, is there a mechanism to dynamically prevent the child's implementation of "Process" from executing with no code required in the child "Process"?

[nathand · Accepted solution]

The two approaches that come to mind are:

1) Set an error in the parent VI, and make sure the child doesn't execute if there's an error on the error wire.

2) Make the parent call another dynamic-dispatch method that does the actual work, only if the device is powered on. If you're going to do this, there's probably no reason for the outer VI (the one that does the powered-on check) to be dynamic dispatch. So you still need only a single child VI, it just needs to be called from a different place. Unfortunately I don't know how you'd guarantee that it's only called from within the parent.

There's no way for the parent to say "return immediately without executing any of the code that follows" - which is essentially what you're asking for.

[NathanJD]

Thanks for the prompt response.

I am basically doing suggestion 2 currently but implemented in my top-level VI:  If powered, execute "Process".  I would simply need to encapsulate that into a static dispatch VI of my parent class to implement your suggestion fully.

I also like suggestion 1 but I'm afraid that future developers might not be in the habit of ecapulating the child's "Process" code in an error conditional.

So, both suggestions have essentially the same draw back:  The developer needs to remember how to properly implement the code (whether it be top-level or in the child's "Process") instead of having it enforced by the IDE and/or class heirarchy.