• Tinkle (unregistered)

    I agree, this is horrible, but it might be trying to avoid issues when an empty string would convert to 0 by default.

    What is the real WTF about this is that Convert take a string and returns null, and ConvertBack take a double? and returns null.

    Using the keyword 'as' does not do type conversion, it just casts to that type, so what they were thinking about, I do not know.

  • 3rik (unregistered)

    I am under the impression that this does not convert anything. Convert only casts the object value to double and then directly returns that double back as object. The only effect here is, if object value isn't a double, it'll return null subsequently.

    The same goes for ConvertBack, except with the additional comparison for string.Emtpy to return null.

    So it seems to me, that this does not - as then name suggest - converts double to string and vice versa. This only ensures the returned object is of the expected type or null.

    As for the convert/convert-back direction it's quite simple: From the view-model to the view is "converting", from the view to the view-model is "converting-back". It got nothing to do with the attributes. I believe, those are only for automatic converter selection of WPF but I never used that.

  • (nodebb)

    The real WTF here is all the different kinds of double we can have in c#.

    1. double d -- value type that cannot be null.
    2. object x = double d -- "boxed double" that can be null -- automatically generated when you try to assign a value type to object.
    3. double? d -- a struct with a HasValue boolean field and a Value field you can only access if HasValue is true -- and the language uses null in some contexts to mean such a struct without a value.
    4. objext d2 = double? d - an object containing a boxed double? struct -- which can be null in two different ways just for giggles.

    WPF predates double? so it knows nothing about items 3 and 4. WPF explicitly handles the conversions for #2, and binding to a #1 gets automagically boxed to #2 when you try to assign a double to an object. The author wants to edit a double? in a textbox so they need a converter. it turns out that converting case 3 to and from case 2 is enough to make this work. I still think this is bad code. If you are going to write your own converter you might as convert all the way to the type you need. (Double has ToString and TryParse methods that make this trivial to implement.)

    WPF has its quirks, but no worse than any other framework. (Or maybe after 23 years they've become normal to me.) Given its age, I am not ready to call all of WPF a WTF!

  • Dwaz (unregistered) in reply to John Melville

    #4 is not true. Nullable is special in a number of ways, one of which is that is never gets boxed. If you convert a nullable to object (or to any reference typed variable e.g. an interface), then it either turns into a boxed version of its underlying type (if it had a value), in this case double, or a straight up null (if it was null). This has been the case since it was introduced in net2.0. I wouldn't call any of this a wtf. You really only have double, There are no other variants worth mentioning. You never have to care about boxed doubles, because the runtime handles everything for you. And nullable doubles aren't a different type of double, but rather a wrapper that handles nullability (unless you want to consider any monadesque type like Task<double> as a different type of double, which is just a weird way of looking at thing).

  • Dwaz (unregistered)

    Also wpf absolutely does not predate nullable.

  • Tinkle (unregistered) in reply to Tinkle

    Hmm, correction.

    The name of the converter is back to front.

    It is not a StringToDoubleConverter, but an attempt at a DoubleToStringConverter. It still does not actually convert anything though, that is left to WPF.

  • Tinkle (unregistered) in reply to Dwaz

    It looks like you are correct.

    They just needed to add TargetNullValue='' to the binding.

    Every day is a learning day.

  • (nodebb)

    "Convert" means convert some other object to the type of which the Convert method is a member. "ConvertBack" means convert an object of the same type of which ConvertBack method is a member to something else.

    Could better be named as ConvertTo and ConvertFrom I suppose, like Powershell does. But the intent is clear even if you don't like the naming.

  • Hmmmm (unregistered)
    Comment held for moderation.

Leave a comment on “Convert Back, Way Back”

Log In or post as a guest

Replying to comment #702507:

Log Out

« Return to Article