Unexpected behavior with multiple event structures handling the same event.

[lab4_nl]

Hi, does anyone have an explanation of the following behavior?

After "Boolean 2" is enabled then disabled the program "freezes". You can still abort the program but nothing else is responding.
Such as pressing one of the File, Edit, View, Project, Operate, Tools, Windows, Help, or any other object inside the VI.

This happens if I have two event structures that want to handle the same event, even though the flat sequence should only let one of them run.

[James.M · Accepted solution]

This is not a bug.

Event structures should only be used to handle separate events. Since you've registered your boolean event in both event structures, the event gets queued to both when it occurs. This means one or the other will be waiting to handle the event and will by default lock the application. In scale-able LabVIEW architectures, usually there is a single event structure that handles all events and then sends messages off to the rest of the application to handle these events.

There is a "Lock panel" checkbox in the event dialog box that is by default turned on, but you should leave this on because it leads to bad practices otherwise.

[RavensFan]

You probably have the events set to lock the front panel until the event case completes.  The first event structure will never complete after the first time it captures an event, because it is no longer in the path of execution.

Caveats and Recommendations when Using Events in LabVIEW - LabVIEW 2015 Help

[Ben]

---

@James.M wrote:

This is not a bug.

...

There is a "Lock panel" checkbox in the event dialog box that is by default turned on, but you should leave this on because it leads to bad practices otherwise.

---

As one that breaks to rules just to find out "what that red button really does" can you enlighten me as to what those bad practices may be?

Curious,

Ben

[James.M]

---

@Ben wrote:

As one that breaks to rules just to find out "what that red button really does" can you enlighten me as to what those bad practices may be?

---

I guess I've inherited too much code where the developer unchecked that box and started throwing event structures all over the place. They would end up handling the same event in multiple places and ignoring the event based on the status of another part of the code. It was a lot of duplication and hard to track down bugs. A central UI handling structure is much easier to debug.

Edit: Thinking back, I may have seen an instance where they knew that one of the event structures probably wasn't going to be able to catch the event fast enough, so they just ignored events that occured more than 1sec in the past. The first structure to catch it obviously had to be the one that mattered right then, so that one would get to handle it.

There's also a reason it's checked by default, I think. But that's just speculating that NI had foresight.

[natasftw · Accepted solution]

https://zone.ni.com/reference/en-XX/help/371361J-01/lvhowto/caveatsrecmndtnsevnts/

Ensure that Event structures can handle events whenever users can generate events. 

Creating a structure to prevent one event structure from handling the event at any given time breaks this.

Avoid placing two Event structures in one loop.

This one should be obvious

Think about how an event structure works.  Wouldn't it be a tad useless if it could only queue up events while it was waiting to execute?  Imagine if you hit the same key twice very quickly.  You'd want both to execute, correct?  The event structure is always queueing up the events it can handle even while it doesn't have focus.  When it gets focus again, it executes.  In this case, you're queueing it up twice, once for each structure, and causing the non-focused to wait. 

[RavensFan]

My opinion, that default setting of locking the front panel is useless to me.  And it seems to cause people, especially new LabVIEW programmers who don't fully understand event structures, more problems than it solves.  Though it is kind of hard to be sure since we don't know what kind of problems people would be having if that was not the default setting.

I say it is a problem because we see quite a few messages on the forums where someone complains about their VI locking up.  Every few weeks I see another post where the "Caveats" link needs to be posted for someone.

I think in this situation, having the lock setting be off by default would have prevented this unwanted lockup.  But perhaps in the long term would have caused other problems.) Or maybe the user/programmer would never see it.  After the first event structure executes, it would still be sitting there actively queueing up events, but has no means of servicing those events.  It would then become a basic memory leak.

[lab4_nl]

Thank you for all the great answers! This explains all the unexpected behavior I experienced.
I assumed that the program started to listen to events when the event structure was activated, not queuing the events from anywhere in the program.