RadNumericUpDown - Value cannot be converter

[alex]

I'm looking for a generic solution for handling a common issue with RadNumericUpDown. When binding the Value property to a double (non-nullable) and the user clears the input (e.g., with Backspace), the control throws a "value cannot be converted" error.

I'm aware that changing the bound property to a double? would resolve this, but in my case, this is not feasible across the entire application due to the extensive refactoring it would require in legacy code.

 

As a senior WPF developer, I prefer generic solutions that can be applied globally—such as using an attached property via styles—so the fix can be inherited by all RadNumericUpDown instances.

I've considered using FallbackValue or TargetNullValue, but these aren't suitable as they require changes to each individual binding and would assign a default value, which is not ideal.

Since the value in the ViewModel doesn't actually change when the conversion fails, it seems reasonable to simply suppress the error and let the control revert to the source value.

Is there a way to implement an attached property that can detect this conversion failure and handle it gracefully—possibly by resetting the control’s value to the bound property from the DataContext?

Any suggestions or sample code would be greatly appreciated.

Thanks!

[Motti]

Dear Dimitar,

It works as expected. I saved the last value of the numeric in another dep property instead of using the BindingExpression.

This was needed in case that I use binding mode OneTime, OneWay, OneWayToSource (for these cases the user will see the last written value in the control ajd the view model binding will not be changed).

You may close this issue (please consider to add this capability for future versions, you can add a dep property named "RevertLastValueOnNull").

[Dimitar]

Hi Alex,

Thanks for the question. This is indeed possible. Here is how you can implement the behavior (will default to the previous value): 

public static class RadNumericUpDownBehavior
{
    public static readonly DependencyProperty HandleValueConversionErrorProperty =
        DependencyProperty.RegisterAttached(
            "HandleValueConversionError",
            typeof(bool),
            typeof(RadNumericUpDownBehavior),
            new PropertyMetadata(false, OnHandleValueConversionErrorChanged));

    public static bool GetHandleValueConversionError(DependencyObject obj)
    {
        return (bool)obj.GetValue(HandleValueConversionErrorProperty);
    }

    public static void SetHandleValueConversionError(DependencyObject obj, bool value)
    {
        obj.SetValue(HandleValueConversionErrorProperty, value);
    }

    private static void OnHandleValueConversionErrorChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        if (d is RadNumericUpDown numericUpDown)
        {
            if ((bool)e.NewValue)
            {
                numericUpDown.ValueChanged += NumericUpDown_ValueChanged;
            }
            else
            {
                numericUpDown.ValueChanged -= NumericUpDown_ValueChanged;
            }
        }
    }

    private static void NumericUpDown_ValueChanged(object sender, RadRangeBaseValueChangedEventArgs e)
    {
        if (sender is RadNumericUpDown numericUpDown)
        {
            // Check if the new value is null (e.g., user cleared the input)
            if (!numericUpDown.Value.HasValue)
            {
                // Reset the value to the bound property from the DataContext
                var bindingExpression = numericUpDown.GetBindingExpression(RadNumericUpDown.ValueProperty);
                if (bindingExpression != null)
                {
                    bindingExpression.UpdateTarget();
                }
            }
        }
    }
}

To use this, you add the following style to your resources: 

<Application.Resources>
    <Style TargetType="telerik:RadNumericUpDown">
        <Setter Property="local:RadNumericUpDownBehavior.HandleValueConversionError" Value="True" />
    </Style>
</Application.Resources>

I hope this helps. Should you have any other questions, do not hesitate to ask.

Regards,
Dimitar
Progress Telerik

[Motti]

Thank you for your fast reply.

I am wondering if this solution is good when the binding can be set to Property Changed OR lost focus.

The user may remove the value to introduce a new one, so I am not sure that this fix is good (since the value will be reverted during typing on Property Changed).

How can I use this fix on Lost Focus? (after the user finished typing). Can I copy same code to LostFocus event instead of ValueChanged event?

Moving the code to the LostFocus event isn't sufficient, as I still need a way to bypass the "Value cannot be converted" error.

 

To resume I need:

1. Do not show error on UI (keep error template for other errors)

2. Update value according to trigger (LostFocus or PropertyChanged)

3. OnLostFocus: revert control value if null

[Dimitar]

Hi Motti, 

I have tested this in my project, and it seems to work as expected. I have attached the project. Could you please check it and let me know if I am missing a specific case? 

I am looking forward to your reply.

[Motti]

Thanks,

According to your code you revert the value on ValueChanged.

Then I have two options

1. LostFocus: value will changed on lost focus, then error is skipped and value is reverted. If user deletes the value, it will reverted on Lost Focus. Expected behavior.

2. PropertyChanged: value will be changed on property changed, then error is skipped and value is reverted. If user deletes the value, it will reverted on Property Changed (during typing). UNEXPECTED behavior.

Imagine that the user wants to delete number, for example "12" in order to type "16". He will not be able to do that since the value will be reverted with your code.

If I want to add this fix to a style, I need to handle both scenarios.

Maybe do we need a kind of combination? skip the error on ValueChanged and revert the value on LostFocus?

Can you please test both scenarios in the code example you have provided to see the unexpected behavior I am talking about?

[Dimitar]

Hi Motti, 

I have tested this, but I am unable to reproduce the mentioned behavior with the test project. When typing, the value changed event is not fired on every keystroke, and you cannot set the value to null with the buttons. What am I missing in this case?  Can you record a video of the behavior on your side? 

I am looking forward to your reply.

[Motti]

I didn't tested it yet because I wanted to get final code to test it on my side (it takes a little bit to prepare the environment for testing).

But "how the value changed event is not fired on every stroke?"

How the value is updated every time on ViewModel (with PropertyChanged)? and how the errors appears? I taught that when removing the last number number with backspace, the ValueChanged event is fired and because of binding failure (bound to double instead of double?), I get the message.

When the ValueChanged is called? if I get null when property in ViewModel is double?, it seems natural to do the same with double, because of that reason I taught that for every change the event is called.

If there is a "12" on RadNumericUpDown, then removing "2" and then "1" supposed to trigger ValueChanged twice. for the second, I supposed to get the reverted value according to your solution. Why dont you see it on your side? 

I cant understand why your solution works...

What am I missing?

[Dimitar]

Hi Motti, 

I have examined this one more time. It seems that the text is not updated when we update the value in the custom behavior. So there is a valid underlying value that is not displayed. Once the focus is lost or the user starts typing again, the value is displayed and updated. 

I hope this clarifies this. Should you have any other questions, do not hesitate to ask.

[Motti]

I understand. Thank you for your help.

I will test it and let you know. I sugguest to open an issue on this topic, maybe for future versions.

I think that most of the cases, developers bind to not nullable values, and such a feature can be very helpful.

I am sure that it is more complicated for you, because you need to test more cases. Adding a Dependency Property which defines whether to display error or not will be nice.