Provide a Value Change? (Filter) event

[GregSands]

In the same way that mouse clicks, key presses etc can be filtered or modified before being accepted, having a Value Change? event option would allow tighter control over input data than possible using the Data Entry tab, and without needing to wire to a Value property node or local variable as AQ suggests here.

While this idea in itself probably doesn't make much difference, it would be very useful if such an event could be "bound" to a .ctl (a sort-of mini-XControl) in an enhanced version of what the Data Entry tab currently does.

[AristosQueue (NI)]

"Value Change?" was explicitly discussed when the Event Structure was created and decided against. I do not recall the reasons. I'll see if anyone remembers. I'm guessing that the answer is that it didn't add anything more than you get with Value Changed and then setting the control value as needed. Often you don't want to go back to the old value but instead coerce to some new value.

[Intaris]

Regarding "binding" an Event, you can do this with the "Callback VI" registration node (I believe it's under the ActiveX palette but it works fine for LV Events too).

I too have on occasion wished to have a "Value Change?" filter event.

[GregSands]

I do know about Callback VIs, though haven't used them much.  But I was thinking more along the lines of being integrated into a .ctl file, so that when you drop the Control on the FP, the associated event handling (or callbacks) comes along for free.  Very much like an XControl, but without the baggage.  Or maybe it wouldn't work without that baggage, and we just need to wait for the XControl/XNode rewrite....

[Intaris]

Just thought I'd mention it in case you were sitting on a use case you'd like to solve.....

[ghighuphu]

text deleted. wrong thread. I'd like it to delete the message, but not possible.

[chris_d754]

A good use case for this, is when you have unsaved data, and a change in value would delete the data,. With value change? you could popo-up a window asking if a you want ot save the data first, if so, cancel value change otherwise allow value change.

[crossrulz]

You can still do that now.  You just write the old value into the terminal to "discard" the value change.

[AristosQueue (NI)]

chris_d754: As crossrulz says, this is already possible. The old value is included in the event refnum information in the left side event data node in the event frame.

[Intaris]

How does this version work if multiple pieces of code have registered for the Value Change event on the control?

[AristosQueue (NI)]

> How does this version work if multiple pieces of code have

> registered for the Value Change event on the control?

You would have only one listener watching for the Value Change on the UI control. You would need to have the others watching for a separate event for "Commited Value Change" or something like that (it can be a User Event but it is often easier to make it a hidden control so you can statically register for it and set the value of using Value Signaling). The main watcher would fire the secondary event after it approved the value change. Having that two-stage model for value changes is generally helpful anyway since it means that your multiple watchers are watching for a non-UI element, making it easier to change your UI without having to update many listeners.