CodeSOD: Convert Back, Way Back

Windows Presentation Foundation, the XML-based UI framework for Windows, has its own "fun" quirks. One of its core ideas is that controls can be data-bound: that text box is linked to a numeric field in your model class. Type a different number, and the model automagically updates.

That's fine for what it is, but of course you're going to need to give it some instructions on how to do those kinds of conversions for your own custom types. And that's where the IValueConverter interface comes in.

You can write a class which implements that interface, which can then Convert and ConvertBack. Which, as a note, I hate that naming convention; which way is "back"? Well, that's controlled via an annotation. This is some of Microsoft's sample code, from their docs:

[ValueConversion(typeof(Color), typeof(SolidColorBrush))]

public class ColorBrushConverter : IValueConverter

{

    public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)

    {

        Color color = (Color)value;

        return new SolidColorBrush(color);

    }



    public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)

    {

        return null;

    }

}

I don't particularly like this API, but again, it is what it is. This converts a color into a brush, and returns a null when we try and convert back, because that's not a valid operation.

Which brings us to Fredrika's submission. You see, there is a problem with this approach. If you bind a text box to a double? field, everything is fine and handled automatically- except the built-in converter doesn't turn empty strings into nulls. So one of her co-workers wrote this:

    public class StringToDoubleConverter : IValueConverter 

    {

        public object Convert(object value, Type targetType, object parameter, CultureInfo culture)

        {

            double? parsed = value as double?;



            return parsed;

        }



        public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)

        {

            string parsed = value as string;



            if (parsed == string.Empty)

                return null;



            return parsed;

        }

    }

Convert doesn't do anything. ConvertBack takes the string from our text box, checks if it's empty, and if it is, returns null.

Now, you'll notice something about the code here: when it Converts, it casts value as double? and when it ConvertBacks, it casts value as string. So that's where it's reaching out to the .NET Framework's built-in conversion functions.

I'm not entirely sure where to point to for the WTF, and some of that may be because I've had the good fortune to never have to use WPF. I don't like WPF's approach, but the developer behind this code isn't helping matters. Certainly naming variables parsed isn't clarifying matters.

I don't have a nice bow to put on this one. I just don't like any of this. I don't like the converter API. I don't like this implementation of it. I don't like trying to treat empty text boxes as null values, which I'm sure is correct here, but boy howdy do I suspect there'll be problems in the future.

[Advertisement]
ProGet’s got you covered with security and access controls on your NuGet feeds. Learn more.