Reint to Default menu action triggers unnecessary ValChanged events

[David Boyd]

If I invoke Edit->Reinitialize Values to Default on the runtime menu of a running VI, every control which has a Value Change event registered fires an event, even if no actual value change occurs. If I test OldVal and NewVal within the event case for equality, yep, they're equal. This is especially unwelcome when dealing with latching boolean buttons which trigger some code when the user presses them - they ALL fire when the user does the Reinit to Default.

I'm surprised I hadn't noticed this behavior before. If there's a rationale for this, could someone explain it to me?

The workaround would be to compare OldVal and NewVal and conditionalize the code within each event case.

Also behaves this way in 8.2.1.

Dave

[Aristos Queue]

QUOTE(David Boyd @ Nov 30 2007, 04:10 PM)

I'm surprised I hadn't noticed this behavior before. If there's a rationale for this, could someone explain it to me?

The workaround would be to compare OldVal and NewVal and conditionalize the code within each event case.

Also behaves this way in 8.2.1.

Looking at the code... the rationale appears to be that LV just copies the default value over the current value for all controls without checking if the current value is the default value. So a value changed event gets fired regardless. We could slow down the process by doing a comparison on each individual control of current versus default before doing the copy, but we don't bother.

Would you want this behavior to change?

[Tomi Maila]

QUOTE(Aristos Queue @ Dec 1 2007, 12:59 AM)

Would you want this behavior to change?

I don't want this to be changed. I think this is correct behaviour. I think a value can be changed into the same value completely legally. I think value change event should be fired even when value is modified to be the same at it was previously. Does it trigger if I edit a path from C:\file and replace it with C:\file. I think value change should trigger. However if reinitialize to default values is invoked using scripting, then event should not be triggered. Is it? I don't have the time to check these out now.

[Aristos Queue]

QUOTE(Tomi Maila @ Nov 30 2007, 06:42 PM)

However if reinitialize to default values is invoked using scripting, then event should not be triggered. Is it? I don't have the time to check these out now.

There are only two built-in events that can be programmatically triggered. One is the "Value (signaling)" event. The other is App Exit. Anything else that you do programmatically does not trigger the event structure. You'd have to write your own user events for anything else that you want to be reported to the event structure.

[i2dx]

QUOTE(David Boyd @ Nov 30 2007, 11:10 PM)

I'm surprised I hadn't noticed this behavior before. If there's a rationale for this, could someone explain it to me?

I, e.g. did not notice this, because I allways turn off the default right-click and default VI menus in any application. If I need a right click menu on a control or a VI menu bar I allways use the custom menus.

[Tomi Maila]

QUOTE(i2dx @ Dec 1 2007, 01:35 PM)

I, e.g. did not notice this, because I allways turn off the default right-click and default VI menus in any application. If I need a right click menu on a control or a VI menu bar I allways use the custom menus.

Actually the name of the event should not be "Value changed" but instead "Value edited" or "Value modified" or something similar. Actually I suggest adding a new event called "Value changed" which would function as Dave suggests i.e. the value change would be actually tested before signaling the event. So having "Value edited" and "Value changed" events would suit to all possible use cases.

Tomi

[David Boyd]

QUOTE(Aristos Queue @ Nov 30 2007, 05:59 PM)

Would you want this behavior to change?

As Tomi suggested in his post, perhaps this is about semantics; the name of the event suggests something that isn't actually happening. True, an action was invoked on the control, but there's no change on the wire.

If changing the behavior would break any existing code, then of course I wouldn't push for it. But I think this subtlety calls for some sort of clarification. I certainly hadn't expected all my boolean buttons to 'fire' from a menu-invoked reint to default.

Dave

[silmaril]

QUOTE(David Boyd @ Nov 30 2007, 11:10 PM)

The workaround would be to compare OldVal and NewVal and conditionalize the code within each event case.

For the latching buttons you mentioned, it should be enough to wire NewVal to the selector of a case structure.

There is no need for an extra comparison.

You could use the button's terminal instead of the NewVal node. This would result in switching it off as soon as the event is detected. (It's you choice if you want this behaviour or not.)

[pete_dunham]

This Topic is from a ways back, but I ran into a similar issue.

I set up a Event (as an interrupt) registering a Change Detection event from a digital i/o card (discontinued pxi6533).

Each time I started the VI the event would trigger (just once). I worked through the issue with NI engineers, as they weren't expecting this behavior. It was a simple work-around ("throw away" the first event). But no one could ever come up with what caused this behavior.

[Rolf Kalbermatter]

This Topic is from a ways back, but I ran into a similar issue.

I set up a Event (as an interrupt) registering a Change Detection event from a digital i/o card (discontinued pxi6533).

Each time I started the VI the event would trigger (just once). I worked through the issue with NI engineers, as they weren't expecting this behavior. It was a simple work-around ("throw away" the first event). But no one could ever come up with what caused this behavior.

Wonder if it is an intricacy of the occurrences? At least in the beginnings all LabVIEW synchronization tools (queues, sempahores, etc) were based on occurrences and they do have a certain special behavior that they can initially trigger once, for occurrences that have been triggered by a previous execution of the code but not polled with a Wait on Occurrence.

Rolf Kalbermatter

[Val Brown]

To my mind this is correct behavior: ie a "Value Change" has occurred programmatically because the value was set (programmatically) to a value that is newly set, whether that value is the same as before. It is really the value set operation that is being tested not the value of the value. I though you "by ref" folks would really get that....

Seriously I think that this is correct behavior and should be maintained. If someone wants a "test to see if the value is still the same after reint to default" then that functionality could be implemented for individual controls.