10-19-2015 06:14 AM
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
Solved! Go to Solution.
10-19-2015 06:26 AM
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?
10-19-2015 06:35 AM
If you use Register and Unregister for events, it'll only react to events in between those two VI's.
/Y
10-19-2015 11:38 AM - edited 10-19-2015 11:41 AM
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.)
10-19-2015 08:26 PM
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.
10-20-2015 01:58 AM - edited 10-20-2015 02:00 AM
A few questions:
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.
10-23-2015 07:31 AM
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
10-23-2015 08:45 AM
@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.
10-23-2015 08:59 AM
@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.
10-23-2015 09:44 AM
@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.