Question

I’ve inherited a Silverlight project with dubious code quality overall, and there is one construct that I’m not sure whether I should touch it:

public SomeClass Self
{
    get
    {
        return this;
    }
}

It is used in XAML Bindings, with parameters, sometimes complex like this:

Visibility="{Binding Self, ConverterParameter=!, Converter={StaticResource SmartAssConverter}}"

And it is used in a PropertyChanged notification (MVVM Light):

RaisePropertyChanged("Self");

So, is there something preventing me from just doing this:

Visibility="{Binding ConverterParameter=!, Converter={StaticResource SmartAssConverter}}"

which, I’ve tested, still shows just fine?

Rephrasing my question, is the necessity to ‘raise property changed’ forcing this kind of (IMHO ugly) construct?

Edit: rephrasing again, is there a more elegant solution to notify binded controls that their target has changed, or should I look into reworking the Converters?

Answer 1

What if the object (i.e. Self) changes? When using the Self property you can leverage the INotifyPropertyChanged interface to tell the binding to updated. If you remove the property, then how would you update?

You can try doing RaisePropertyChanged(string.Empty), but I don’t think that would work.

Generally the converters would just be passed the properties they need, not the entire object. But in Silverlight, there is no MultiBinding so you are limited to a single property.

You can either add a new property to your object that performs the same operation as the converter, or wrap it with another object that adds the property. This is generally the role of a view-model.