• 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)

    This post reinforces my agnocodolinguophobia!

  • Rob (unregistered)

    This interface should have been generic, that would remove the need for "typeof"s in the ValueConversion attribute, prevent having to deal with "object", and actually show the intent of both convert methods. And that cast to "double" would probably not even compile if the value wasn't "object" but "string".

  • Officer Johnny Holzkopf (unregistered)

    Info: such culture, much convert.

  • Twither (unregistered)

    I know exactly what this person was thinking. They were thinking that C# is JavaScript. Except with types. So, they have a string and they want a double. Just cast it to a double! The type checker is happy and everything compiles, so it must be right.

  • Twither (unregistered) in reply to Rob

    This interface should have been generic

    That's a nice thought, but it doesn't work. IValueConverter is meant for use in XAML which is allergic to generics (and doesn't much like types in general). Hence the need for type annotations instead of actual types.

    As a side note, XAML is also why it took so long for C# to get "extension properties". The language team was all ready to pull the trigger and then the framework team said "Wait, that doesn't do what we wanted."

    WPF isn't the WTF. XAML is.

  • (nodebb)

    Meh. Not much of a WTF.

    The semantics of the Convert/ConvertBack are pretty clear:

    • Convert converts from the "source" (model/viewmodel/datacontext) to the "target" (a property of a UI element)
    • ConvertBack converts back from the target to the source (used in two-way bindings or one-way-to-source bindings), so it's not a particularly bad name. The names only seem bad to Remy because he doesn't really know WPF.

    In this example, the Convert method doesn't really do anything useful. If the source value is null or anything other than a double, return null, otherwise return the double value. Since we can reasonably expect that the value will always be either a double or null, the implementation could have been just return value;. The ConvertBack method just converts empty strings to null, which is legitimate as far as I can tell.

    So basically the only WTF here is the name of the parsed variable.

    So that's where it's reaching out to the .NET Framework's built-in conversion functions.

    No, it doesn't "convert" anything. It just casts. If value is of the expected type, parsed will have that value, otherwise it will be null.

  • Tim (unregistered)

    I've never used WPF but it seems to me quite obvious that (a) the functions in the interface should be named something unambiguous like ModelToDisplay and DisplayToModel; (b) they should have generic type annotation so that when you implement IValueConverter<Double> the parameter and return types are explicit. in fact either of these would be enough to remove the ambiguity

  • NeuroticNetwork (unregistered) in reply to Tim

    There's actually a reason for the Convert() - ConvertBack() convention: IValueConverter is data binding glue. And while the typcial WPF use case is bindings between view and view model, it's not the only use case. Bindings within the view are useful for linking control states that are just UX, not underlying business requirements, for example. I've also created bindings between view models in the past, but that's admittedly niche (and I personally find it annoying to set up). So from that perspective it makes sense to see the methods as dependent on data flow direction instead of sender/receiver.

  • 3moly (unregistered)

    I used WPF a long time ago, and while it hasn't aged well for custom UI, focusing strictly on business logic without touching the underlying UI still makes WPF a very fast tool for building safe, validated apps. But this post makes no sense — asking these questions without even showing what you actually achieved.

    You're acting like a kid who just discovered a great tool -> C# Annotations. Looks like you haven't touched C# at all and are just making an inappropriate post for whatever reason.

    Those conversion classes are just mappers, if you didn't know. What matters is what's specified in the annotation: FROM which type to convert and TO which type.

    ~Oh yeah guys, I don't see 1 line of unsafe Python code, so I'm gonna call this ugly if I see 7 lines of understandable, fully readable code ~oh, I see 1 inner "parsed" line, oh my god, I'm gonna cry.

    And I get that XAML is the problem. If you aren't asking yourself what it can actually be useful for (ask AI about that if you can't ask yourself), then why make this post and claim you don't like it? I'm 100% sure this was a hasty decision ("oh, I haven't posted in a while, let me make another post").

    Lame that I saw this post while just checking if this forum is good for me. Not this time.

    Just ask yourself more questions — and not from the EGO side of yourself. Maybe you'll find something useful instead of ~python~.

Leave a comment on “Convert Back, Way Back”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article