Lesson 03.6 – Update Player data with the PropertyChanged event

In this lesson, we will finish connecting the Model (Player.cs) to the View (MainWindow.xaml). With this change, when a property value changes on the Model or ViewModel, the View will automatically update.

 

 

Summary

  • An “Interface” defines the properties and functions that must exist in any class that “implements” the interface.
    • It also lets other classes know how the classes with the interface will work, and how they can be used.
  • Databinding does not automatically know when a property value changes in the DataContext object.
    • The View can know about changes to properties, if the ViewModel (or Model) classes implement the INotifyPropertyChanged interface.
    • When a class implements INotifyPropertyChanged, its properties “raise” a PropertyChanged “event”. The View “listens” for that event, and updates the UI, when it receives notification of the change.
  • To make the property raise the PropertyChanged event, when it gets a new value, they cannot be auto-properties.
    • We need to add extra code to the property “set”, to raise the Property Changed event, when the property is set to a new value.
    • To add this extra code, we need to add a “backing variable” for the property – a variable the property uses to store its value.
    • Then, we need to add a code to raise the PropertyChanged event, for anything that may be subscribed to the eventhandler, such as the View.

 

Source Code

 

Player.cs

 

MainWindow.xaml

 

MainWindow.xaml.cs

 

Return to main page

 

9 thoughts on “Lesson 03.6 – Update Player data with the PropertyChanged event

    1. Yes. Although, the property changed event is a built-in one that is automatically recognized. So, for the property changed event, we do not need to create the delegate, or manually connect from the “subscriber” (the ViewModel) to the “publisher” (the View).

      In future lessons, we will create our own custom events, for events like OnPlayerKilled and OnMonsterKilled. Those will require the delegate, subscribing, etc.

    1. Yes, you generally implement INotifyPropertyChanged in the Model. In the section of the Microsoft webpage labeled “The Model Class”, it mentions, “Typically, the model implements the facilities that make it easy to bind to the view. This usually means it supports property and collection changed notification through the INotifyPropertyChanged and INotifyCollectionChanged interfaces.”

      The View normally binds to properties of the ViewModel and the Models. This is because the View is normally displaying values from the Model properties. If we didn’t do this, we would need to duplicate properties from the Models in the ViewModel. Then, you would still need to have the Models raise events; however, they would be caught by the ViewModel – which would update its properties, and raise its ProperyChanged events, for the UI to capture. That would create a lot of duplicated code (the same properties in the Models and the ViewModel).

      You would use the ViewModel to handle “actions” from the UI, such as a button click. However, the ViewModel functions that handle those actions are usually small. They mainly call the appropriate functions in the Models, which have the more complex logic.

      Please let me know if that wasn’t clear, or if you have other questions.

  1. ok, so a few questions here… first of all, the virtual method OnPropertyChanged implies that it can be overridden in derived classes. Is this a default way of specifying this or are you planning to derive further classes from this Player class? if not planning on creating derived classes, is it better not to make it virtual?

    I understand that you must implement everything offered in an interface. this interface only had an event. ultimately, I think my question is how do I see/understand the functionality of the interface itself. When i look at the definition in VS, i don’t see it being derived from anything else and no explanation of how or when to use it. So, I go on you telling me I need this, but me being REALLY OCD when it comes to this stuff, I need to know the workings of it and having difficulty finding it. any advice?

    thanks

    1. It’s a common practice to make functions in base classes “virtual”, unless all its derived classes are “sealed”. In that situation, you would know there will never be a future derived class that needs to override the base function. So, you can safely remove the “virtual”.

      Because this program is still being developed, and I expect people will eventually modify the code to create their own versions, I prefer to leave the function virtual for now. If I ever decide the program is “complete”, and want to release a Version 1.0 of it, I would run static analysis tools on it (with very strict rules), and clean up issues like this.

      Other people prefer to be extremely strict from the beginning. Personally, I wouldn’t keep an unused class/function/property/variable in the project. But, I consider things like this (non-overridden virtual functions in base classes, class scope more visible than needed, etc.) to be acceptable during development.

      I’m not sure about your question, “I think my question is how do I see/understand the functionality of the interface itself.” If I didn’t answer it above, can you give me some more details of what you’re looking for?

  2. Thank you. No, I think I just need to read more on interfaces and OO in general to get a better understanding of how some of these things fit in the foundation of the language.

Leave a Reply

Your email address will not be published. Required fields are marked *