NumericUpDown Internal Text Doesn't Update When Expected

[ryanknopf]

Hey All,

Looking for any pointers I can get on a workaround for this issue. I've tried nearly everything I can think of but am still following short of the desired result. This is similar to issue num 2952.

NumericUpDown Text Doesn't Update to Value on Lost Focus

I have a NUD (NumericUpDown) which is bound to a double type property (TwoWay, UpdatedSource on PropertyChanged, Converter converts double? to double via substitution of null with 0). That property's set statement rounds to the nearest tenth (set value 11.234 becomes 11.2). To match this I have the NUD interval set to 0.1 and the string format is "F1".

However, in practice, if a user types in a value with excessive precision (e.g. "11.3456") that text persists until something else (up or down buttons, code behind) changes the value of the source. In fact, from what I've seen a ValueChanged event never occurs in this case because in fact the ValueProperty of the NUD is already the correct "11.3" because of it's binding to the source (which rounds it when set) but the text does not reflect that.

Removing the rounding operation from the set statement of the property which is the bound value source for the NUD resolves this issue in that the text is updated to match the string format on loss of focus, but oddly enough the actual ValueProperty is set to exactly what the user has entered ("11.345678 etc")

Everything works as expected if UpdateSourceTrigger is set to LostFocus, but this isn't the behavior we want for this control.

Expected outcome

I would like it to be the case that when users type in values of excessive precision (e.g. "11.3456" that the value is automatically updated ("11.3") to match the string format property or interval when focus is lost. Even better would be if the user were prohibited from even typing in a value with a precision that is too great. I know exactly how that could be done if I were rolling my own spinbox from a TextBox (regex the text property on PreviewTextInput and handle the event if format is bad) but it seems there must bee a good workaround that still leverages Metro (almost everything else has worked exactly as I would expect!).

An example of the property being bound to:

public double Setting
{
    get { return _setting; }
    set
    {
       value = Math.Round(value, 1);

       if (_setting != value)
       {
            if(0.0 < value && value < 2.0)
            {
                _setting = 2.0;
            }
            else selected_grip_setting = value > 0.0 ? value : 0.0;

            RaisePropertyChanged("SelectedGripSetting");
        }
    }
}

An example of the control xaml:

<Controls:NumericUpDown x:Name="SpinBox"
                                            Minimum="0"
                                            Maximum="12"
                                            Interval="0.1"
                                            StringFormat="F1"
                                            Value="{Binding Setting,
                                                         Converter={StaticResource NullableDoubleConverter}}" 
                                            Width="130"
                                            Height="55"
                                            FontSize="18"
                                            VerticalAlignment="Top"
                                            HorizontalAlignment="Center"
                                            Margin="0,10"/>

Environment

• MahApps.Metro v1.4.1
• Windows OS 10
• Visual Studio 2017
• .NET Framework 4.5

[punker76]

@ryanknopf Can you try using the latest version 1.5.0?

[ryanknopf]

@punker76 Thanks for the quick response! Looks like exactly the same behavior in 1.5.0.

[ryanknopf]

@punker76 I've narrowed down the issue a bit further (if the explanation is helpful):

When a user types a value of excessive precision into the NumericUpDown internal TextBox "e.g. 1.2345", OnTextChanged() is called as each character is typed ("2", then "3", then "4", etc.), and ValidateText() succeeds because even though the number is of greater precision than the interval desired by the user it's still a valid double. Thus the NumericUpDown ValueProperty is set to the result of CoerceValue(), which only truncates the number if HasDecimals is false.

When this happens, while tracing the two-way data binding to my rounding example property "Setting", I see that the property receives a raw value of "1.2345", that it is rounded to the nearest tenth "1.2", set, and the property changed event is raised, at which point the NumericUpDown grabs the current value but the text of the internal TextBox does not change (from “1.2345”).

When the user leaves the NumericUpDown internal TextBox, OnTextBoxLostFocus() is called. At this point, the internal text is still "1.2345" while the NumericUpDown ValueProperty has been updated by the binding to "1.2" (they don't match). So, after ValidateText succeeds on the textual convertedValue, SetValue(ValueProperty, convertedValue) is called because the current value "1.2" and the convertedValue "1.2345" don't match. This causes the "Setting" property to be set through the binding with a raw value of 1.2345, but since it's rounded to 1.2 there is no change, and the property changed event isn't raised (and so the internal text of the NumericUpDown isn't updated as it would be if OnValueChanged were called due to a property changed event).

I've been able to "band-aid" this by extending the NumericUpDown class and adding a method which calls OnValueChanged(Value,Value). I then call this method in a LostFocus event handler manually. Seems like there should be a much cleaner solution though. I’m just looking for the ability to restrict user input to the level of precision implied by the Increment/Decrement interval.

[ShannonZ]

I met the same problem. How to solve it elegantly?

[punker76]

@ryanknopf Should be fixed now with bd5b84f, available in 1.6.0 (and upcoming alpha)