views:

402

answers:

4

Several (newbie) questions:

1) I see a lot of

public Person SelectedPerson { get; set; }

I am assuming this does NOT fire a property change?

So, if I want to do so, I must provide the following?

    private Person selectedPerson;
    public Person SelectedPerson
    {
        get
        {
            return this.selectedPerson;
        }
        set
        {
            if ((this.selectedPerson != value))
            {
                this.selectedPerson = value;
                base.OnPropertyChanged("SelectedPerson");
                // Note: Using ViewModelBase

            }
        }
    }

2) If I have the following:

    public bool CanDeletePerson
    {
        get
        {
            return SelectedPerson != null;
        }
    }

and also in the XAML

< Button IsEnabled="{Binding CanDeletePerson}" 
Command="{Binding DeletePersonCommand}"> Delete </ Button >

How do I get it to re-evaluate the CanDeletePerson property? Basically, it is initially disabled, but when I click on the grid and move row to row, the SelectedPerson IS being updated, but the CanDeletePerson is NOT getting the updated value, so how do I get it to actually check the value again?

3) I see

... depends on whether anything has subscribed to the event

How do you subscribe to the event?

+1  A: 

Yes, Auto Properties do not fire the PropertyChanged event.

You can get the CanDeletePerson to re-evaluate by adding OnPropertyChanged("CanDeletePerson") to the SelectedPerson setter.

I'm not sure if your last bit is a question, but you can subscribe to the PropertyChanged event like any other event. MyClass.PropertyChanged += MyClassPropertyChanged

Where MyClassPropertyChanged is

private void MyClassPropertyChanged(object sender, PropertyChangedEventArgs args)
{
    args.PropertyName .... //<-- Name of property changed.
}

But you shouldn't need to. WPF does the subscribing to the event that it needs to.

Ray
+1 You beat me.
statenjason
+2  A: 
  1. Correct - that does not fire
  2. Yes, to have CanDeletePerson reevaluated, you can raise PropertyChanged on CanDeletePerson, like so

        set
        { 
            if ((this.selectedPerson != value))
            { 
                this.selectedPerson = value; 
                base.OnPropertyChanged("SelectedPerson"); 
                base.OnPropertyChanged("CanDeletePerson");
            }
        }
    
  3. Like any normal event, but if you're using WPF, you typically don't need to subscribe explicitly

Scott Weinstein
+1 You got in later, but I liked the organization of your answer.
Anderson Imes
see http://stackoverflow.com/questions/1329138/how-to-make-databinding-type-safe-and-support-refactoring/1333874#1333874 for a compiler checked way of implementing INotifyPropertyChanged.
Ian Ringrose
A: 

Here's a link to a good article introducing the MVVM pattern.

Specifically, if you look at the RelayCommand class, it does a nice job of implementing an ICommand object and allowing you to specify a predicate to evaluate whether or not the Command may be executed.

The evaluation of the canExecute predicate in the RelayCommand saves you from binding a separate property to the IsEnabled property of the Button.

I typically follow the example in the article of implementing a private property which supplies the Boolean value for the canExecute predicate.

That article was a good help to me to get started with the pattern.

Eric
A: 

If you use the PropertyChanged event, your class needs to implements the INotifyProperyChanged interface and raise the event where necessary. In WPF, the default for the databinding is the DependencyProperty, so if you work with the PropertyChanged event, you must do something into the XAML (Assuming that your class person have a Name property where you raise the PropertyChanged event):

<TextBlock Text={Binding Path=Name, UpdateSourceTrigger=PropertyChanged} />
Coolweb