Smarter (or correct) EVENT_VAL_CHANGED

[Wolfgang]

Hello,

I just discovered a strange and unexpected behavior of EVENT_VAL_CHANGED which requires that I will have to double check all my previous software written in CVI...

For some reason I have assumed that if the EVENT_VAL_CHANGED is triggered on a numeric control the new value will be different from the old one. This may not be true - the value may be still the same!

Since for more experienced users this seems to be a well-known fact I doubt that NI will call it a bug, hence I am suggesting an improved behavior : Please, for numeric controls, fire the EVENT_VAL_CHANGED event only if the numeric value has changed...

(Right now, if the numeric control displays 1.0000 and I enter '1 ENTER' the value remains the same (at least), but the EVENT_VAL_CHANGED event is triggered...)

Thanks

PS: Also the documentation seems to be misleading: It (in CVI2010) states:

The EVENT_VAL_CHANGED event is generated continuously while the user is performing an ongoing action which results in the value of a control changing.

[LuisG]

This behavior cannot be changed without breaking backwards compatibility of the CVI run-time.

[Wolfgang]

Hi Luis,

Sometimes I am surprised that NI is fixing bugs because removing a bug always affects backward compatibility... And while your answer does not come as a complete surprise I am surprised that you didn't consider obvious alternatives:

Why do you decline the possibility to provide a new, 'related' event which may be called EVENT_VAL_MODIFIED or something similar?

[Wolfgang]

OK Luis,

here is a compromise proposal: Why don't you call the 'filtered' EVENT_VAL_CHANGED in good NI tradition EVENT_VAL_CHANGED_EX...? This would be ok for me What do you think?

[Wolfgang]

I don't want to to attack on windmills, but for me this is much more than a cosmetic issue:

- EVENT_VAL_CHANGED is the most common or second most common event type in all my GUI related software

- to live up to its promise each event has to be complemented by several lines of code, such as:

old_value = user_value;

GetCtrlVal ( panel_handle, control_id, &user_value );

if ( old_value <> user_value )

{

}

Replacing EVENT_VAL_CHANGED by a new EVENT_VAL_CHANGED_EX should render these changes unnecessary

[LuisG]

Yes, EVENT_VAL_CHANGED_EX would be a possibility (although note that no _EX events exist just yet ).

However, implementing such as event would be fairly involved, and we'd only consider this if support for this idea took off.

Just to give you a quick example of the complexity: imagine a table control, onto which the user pastes a block of new cell values. Currently, the event is sent because one or more of the cells might have changed, as a result of the paste operation. But, if we had the stricter interpretation that you're asking for, what if some cell values change, and others don't? This is why I think it's far preferable for you to not assume that the value is changed, when this event is sent. The way to interpret this event is that it is sent when the user does something that might change the value (and I concede that the help could be improved to make this point more explicitly).

[Wolfgang]

Hi Luis,

this sounds (a bit) better Unfortunately, so far it appears that this event does not take off at all - so may be you should withdraw your 'declined' status, otherwise nobody ever will support this idea...

If a table receives an EVENT_VAL_CHANGED_EX event I would think that at least one cell has a a new value.