newValue and OldValue are both 0! so why does it triggers the event?
This is causing an error because it then tries to close a dialog that’s not even open. To be fair, the error is visible only in the diagnostic page, not on the HMI, but still I don’t understand this behavior.
for an valueChanged event the value actually has to change. The debug showing 0 for new/oldValue means the value was 0 and stayed 0 so for the system the value didn’t change so no event was triggered.
It doesn’t work in your case but if you want to force a valueChanged event you can initialize the variable with -1 or any other number not used otherwise. When mappView loads and the actual value is written you get oldValue = -1 / newValue = 0 and the event.
To prevent to error when the system is trying to close the dialog I would add a condition of newValue = 0 AND oldValue > 0.
that’s exactly the issue I’m having! the event is triggered even if the value didn’t change!
I am already using the solution you wrote newValue = 0 AND oldValue > 0, but it’s really nonsense. the value change event should be triggered only if the value does change..
OK, I misunderstood the issue then but there is a setting in mappView to trigger on the initial value. Can you check if this is TRUE in your config file?
I know that mappView is writing in some specifici scenarios a default value to OPCUA tags (e.g. I think to reset value of momentary button), and it does not matter if the default value and current value are the same. But this should not be the case; you are checking the pending alarm output of MpAlarmX Fub, right? So this should be read-only.
yes I check valuechanged of that output of MpAlarmX.
the very annoying thing is that even the diagnostic shows oldvalue = newValue = 0 !!!
I don’t know what happens under the surface of if that’s the case you are describing, but this is a very basic usecase, not a complicated binding.. as usual mappview is so frustrating to use…
You have a workaround. So it is up to you if you report it to local support. I think it should not behave as you are describing for this specific use case. But I might be wrong, and the project must be checked by colleagues from support. I think there could be some additional dependecies we cannot see right now.
