• 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
    Comment held for moderation.
  • Dwaz (unregistered)

    Also wpf absolutely does not predate nullable.

  • Tinkle (unregistered) in reply to Tinkle
    Comment held for moderation.

Leave a comment on “Convert Back, Way Back”

Log In or post as a guest

Replying to comment #702496:

Log Out

« Return to Article