Event Blocks UI

[tobyscott]

So I found some strange event behaviour, I figured out I can fix it by unchecking lock UI in the event handler but I'm curious as to why this happens.

To get the UI to lock I hit connect followed by Master Stop. Even though the first event has already occurred and should only execute once the UI still locks up.

If I hit connect then start the program executes properly.

Any ideas as to what is going on here?

[JÞB]

---

@tobyscott wrote:

So I found some strange event behaviour, I figured out I can fix it by unchecking lock UI in the event handler but I'm curious as to why this happens.

To get the UI to lock I hit connect followed by Master Stop. Even though the first event has already occurred and should only execute once the UI still locks up.

If I hit connect then start the program executes properly.

Any ideas as to what is going on here?

---

Yes, You have multiple events on one BD that can only execute once but are regestered for multiple events.  DON'T do that.  you'll lock up your FP waiting to process events that can't be processed

[crossrulz]

Because, even though the event structure is not being called, it is still technically doing stuff.  If you have the Lock UI, it does just that.  It doesn't matter if the event case is currently sleeping waiting for an event.  It sees an event and locks the front panel.

In general, it is a really bad idea to have multiple event structures in a single VI.  This is one of those major reasons.  What you should do here is put that event structure in a while loop and make a case for each of your buttons.  You can supply whatever logic you need to tell the loop to stop.  Shift Registers will help here.

[tobyscott]

So is there a way to stop them being registered for multiple events? I only want these wevents to occur once. I thought that was what an event structure did, just run one event then move on.

[crossrulz]

---

@tobyscott wrote:

So is there a way to stop them being registered for multiple events? I only want these wevents to occur once. I thought that was what an event structure did, just run one event then move on.

---

The way a lot of my systems like this are set up is I use a loop that does nothing but GUI.  It is a While Loop with an Event Structure inside of it.  That Event Structure takes care of all user button presses, value changes, etc.  I then have other loops that do the actual work of the program.  I use Queues to send the commands from the GUI loop to the other loops, telling them to go into certain states or do whatever.

Do a search for Queued Message Handler.  There are a few good examples floating around that show what this should look like.

[JÞB]

---

@tobyscott wrote:

So is there a way to stop them being registered for multiple events? I only want these wevents to occur once. I thought that was what an event structure did, just run one event then move on.

---

Taking a second look.  (No 2014 on this machine so all i can see is whats inline) you really need to read the Caveats and Recommendations when Using Events in LabVIEW

I also bet that at least one of those booleans is a "Latcher"  Those have to be placed inside the event that handles them so the "Latch" can complete.

[Dennis_Knutson]

I don't see a while loop in the snippet. You aren't using the run continuous button are you? That's another no-no.

[tobyscott]

Not using the run continously and no the mechanical action is just switch when pressed.

I understand the normal way you would use a while loop with one event structure inside to handle all UI events, that way you follow the order of commands that the user inputs and also can store events if the user is inputing them faster than you can handle.

I also read the caveats and although it says not to use event structures outside while loops it doesnt say why, I guess because it will continuously store events even though the structure will never get to execute again.

Basically I just wanted a simple step through structure where the user can't get ahead of themselves but I need to wait for the user to be ready (afterwards I have a state machine). Thats why I had the event structures connected one after the other. But maybe it will be better to implement it in a different way.

[JarleEkanger]

So you want the user to do some tasks in a certain order before the state machine executes? I suggest you put all the events in a single event structure within a while loop, but implement some filtering of the events. I.e:

When the user hits the first "correct" button, raise a boolean flag indicating that stage is OK. That boolean flag can now be used as a check if the user clicks the other button. If a button is clicked out of order, "discard" the action (and maybe pop-up a dialog explaining that this is the wrong order of operations). Always allow the stop button. Then iniate the state machine once the final initialization action has been made by the user.

[dkfire]

You could also disable all the buttons that the user is not allowed to click on.

I do that a lot of times. Depending on what state the state mashine is in, only valid buttons are active for the user to select.