`CoerceValueCallback` call after source updated causes source got a wrong value

[ahdung]

Description

I'm writting a NumericUpDown control, when user click up/down button, the Value will increase or decrease, but limit by MaxValue/MinValue in CoerceValueCallback, when Value and MinValue is 0, click down button will cause Value be -1, and source got -1, and then, CoerceValueCallback make value to 0, but source still -1. why the CoerceValueCallback called after source updated?? it should be a guard, every change should call it first.

Reproduction Steps

demo here.

WpfNumericUpDown.zip

Expected behavior

all change respect CoerceValueCallback

Actual behavior

CoerceValueCallback not respected

Regression?

No response

Known Workarounds

No response

Impact

No response

Configuration

wpf 9.0-windows

Other information

No response

[lindexi]

Reference: https://stackoverflow.com/questions/58128142/updatesource-not-working-within-coercevaluecallback

I'm afraid the issue you're running into is by design, not a bug.

There's actually some rationale behind the current approach — the input source side still stays in an error state. I tried adding a bit of code that might help clear things up for you. I do agree with what you said about CoerceValueCallback should be a guard. The question is really whose guard it is. The thing is, CoerceValueCallback serves as a guard for DependencyProperty ValueProperty, not for TestViewModel.Value. I think that design choice has some merit

    <TextBox Text="{Binding ElementName=NumericUpDownElement,Path=Value,Mode=OneWay}" Width="80"></TextBox>

As shown in the image above, you can see that CoerceValueCallback does indeed act as a guard for DependencyProperty ValueProperty, making sure that invalid data doesn't get written into ValueProperty. However, TestViewModel.Value isn't meant to be protected by the CoerceValueCallback — that's why the source still holds -1.

If you still find this behavior unintuitive or are wondering why it was designed this way, just think about it: in WPF, a single source can feed multiple targets. It's totally reasonable to bind a ViewModel property to several places in the UI. So what happens if all those places have their own CoerceValueCallback? If a value conflict arises and CoerceValueCallback also acted as a guard for the source, the ViewModel property would end up being clobbered by conflicting CoerceValueCallbacks from different bindings.

[ahdung]

@lindexi Thank you help with patient. Ok I know I can't to push any changes, especially something BY DESIGN, although I don't think that is a problem. I don't ask CoerceValueCallback protect things out of control, but control should have responsible for providing corrected value to the outside, let ViewModel got a raw value is a definitely wrong.

No matter about above, I let Value become a UpdateSourceTrigger.Explicit, and call UpdateSource in ValueChanged, coerce work fine now for click Up/Down button, but meet new issue:
when Maximum set to 33, and type 44, coerce make Value to 33, but ViewModel still got a wrong value 44, note e.NewValue is the corrected 33, except I set Value manually in ValueChanged, this is a ugly solution, can you help please? new demo here:

WpfNumericUpDown.zip

[ahdung]

seems PropertyChangedCallback is not enough Chang**ed**, the control so stubbornly like the raw value and put it to source, insane design.

[gpaskaleva-msft]

You're right that PropertyChangedCallback (and CoerceValueCallback) aren't enough — and that's not a bug, it's the intended separation. Here's the why, which makes it feel less insane:

When a DP is the target of a TwoWay binding, SetValue routes through the binding before coercion runs. The binding caches the raw incoming value first; only then does coercion shape the DP's effective value. Coercion is deliberately property-local — it changes what the property is, never what a binding sends to its source. So UpdateSource() faithfully pushes the raw value it cached earlier. The control isn't being stubborn; the binding simply committed to the raw value before your callback ever ran.

In this repro (type 44, Maximum=33): outer {Binding Value} caches raw 44 → coercion clamps the DP to 33 → ValueChangedCallback 's UpdateSource() pushes the cached 44 .

Fix — since Maximum is a control constraint, re-set the coerced value so the binding re-caches it before pushing to the source:

// e.NewValue is already coerced; re-setting re-caches it in the binding.
// Idempotent coercion means no re-entrancy.
control.Value = (decimal)e.NewValue;
control.GetBindingExpression(ValueProperty)?.UpdateSource();

Clamping in the ViewModel setter or an IValueConverter.ConvertBack is the alternative but only fits when the limit is a domain rule rather than a control setting.

[ahdung]

@gpaskaleva-msft Thanks for your explaination.
call CoerceValueCallback after updating source, cause control and ViewModel have different value, is that their design?
UpdateSource but source not got e.NewValue is also the design?
even need Value=e.NewValue these HACK trick to make it work normal.

bug is bug, I think I'm starting to understand why WPF doesn't provide a NumericUpDownm, that even they can't write a robust one?

[lindexi]

Yeah, I agree. Sometimes framework design is just about picking your battles.

[miloush]

Value coercion is a fundamental part of the dependency property design. Not only can the value itself change, but the coercion conditions themselves can change. The DP system remembers the value you are aspiring for and will keep attempting it. This is documented and described here: https://learn.microsoft.com/en-us/dotnet/desktop/wpf/properties/dependency-property-callbacks-and-validation#constraints-and-desired-values

It sounds like value coercion is not the right tool for your task.

[ahdung]

@miloush Thank you for explain. Do you have suggestion for this scene.