Dynamic Dispatched VIs staying in run mode

[kegghead]

Ah, I think we were misunderstanding each other.

If I do what you outlined, yes, I'm prompted to save any VIs I edit when I try to close out the VIs or the project, and the file on disk is definitely updated. I was under the impression that when you opened the project, you were showing that some of the VIs already appeared dirty before you did anything due to automatic code changes.

The "save problem" I was referring to is once the two VIs (MessagePump:PostMessage.vi and MessagePump:ProcessMessage.vi) become stuck in a run state, when I quit the project, I do not get the dialog warning that quitting will abort running VIs. Perhaps I should have never mentioned the save dialog in the steps to reproduce the behavior, since I never edited any of the VIs to trigger the dialog to begin with. The fact remains though, that there appears to be a contradiction in the run state of the VIs. Quitting out the project does not warn of any running VIs, however I can't switch the two VIs in question to edit mode because apparently there are overrides stuck in run mode.

-m

[Burt_S]

That makes sense.  I thought we might be seeing the same behavior afterall.  I was just worried that this issue was keeping you from saving your work.  I'm glad that it isn't.

[kegghead]

Have you been able to reproduce the problem referred to in the original post? That is the two dynamic VIs of the base class staying in run mode?

[Burt_S]

Yes I have.  R&D is currently looking into this.  Thanks!

[Ben]

Ignore this post (I would delete it if it was allowed).

Ben

Message Edited by Ben on 04-08-2009 09:24 AM

[kegghead]

This issue came up for me again today, and I realized the thread here has links which are no longer relevant since the discussion on lava got moved when they changed the site over. Since the issue is still outstanding, I figured I'd repost the message and instructions here to reproduce the problem to keep everything clear.

An up to date file containing the class and examples is attached to this post.

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?

[MichaelAivaliotis]

The original LAVA thread is located here:

http://lavag.org/topic/9780-dynamic-dispatched-vis-staying-in-run-mode/ 

[kegghead]

It appears the issue has been resolved as of LabVIEW 2009, I can no longer reproduce the behavior on a Vista PC.