Avoid duplicated button clicks in event structure

[vpicco]

Hello,

I have a seemingly easy problem that I can't seem to solve. I am attaching a VI that exemplifies my issue.

My problem is this: when an event is running the OK button is disabled, but if the user clicks on it the event is queued and, when the current process is finished, another one will start right away. The only reason why I disable the button is to avoid this event queuing. The mechanical action of the button is set to Switch until release (so that the button comes right up after I let go of it).

How can I avoid this?

Thanks!

[RavensFan · Accepted solution]

First, your mechanical action seems wrong.  Use Latch when Released and move the button inside the event case.  Right now you are using Switch until Released which is catching actions on the up and down motions.

Second, don't check the box that says "Lock Front Panel until the case for this Event completes".  Notice it has parentheses that say "defer processing of user actions" which means it waits until the case completes (at which time the button has been re-enabled).  You are basically defeating the whole purpose of disabling the control because you deferring the user interaction until the button has been re-enabled.

[vpicco]

Hi RavensFan,

Thank you. You actually answered another long time question which, as a self-trained LabVIEW user I did not know. I have always used button with that mechanical action to make them come automatically back to their initial position. I understand that is not the right way of doing it. It's pretty interesting that by placing the button inside the case event the button is "reset". OT: is the trick I use to concatenate a string to itself using variables "bad"?

Also, I had thought about unchecking that box, but I didn't do it because I thought that if action queuing was enabled with the panel locked, it would have also been active with the panel being active.

Anyway, I made the changes you suggested and everything seems to work. Thanks a lot!

[crossrulz]

First of all, your button should be set to the default of Latch When Released.  Then put the terminal for the button inside of its Value Change event case.

You are actually causing two value change events with the switch until release: 1) true when you press the button, 2) false when you release the button.  By using the latch, then you will only have one change event.

Also, interestingly enough, I found that if you turn off the "Lock front panel" option in the event case setup dialog, then your issue goes away.

You should also make a way to stop your loop.  Using the Abort is a big no no.

Attached is a cleaned up version of your code that I put together.

EDIT:  Ok, I must have taken way too long to play around with this VI...

[RavensFan]

Yes, the latching action means that the button will pop back up automatically (and not be seen as a value change event) whenever it is "read", which means the terminal is within the line of execution of the LabVIEW code.

I was also somewhat surprised that the front panel was registering clicks even thought the control was disabled, and the front panel was "locked".  I always thought that the front panel being locked meant you couldn't do anything else on the front panel, but that theory is contradicted by the note that the front panel lock "defers user actions".

Honestly, I never use Lock front panel and find it annoying that it is the default which is why I voted for Default setting for Event Structure shouldn't be to Lock Front Panel which surprises me that only one other person (plus the original poster) thought it was a good idea.  I find that "locking" the front panel setting is just a bad method to cover up for poor UI design by the programmer when they don't make good architecture decisions to allow for a responsive user interface.  There are way too many messages on the boards about people complaining their code locked up because they used this setting when the code was designed improperly, than people who claimed their code was behaving inaccurately when they did not lock the front panel.

I remember seeing a post years ago that got into the deeper quirks of the "lock front panel" setting, but I don't know if I could find it now.

Anyone who uses event structures should also read Caveats and Recommendations when Using Events in LabVIEW - LabVIEW 2013 Help, but I feel that this article leaves out a few critical points about using the event structure and needs updating.

[vpicco]

Hi crossruiz,

Your solution is almost the exact same as RavensFan's, so I hope you don't mind if he gets "solution" status 🙂 Also, my actual VI is much more complex than this example and does have a dedicated EXIT button which terminates the while loop.

Thank you for the helpful suggestion!

[vpicco]

Hi RavensFan,

---

@RavensFan wrote:

Honestly, I never use Lock front panel and find it annoying that it is the default which is why I voted for Default setting for Event Structure shouldn't be to Lock Front Panel which surprises me that only one other person (plus the original poster) thought it was a good idea.  I find that "locking" the front panel setting is just a bad method to cover up for poor UI design by the programmer when they don't make good architecture decisions to allow for a responsive user interface.  There are way too many messages on the boards about people complaining their code locked up because they used this setting when the code was designed improperly, than people who claimed their code was behaving inaccurately when they did not lock the front panel.

---

Out of ignorance I used to always uncheck that box, because I was wondering why would one lock the front panel. Then. out of ignorance again, I did not notice big differences in the programs I made, so I stopped touching it. The moral of the story is that ignorance is an ugly beast!

[billko]

It's funny that I never bothered even looking at the "Lock Front Panel..." property.  I guess I never noticed issues because I hardly ever have any kind of code worth mentioning in the event structure.