Why "Limit maximum instances of this event in event queue" in the Edit Events Dialog Box?

[Agile]

Why would I "Limit maximum instances of this event in event queue" in the Edit Events Dialog Box?

I think this is new to LV 2014, but I couldn't find any explaination of a good instance to use this . A search on NI shows only the 2014 Help text, which explains what it does, but not why?

Does anyone know of a good case to use this option?

Thanks in advance.

Justin Tyme

[Gregory · Accepted solution]

It's useful for UI elements that can enqueue actions faster than they can be carried out.

For instance, say it takes takes 1 second to take a picture and save it. The user presses the "Take Picture" button but they don't see a new picture file yet after waiting 250ms (humans can be impatient) so they press it a couple more times. Finally they see a new picture file... and then another... and then another... To get rid of this possibility, check that box.

Or say you have a slider to adjust some parameter. The act of moving the slider updates it very fast! If the user slides from 0 to 1 then the program might try to send everything in between as a setting to your instrument, which takes some amount of time. Instead of sending all those values, it is probably better if the program can keep up up with the slider and send a value of 1 approximately at the same time the slider says 1. If you don't check that box, the user might be at 1 but the instrument is still receiving values of 0.53, 0.54, 0.55...

[Agile]

Humans are impatient at 250 ms?

Man, if an elevator takes longer than 10ms to get to MY floor, I'm banging on that call button like I'm giving CPR to a fruit fly. The elvator gets there faster. True Fact.

Seriously though, thank you. Your illustration explains it.

[Gregory]

No problem, I got that idea from a blog post by Mike Porter, but he actually says 200ms in regards to getting a splash screen up so they know the program is initializing. 

[natasftw]

For your slider example, I want to make sure I'm understanding how the slider works without going and creating a test case.

I see one of two things happening here:  the slider doesn't update until you release the mouse (similar to the way you don't update a numeric until you click away) or the slider updates at each point along the slide.

If the first is true, it'd only queue the single event at your final event and you'd never run into an issue where it's still handling all of the events in between unless you opted to make it hit each of those before sliding further.

In the second, you'd want this behavior even less.  If I slide to 1 and it's processing events at 0.53/etc, the first event it'd fire off isn't 1.  If we limit to a single event, it's quite possible it'd never trigger for the value I actually changed to.

Is this really how sliders work?

[Gregory]

---

@natasftw wrote:

In the second, you'd want this behavior even less.  If I slide to 1 and it's processing events at 0.53/etc, the first event it'd fire off isn't 1.  If we limit to a single event, it's quite possible it'd never trigger for the value I actually changed to.

---

I think this is closer to how they work. If you have the event structure firing on a "new value" it will fire every time the value changes, even if you don't lift the mouse. If you are dragging the slider it will fire values during the slide. If you simply click somewhere on the slider to change the position, it should only fire once. I see your point that it might not be able to fire the final value you set it to after a drag, but for some reason... it does. Here is an example that has "lock front panel" selected, and I think the behavior with "limit max instances" is much more desirable.

[crossrulz]

---

natasftw wrote: If we limit to a single event, it's quite possible it'd never trigger for the value I actually changed to.

---

You are thinking the wrong way with which events get discarded.  The oldest value change of the slider (ie, the next one to be handled) is what gets thrown out, not the newest.  Therefore you will always get the last value you set.

[Gregory]

Excellent, thank you for the clarification

[altenbach]

Have a look at this idea for the reason we have this checkbox.

Also follow the various links (e.g. this one) for illustrative old examples.

[Hooovahh]

I also use this for window resizing.  Lets say if my window resizes then I need to recalculate the position of some things on the UI or maybe adjust column width of a table or something.  This may take on the order of a few ms to complete, but if I resize a window an event will be generated for every pixel that the window moves, so dragging and making the window larger may generate 100s of events.  The old method would have me resize and recalculate my UI elements 100s of times.  With this option I can throw away all the old events and just resize for the last one generated.

The work around before this existed would be to use the timeout event and set it to 0 if a resize was happening.  In the resize event all we would do is set a variable (boolean in a shift register) and then when timeout of 0 happened we would resize the UI elements, then we would clear the boolean.  It was more work, and didn't always work as well so I'm very glad to have this feature for UI resizing, and sliders.