Re : Re: Slider control generates too many "value change" events

[altenbach]

Oh, and read the entire thread mentioned in my reply above, for example you should make sure that "lock front panel" is unchecked in the event configuration. Of course only the upper while loop in the example code is needed in a typical application, the rest is just trimmings to show the behaviors.

[chilly_charly]

---

tst a écrit:

Two additional options:

1. Compare the NewVal terminal to the control terminal and only perform your action if they are equal. This works because the control terminal holds the current value.
2. Use the Value Change event to feed a short timeout value (e.g. 100 ms) into a shift register and wire the SR into the event structure's timeout terminal. In the timeout event, output -1 into the SR. As long as the VC event occurs, the timeout event will not. When the VC stops, the timeout event will occur and you can place your code there. This also works for other continuous events like Mouse Move or Panel Resize. 

---

Funny, there was a similar problem, at the same time in this thread ! 😄

[altenbach]

---

tst wrote:
Compare the NewVal terminal to the control terminal and only perform your action if they are equal. This works because the control terminal holds the current value.

---

Ah, I mssed the reply by tst. Still, the link to my old thread is probably useful. 😉 

---

tst wrote: 

Use the Value Change event to feed a short timeout value (e.g. 100 ms) into a shift register and wire the SR into the event structure's timeout terminal. In the timeout event, output -1 into the SR. As long as the VC event occurs, the timeout event will not. When the VC stops, the timeout event will occur and you can place your code there. This also works for other continuous events like Mouse Move or Panel Resize. 

---

I actually use this more and more, because the "equal" trick does not work for an event case tied to multiple trigger flavors (slide changed or cursor moved, for example.)

I place the bulk of the common recalculate code in the timeout case and then make seperate, nearly empty event cases, for example one for "slide changed" and "one for "cursor moved". In the slide changed" case I do the equal trick and set the timeout to zero if it matches. In the "cursor moved" event, I similarly compare the new coordinates from the event terminal with the cursor position from a property node tied to the active cursor as obtained by the event terminal. All values are kept in shift registers. And so on.... Works pretty well. 🙂

[Eugen_Graf]

If you ajust the increment property of the control, you will get less value change events.

[TCPlomp]

---

LabVU_Dog wrote:

Hi Ton,

I think I may be stuck using something like your technique with notifier. I'm using a QDSM architecture, so it should work. It just seems like a clunky work-around.

Also - with regard to "If you decide to ignore that you will have quite some strange faces.", I was trying to allow the user to control the slider as long as they are over the slider. Once they move off the slider, I force them to relinquish control (last value remains). This seems like it would be reasonable behavior.

Thanks!

---

If you use a QDSM (Queue Driven State Machine) it even gets easier, in the notifier loop you can send a 'Value Change' queue event every xx ms.

The problem is that what you want is not standard OS slider behaviour and NI has tried it's best to implement standard OS behaviour into everything.

Ton