views:

3615

answers:

3

I am open to suggestions with the title. It really is pretty bad.

What I have is an object that has an "IsReadOnly" property. If this property is true, I would like to set the "IsEnabled" property on a Button, ( for example ), to false.

I would like to believe that I can do it as easily as IsEnabled="{Binding Path=!IsReadOnly}" but that doesn't fly with WPF.

Am I relegated to having to go through all of the style settings? Just seems too wordy for something as simple as setting one bool to the inverse of another bool.

 <Button.Style>
                    <Style TargetType="{x:Type Button}">
                        <Style.Triggers>
                            <DataTrigger Binding="{Binding Path=IsReadOnly}" Value="True">
                                <Setter Property="IsEnabled" Value="False" />
                            </DataTrigger>
                            <DataTrigger Binding="{Binding Path=IsReadOnly}" Value="False">
                                <Setter Property="IsEnabled" Value="True" />
                            </DataTrigger>
                        </Style.Triggers>
                    </Style>
                </Button.Style>
+25  A: 

You can use a ValueConverter that inverts a bool property for you.

XAML:

IsEnabled="{Binding Path=IsReadOnly, Converter={StaticResource InverseBooleanConverter}}"

Converter:

[ValueConversion(typeof(bool), typeof(bool))]
    public class InverseBooleanConverter: IValueConverter
    {
        #region IValueConverter Members

        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 boolean");

            return !(bool)value;
        }

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

        #endregion
    }
Chris Nicol
There are a few things I have to consider here, that will likely make me pick @Paul's answer over this one. I am by myself when coding (for now), so I need to go with a solution that "I" will remember, which I will use over and over. I also feel that the less wordy something is the better, and creating an inverse property is very explicit, making it easy for me to remember, as well as future dev's ( I Hope, I Hope ), to be able to quickly see what I was doing, as well as making it easier for them to throw me under the proverbial bus.
Russ
By your own arguments, IMHO the converter solution is better in the long term : you only have to write the converter once, and after that you can reuse it over and over. If you go for the new property, you will have to rewrite it in every class that needs it...
Thomas Levesque
Chris, Thomas I want you both to know that even though I picked Paul's answer as "the answer", and I don't feel it’s fair to change that pick this late in the game, I am conceding here that you were both right, and the converter has become much more useful to me, especially when using framework values where I have no control.
Russ
No problem ... just as long as you have a solution that works for you then that's all that matters. Converters are great though aren't they!
Chris Nicol
I'm using the same approach... but it makes panda saaad... =(
Yacoder
+3  A: 

Have you considered a IsNotReadOnly property? If the object being bound is a ViewModel in a MVVM domain then the additional property makes perfect sense. If it's a direct Entity model, you might consider composition and presenting a specialized viewmodel of your entity to the form.

Paul Alexander
I just solved the same problem using this approach and I agree that not only is it more elegant, but much more maintainable than using a Converter.
alimbada
+11  A: 

I opened suggestion to implement Boolean inversion converter to WPF framework (to Microsoft Connect bug/suggestion system)

If you care about this enhancement please vote on it there.

There are many other such weaknesses in WPF that should be addressed also, so if you find such a rudimentary insufficiency I think you should also add it to there. Currently people seem to implement a lot of these "common" / "utility" libraries to accommodate simple tasks that should be part of framework.

Ciantic
Thats a good Idea. I have added one or two myself when I find the doc wanting.
Russ
+1, here and there =)
Yacoder
+1, this would be awesome if its built in WPF framework.
Sarmaad