WPF - Dynamic value in ConverterParameter

Question

Got a situation where checkboxes in a UI need to be bound to a numeric parameter - effectively, certain values make the checkbox "true", otherwise it's "false".

Easiest way to do this seemed to be to use a converter:

[ValueConversion(typeof(int), typeof(bool?))]
public class TypeToBoolConverter : IValueConverter
{
    public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
    {
        if (targetType != typeof(bool?))
            throw new InvalidOperationException("The target must be a bool");

        if( (value < 3)
        {
            return true;
        }
        return false;
    }

    public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
    {
        throw new NotImplmentedExpection();
    }
}

And then in the XAML:

<CheckBox IsChecked="{Binding Path=Type.TypeID, Converter={StaticResource TypeConverter}}" />

Which works like a charm when using Convert, but fails utterly when using ConvertBack because it needs to know what the numeric value was (it depends on other UI elements) before it can know what number to return - effectively it needs access to the bound object.

I assumed I could do this with a ConverterParameter, but from the looks of things you can't bind a value to this property.

Is there a way out of this mess?

EDIT: I have solved this by messing around with the original bindings, and got away with it because on uncheck all I want to do is delete the item anyway. But I'm going to leave this in place since it seems a valid issue and I'm curious about possible solutions.

could this be of any help? http://stackoverflow.com/questions/397556/how-to-bind-radiobuttons-to-an-enum — Lucian, Mar 19 '14 at 12:27

score 7 · Accepted Answer · answered Mar 19 '14 at 12:28

7

Why don't you just bind to something and do the work in what you are binding, for example a viewmodel? It probably will be cleaner and faster.

Converters are nice in theory, but after building many large WPF projects, I almost never use them for reasons like above. Sure, you can get it to do what you want, but what's the point? You have much less control of how and when these conversions happen.

answered Mar 19 '14 at 12:28

therewillbesnacks

1,015
6
8

Good point, but in this instance it would involve significant extra effort. The ViewModel behind this contains a number of collections of EF objects which are used directly, not mapped. To do what you're suggesting would require me to add in some POCOs and AutoMapping and then add the desired property to work with in the POCO. – Bob Tway Mar 19 '14 at 12:39
Fair enough. As per my edit I found an easier way round this in my particular problem, but your suggestions make good sense for instances where you're wanting to update rather than delete an item, so I'll accept your answer. – Bob Tway Mar 19 '14 at 12:47
Thanks, sounds good. I really recommend in any WPF app you simply encapsulate things using good patterns. MVVM and other patterns are not a panacea, but they at least make situations like this a lot easier. It's tempting to directly bind all your data and do things quickly, but as you implement more real-world projects and requirements, the quick and dirty approaches can fall apart. I find my DB for instance is rarely a direct mirror of my UI in all but the simplest cases or for some throw-away admin screen. – therewillbesnacks Mar 19 '14 at 12:51
I'm actually using MVVM, and have mostly been doing what you've suggested. This particular instance is a really odd UI requirement where the screen doesn't map to the data well at all. The UI probably needs a redesign, but I needed a quick temporary fix. – Bob Tway Mar 19 '14 at 12:53

WPF - Dynamic value in ConverterParameter

1 Answers1