Telerik RadNumericUpDown for Silverlight does not update binding when value is blanked out

Note: This may be fixed in a later version of Telerik controls; this issue was discovered in the Telerik.Windows.Controls library; version 2011.1.315.1040

Working on a Silverlight application, we found ourselves with some dialogs that utilize the Telerik RadNumericUpDown control.  We discovered a defect when binding the Value property of the control to a ViewModel behind the scenes.

The original binding works as expected, and if the spinner controls are used to change the value, the ViewModel updates as we expect.  If a user types a new value into the control it also updated the binding on the ViewModel correctly.

The problem arises when we blank out the value by clicking into the textbox portion of the control, highlighting it and hitting the Backspace or Delete key.  Removing focus from the control or not, the ViewModel property bound to that control does not get updated.

To work around this, we created this Event Handler:

void RadNumericUpDown_ValueChanged(object sender, 
                                   RadRangeBaseValueChangedEventArgs e)
{
    if (sender is RadNumericUpDown)
    {
        RadNumericUpDown upDownControl = sender as RadNumericUpDown;
        if (!upDownControl.Value.HasValue)
            upDownControl.Value = upDownControl.Minimum;
    }
}

Now we apply this event handler to our XAML:

<telerik:RadNumericUpDown ValueChanged="RadNumericUpDown_ValueChanged" ... />

This makes the behavior act the same as if the user had used the down spinner on the control to modify the value down to the minimum.

This may not be the ideal solution for you, but understanding this will give you direction on how you can create your own workaround.  We started down the path of handling the KeyUp event, but ValueChanged seems much more appropriate.

Telerik makes fantastic controls; and I'm not mad by any means.  Being a developer myself, I realize these things happen; but I do hope they have handled this better in a later release.  And as far as I know this is the only control in the 2011.1.315.1040 version that has this issue.

Why We Must Use Classes Instead of Structs for Read/Write DataBinding in C#

Structs are Value Types.
Classes are Reference Types.

When we DataBind in C#, if we're using Value Types... we get copies of those objects instead of pointers to them, for that's how they are passed to the bound control. Therefore, you can't edit the bound control and expect the original objects to be modified. The bound control is only editing the copies and thus we encounter side effects when DataBinding a list or array of value types (like structs.)

I ran into this on a project I was working on where I needed to show a DataGridView for editing attributes. My attribute representation was a struct with a name property and value property... and when I bound a BindingList to the DataGridView, the list would appear... but when I'd edit the values would return to the old values... and when I'd add rows, the values would disappear.

The explanation above explains why. It didn't dawn on me until I started searching for "BindingList structs" and found Bill Wagner's "Of DataBinding and Value Types" (archive.org since the site is no longer available). The title tipped me off because I wasn't thinking about the fact that structs are value types.

Bill's article explains in more eloquent detail than I care to go into here, as I don't feel the need to re-write a well written essay on the topic. I only hope to provide a quick answer for those searching for it, that don't find Bill's article first (and leave myself a quick reference when I forget the next time I try to use a struct...)

He also mentions in his article when it is appropriate to use structs. Thanks for a well-done article, Bill.

So, reminder: use classes instead of structs when you need to do read/write binding. If you're merely databinding for a viewable list... use structs as you like.