remove unhandled events

[SMcS12]

Hi,

I'm using an event structure within a subVI. I have a boolean that when pressed on the front panel, it closes the subVI. However, I've noticed that if I try to click this boolean mulltiple times, the next time I enter this subVI the unhandled events from the previous call begin to execute. I have attached this subVI for reference (Event structure 1.vi). If the VI called 'run 2 event structures.vi' is run and you do mulitple clicks on the 'Event structure 1.vi', you should be able to replicate the behaviour. 

Thanks,

LMS

[SMcS12]

If there was a way to remove unhandled events at the end of the subVI, this would solve the issue. Is this a function that can be implemented?

[Yamaeda]

If you use Register and Unregister for events, it'll only react to events in between those two VI's.

/Y

[billko]

Perhaps the better way to handle this is to prevent the user from clicking multiple times.  It's far easier to prevent unwanted behavior than to deal with it.

(Hide or disable said button when not needed.)

[crossrulz · Accepted solution]

My question is what your VI is doing for 2 seconds after the user presses the button?  There are a few options, depending on exactly what you need to display for the GUI.

1. Change the cursor to the "busy" so that a) the user knows the program is doing something and b) the user cannot keep pressing the button

2. Close the front panel as soon as that button is pressed and do your clean up with no display.  The user doesn't get a status about what you are doing, but at least they can't keep pressing that button.

[altenbach]

A few questions:

• Why do you have a timeout case that never executes?
• Why is the mechanical action of the booleans "switch until released"?
• Why are you using mouse down events instead of "value changed" events (together with latch action booleans)". If you would use latch action booleans, you could place the terminal in a sequence frame after the 2s wait, so in won't pop back up until the VI ends. Then you could also limit the event queue to 1 entry. Maybe that would improve things.

Obviously, you have simplified the VI to demonstrate the problem, but you have simplified it too much, because once the calling VI completes, all events possibly queued up in the subVIs are discarded.

Please explain the purpose of  the subVIs and what they are doing. What else do they do in the full program version? How is the program supposed to function from the user perspective? It is often better to describe what you are trying to do, not how you are trying to do it.  There are probably much better solutions.

[SMcS12]

Hi,

Thanks for the response. Setting the cursor busy solves my issue.

In the application, the user will go through a number of setup screens where they set parameters up and then come back to a home screen. They can then choose to go through the setup screens again at this point. Therefore the main calling VI is always open and the events are always queued. Setting the cursor to busy does stop the user from clciking the button multiple times which exactly the behaviour I wanted to stop.

The VIs attached above were indeed drawn up to demonstrate the issue I was seeing on a much larger application. Some answers to the questions posed above:

The 2 second delay was there to allow time to click the button multiple times which was casuing a very rare issue in the application, induced by the user incessently clicking a save & exit button.

I have code within the timeout case in my application but should have removed it for the demonstration VIs

I use mouse down events so the button defaults back to its original position when clicked upon. A value change would create two events if not handled for properly in this instance.

Thanks,

LMS

[billko]

---

@SMcS12 wrote:

Hi,

Thanks for the response. Setting the cursor busy solves my issue.

In the application, the user will go through a number of setup screens where they set parameters up and then come back to a home screen. They can then choose to go through the setup screens again at this point. Therefore the main calling VI is always open and the events are always queued. Setting the cursor to busy does stop the user from clciking the button multiple times which exactly the behaviour I wanted to stop.

The VIs attached above were indeed drawn up to demonstrate the issue I was seeing on a much larger application. Some answers to the questions posed above:

The 2 second delay was there to allow time to click the button multiple times which was casuing a very rare issue in the application, induced by the user incessently clicking a save & exit button.

I have code within the timeout case in my application but should have removed it for the demonstration VIs

I use mouse down events so the button defaults back to its original position when clicked upon. A value change would create two events if not handled for properly in this instance.

Thanks,

LMS

---

If anything, I'd us mouse up.  This is the standard way an application behaves when a button is pressed.  In most applications, if you click on a button, hold the click and move off the button, the event is not fired.  On the surface, it seems a minor difference - but it does give you a chance to change your mind.  (Maybe you didn't want to eject the warp core after all, but went ahead and clicked 'OK' anyway.)

But I don't understand why you need this to get a button back to its original position?  As mentioned earlier in this message thread, change the mechanical action of the button and you no longer have to worry about mouse up/down events.  I always forget which mechanical action does what, but grab the OK button and plop it down on a VI - that has the correct mechanical action that you are looking for.

[crossrulz]

---

@SMcS12 wrote:

I use mouse down events so the button defaults back to its original position when clicked upon. A value change would create two events if not handled for properly in this instance.

---

Set the mechanical action to Latch When Released and put the terminal in the event case handling its event change.  The button will switch back when the terminal is read.  So when the terminal is in the event case for the value change, the button will switch back when the event is handled.  And you will only get 1 event with this setup.

[altenbach]

---

@SMcS12 wrote:

I use mouse down events so the button defaults back to its original position when clicked upon. A value change would create two events if not handled for properly in this instance.

---

Obviously, you did not real/understand my comment. A latch action boolean (typically "latch when released") will create exactly one event when the value changes (i.e. the button is pressed) and it will pop back up automatically when the terminal is read by the code without triggering another value change. If you want to have it pop up immediately when the event executes, place the terminal inside its event case. If you want it to popup later, you need to ensure that it is read only after the 2 second delay, so you could place it inside a sequence frame that executes only after the delay and it will popup as the last thing before the subVI completes. This makes it immediately clear to the operator that the button is no longer accepting inputs. You could even change the TRUE boolean text to "please wait..." for example.