Limit Maximum instances of this event in event queue, does not seem to limit multiple button presses to one single event

[RTSLVU]

How is this suppose to work? If I check the box "Limit Maximum instances of this event in event queue" and set the limit to 1,

I would expect that if someone were to press a button more than once before the program can react to the button press event and run the VI in that event case, it would not rack up a ton of button presses waiting to be acted upon, but almost every time I press this button it racks up two or more button value change events. I can tell because the VI this event run pops up a window, and when I close it it will instantly pop-up another one until all the events are cleared. 

But this does not seem to be the case.

How can I stop multiple presses from racking up multiple events?

In other words how can I debounce this onscreen button?

[Kyle97330]

If you switch your architecture to a producer-consumer setup and not just an event case, then you get two methods for dealing with this.  (This assumes that you have an event structure in a loop that does nothing but enqueue commands to another loop that uses a dequeuer to run them one by one.)

Your first option would be that as soon as the button is pressed, you use a property node to disable the button so clicking it again is impossible until the consumer case finishes and as its last action, enables the button.

The other option is queue inspection or editing.  You can use the queue nodes to look at the queue and either refuse to enqueue a duplicate press in the first place if there's already a press in the queue, or you can set it up so that any time the dequeuer gets the case you don't want to run twice it flushes the queue, drops the duplicate(s), then requeues the rest in the same order.

[Kyle97330]

You can also switch to using dynamic event registration, then delete and recreate the registration for that button.  That will clear anything pending.

Example:

[BertMcMahan]

Paul, could you post your code or create a minimum viable reproduction? I whipped something up and limited the number of events, and it works the way you'd expect.

(Snippet is v2020, attached in v2016)

Click Run, then click "Boolean" a bunch in the first 2 seconds. Numeric will only increment once.

Click it a bunch more after that, and it'll only update once per 500 ms. I can't reproduce what you're seeing, so I can't help but wonder if there's something else going on.

[Intaris]

---

@BertMcMahan wrote:

Paul, could you post your code or create a minimum viable reproduction? I whipped something up and limited the number of events, and it works the way you'd expect.

(Snippet is v2020, attached in v2016)

Click Run, then click "Boolean" a bunch in the first 2 seconds. Numeric will only increment once.

Click it a bunch more after that, and it'll only update once per 500 ms. I can't reproduce what you're seeing, so I can't help but wonder if there's something else going on.

---

But it should stay at zero if it only executes once. The shift register is initialised with "0", and the increment is only active on the second event fired. Does your text not suggest it is indeed executed twice?

[BertMcMahan]

---

@Intaris wrote:

---

---

But it should stay at zero if it only executes once. The shift register is initialised with "0", and the increment is only active on the second event fired. Does your text not suggest it is indeed executed twice?

---

You are correct, I was in a hurry last night. Pushing it a bunch in the first 2 seconds will actually result in Numeric updating once, not incrementing once.

Click Boolean a whole bunch in 2 seconds, and Numeric will stay at 0. If you manually change the indicator to something nonzero, then click Run, click Boolean a bunch within 2 seconds, then it'll update it to 0.

[Gregory]

I like Kyle's idea for preventing the pop-up from happening twice. 

As far as the "limit instances of this event..." option, it looks like the events actually get enqueued, and then when the event structure can handle them it will handle the most recent one and flush the rest.