Dynamic Dispatched VIs staying in run mode

[mje]

A framework class I'm working on is exhibiting an annoying problem I'm hoping someone can help track down. The most recent version of the framework can be found at the end of another thread, currently at Post #8. I won't duplicate the item here so as to keep it only in one spot.

The problem: After using the class, certain dynamically dispatched VIs won't re-enter edit mode. The VIs have returned, as have any overrides, but are still somehow in run mode. To edit the VI, I must close out the entire project and re-open it. Note that this does not trigger a prompt to save any dirty VIs, nor does it prompt that exiting will abort running VIs (since there are none!).

Steps to reproduce:

1) Open MessagePump Examples.lvproj.

2) Within the project explorer, open Examples/1 - Basic Message Pump/Example 1 - Basic Message Pump.vi, execute the VI.

3) Stop the VI by clicking the "Stop" button.

4) Within the project explorer, open MessagePump.lvclass/Public/PostMessage.vi, observe how it remains in run mode despite not running. Also observe that the child class used in the example does not override this method, and as such there are no running overrides of the method.

4) Within the project explorer, open MessagePump.lvclass/Protected/ProcessMessage.vi, observe how it remains in run mode despite not running. In this case, the child class does override the method. Open it at Examples/1 - Basic Message Pump/BasicMessagePump.lvclass/ProcessMessage.vi. Note how it is not running, and is in edit mode.

When attempting to switch to edit mode for either of the MessagePump VIs, the following error comes up:

Following the steps above, as far as I can tell the error is clearly wrong as no overrides are running. It might take you some time to convince yourself of this as you follow the execution logic of the example. Note MessagePump.lvclass/Public/StartLoop.vi ultimately launches MessageLoop.lvclass/Protected/MessageLoop.vi asynchronously, you should be able to see that this VI does indeed return by use of a break point right before the final error out cluster is written to the indicator, for example.

Any ideas why the two VIs are remaining locked?

-m

[Aristos Queue]

What version of LabVIEW?

[mje]

8.6

[Daklu]

No help for your problem but I can at least confirm I get the same error you do.

[NI-T-IN]

Hi MJE

I've created the following post so that an NI Applications Engineer can get back to you on this issue. Please subscribe/watch the NI Forum thread for further updates. Thank you.

[mje]

Thanks, Nitin. I will do so

And thanks for having someone look into this!