LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
GregSands

Provide a Value Change? (Filter) event

Status: New

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.

13 Comments
Mads
Active Participant

One of the best use cases for a value change filter event is when you want to force the format of a string. Unless we get this idea for input masks instead, the only way to implement this properly with a string control (without making it look bad by first accepting (displaying it as entered) the input), would be by using such a filter event.

BertMcMahan
Active Participant

Throwing one more reason this is better than the "just write to the terminal" trick- if your input validation takes more than a few milliseconds, the bad input value can flicker before the coerced value takes over. It makes the GUI feel a little glitchy. This is mainly for programmatic updates of a value, for example, the file path control. If the user selects a file and you want to build a relative path to that file (and change the control accordingly), the selected path flickers in the control before the event case can change it to a relative path. Of course you can get around this with manually creating the Browse functionality, but it'd be nice to have it baked in.

wiebe@CARYA
Knight of NI

Also, if you have multiple value change events registered, they'd all get the event.

 

For instance, you could have some callback event VIs doing the filtering, and have your main VI use the value when it changes. Perhaps a dynamic VI doing an audit trail as well.

 

As it is, all events return the original change as 'new' value (so you'd have to use a property node or local).

 

Ideally, if the filter doesn't allow the change, I don't want to get the event in my main or audit trail.