Jump to content

Dynamic Dispatched VIs staying in run mode


Recommended Posts

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:

post-11742-1238073894.png?width=400

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

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.