Event structure locks FP if loaded in a subpanel but stopped?

[1984]

Hello Community,

I'm wondering if there is a logical explanation for the following behavior:

My Main VI has a button to change a counter and a subpanel displaying another VI (test). The test VI has a button to change a different counter inside itself and also a stop button Both VIs use a separate event structure to handle the button presses, of course each VI handles its own buttons only. When I start my main VI it also starts the Test VI in the subpanel so I can change both counters with the buttons.

Now comes the problem: if I stop the VI in the test VI by pressing its stop button then it finishes the execution, but if I press its counter button (note the VI finished already) then it locks my front panel and from that point my main VI front panel does not respond anymore.

So a VI which is not running can somehow still register events. Interesting, but more to come. If I uncheck the "lock panel" checkbox for the events in the test vi and keep pressing the counter button in my stopped test vi and then restart the test VI in the subpanel then the counter value changes.

This may sound confusing, but I have attached a project. Steps to reproduce:

1. Open the main VI (make sure the test VI is not open, otherwise an error occurs)
2. Run the main VI
3. Press the counter button in the Subpanel couple times and note the value
4. Press the counter in the main VI just to see that it works
5. Press the stop button in the subpanel. The LED stops blinking
6. Press the counter in the main VI just to see that it still works
7. Keep pressing the button in the subpanel couple times
8. Press the stop button in the main VI

Tada! The VI in the subpanel restarts and the counter will have a higher value than it has before. The VI in the subpanel was not running but the event structure still registered the clicks and when the VI restarted the events were fired.

If you open the test VI and check the "Lock panel" option in the event properties then everything locks at step (6).

I'm not sure if this is a bug or a feature, but certainly looks a very odd behavior. I hope my explanation was clear enough, let me know your thoughts. The project was written in LV2015.

thx.

[1984]

EDIT: "subpanel restarts and the counter will have a higher value"

Not necessarily higher. For example: If in step (3) you pressed the button 10 times and then in step (7) pressed it 5 times then once the test vi restarts the counter will be at 5.

The key point remains the same: the events for the not running VI are still getting registered and fired once the test VI restarted.

[Ben]

I am not going to venture a guess if this is a bug or a feature but maybe offer an alternative...

Using Dynamic event registration you can turn on and off events. SO if the VI in the sub-panel uses dynamic event registration when it starts and then closes same when it finishes...

For what its worth,

Ben

[1984]

Gosh! But this means that:

1. God knows how many VI-s need to be rewritten

2. All future VIs which have even a remote possibility being loaded into a subpanel need to be done in a way which is a lot less common / natural

3. Even one mistake could potentially lock the FP forever

If I consider these I'm rather leaning towards thinking that this is a bug...

[BertMcMahan]

I can confirm this still happens as of LV2018. I will agree with you this behavior is a bit unexpected- I think the more general description for this specific issue is that statically registered events are still registered even if the VI isn't running. I think the VI is in the "waiting to run" state, which (apparently, and confusingly) still gathers events. I couldn't find documentation of this anywhere in the brief search I did. It looks like, since the VI is still in memory, it's still getting those dynamic events.

Here's some further discussion- I think the last post is particularly helpful:

https://lavag.org/topic/19355-when-are-events-queuedregistered/

One suggestion, in my experience, loading VI's into subpanels is incredibly useful, BUT I have always (I think) designed them to be a part of a larger application. I don't think I've ever actually run a totally independent VI from inside a subpanel. That's not to say there's no reason for that, of course, but I think it's better practice to write them specifically to be run as an item in a subpanel.

I can't think of a time when this behavior would be useful, it's very unexpected, and it's not documented, so I think I'd flag it as a bug myself as well. If it was at least documented *when* static registration starts and ends it would go a long way into explaining this unexpected behavior.

[Mancho00]

Perhaps I'm missing something, but why would you want a VI visible in a subpanel if it is no longer running?  Why not invoke the Remove VI method?

[1984]

I can imagine plenty of scenarios when one may want to keep a finished VI in a subpanel. I would rather not start discussing this because then we will end up debating if a certain thing can be done in a different way and that just derails the conversation.

I guess the point here is that LabVIEW supports the idea of keeping a finished VI in a subpanel, but once I'm doing it LV starts behaving in a very unexpected way.

[drjdpowell]

LabVIEW's subVI execution system is designed to work with subVIs that execute in under a microsecond and can be called hundreds of thousands of times a second.  So it can't follow the most intuitively obvious mental model that we have of a subVI call simply "running" and "finishing", because of all the start/stop overhead.  Instead, all subVIs start "running" when their top-level VI does, and subVI calls just execute the code itself.  

Static event queues are a significant overhead, and are done when a subVI starts running (actual running, not the calling that we call "running").  We tend to use Event structures in long-executing subVIs where this behaviour is problematic, but one can use them in fast-executing subVIs called periodically in a loop.  Xcontrols, for example, work this way, and I have used used such techniques.

[Mancho00]

---

@drjdpowell wrote:

Static event queues are a significant overhead, and are done when a subVI starts running (actual running, not the calling that we call "running")....

---

This makes sense.  If I can do this:

This demonstrates that the static queue exists before the code that can execute on it.  I don't think it's entirely unexpected to see that a subVI will maintain its queue, regardless of whether its "running", particularly in a subpanel where its state would need to be maintained.

[1984]

I see the behavior can be explained (or at least guessed) based on how the event structure works. Still, from the perspective of regular programmer - while the behavior can be explained - it still doesn't sound logical.

Thanks for all the valuable thoughts.