Does inheritance matter with events and delegates?

Question

I've been reading up on delegates, event and WPF for some days now and I am starting to get some understanding of it but there are a few things that is unclear to me.

In this question they explained on how to raise an event on a property is changed.

From what I've understood when it comes to event is that you want to do something when they happend, and that you need to add an function to an event like so

Someclass.PropertyChanged += new PropertyEventHandler(somefunction)

public void somefunction(object sender, EventArgs e){ //Do some code}

But almost in every example, when they use INotifyPropertyChanged that is never used, but they somehow manage to activate the event PropertyChanged.

I can't really make sense of it.

Do you need to add function to a new eventhandler if you implement an interface with an already declared event?

Incomplete and unclear. Create a minimal sample. – H H Mar 20 '17 at 20:19 — H H, Mar 20 '17 at 20:19

15ee8f99-57ff-4f92-890c-b56153 · Accepted Answer · 2017-03-22T12:58:40.300

1

No need to give it a handler. You implement PropertyChanged so some other code can handle the event. That other code might be yours, but in the case of INotifyPropertyChanged, it's usually the bindings in your views that'll subscribe to your PropertyChanged events.

You can declare an event without adding your own handler to it. You really ought to raise the event once you bothered declaring it, but you don't have to handle it. By raising it, I mean like this:

protected void OnPropertyChanged(String propName)
{
    var handler = PropertyChanged;

    //  If nobody gave it a handler, it'll be null, so check for that. 
    if (handler != null)
    {
        //  This is what we refer to when we say "raise the event": handler has 
        //  references to at least one handler (because it's not null), and possibly
        //  dozens. This one "method call" here will magically call all of them. 
        handler(this, new PropertyChangedEventArgs(propName));
    }
}

public String Name {
    get { return _name; }
    set {
        if (_name != value) {
            _name = value;
            //  Call this method to raise PropertyChanged
            OnPropertyChanged("Name");
        }
    }
}
private String _name;

Declaring an event is just saying "In case anybody cares about this thing happening, here's an event that I'll raise when it happens."

Maybe you want to handle that event in some other part of your own code. In WPF, you implement INotifyPropertyChanged so when the user interface has bindings to the properties of an instance of your class, it'll get the notifications it needs.

edited Mar 22 '17 at 12:58

answered Mar 20 '17 at 20:19

15ee8f99-57ff-4f92-890c-b56153

36,786
7
62
114

But if you don't invoke the event with something, isn't it useless? – Bojje Mar 20 '17 at 22:46
@Bojje what do you mean by "invoke"? Are you talking about raising the event, or handling the event? I tried to address both in my answer. – 15ee8f99-57ff-4f92-890c-b56153 Mar 20 '17 at 22:49
No sorry it's really late.. Going to get some sleep and get back to this tomorrow :) Glad if you could answer me then. – Bojje Mar 20 '17 at 22:50
@Bojje At any rate, yes, if you never raise an event, don't bother implementing it. If you can be certain that nobody will ever handle the event, then you don't need to implement it either. A lot of classes do not need to implement INotifyPropertyChanged. However, many of them do. If the class has properties which will be bound to control properties in a view, and if there is any chance that those properties will change outside of the constructor, it needs to implement that interface. – 15ee8f99-57ff-4f92-890c-b56153 Mar 20 '17 at 22:51
Okey let's see if I can make more sense now. When you mean raise an event do you mean `OnPropertyChanged` ? Cause the way I see it is that this is just a function? so if you dont use `Someclass.PropertyChanged += new EventHandler(//some code)` that "actually" do something when the event has happend, doesn't it make the event completley "useless"? – Bojje Mar 21 '17 at 12:14
@Bojje If your class implements `INotifyPropertyChanged`, you're promising the compiler that you will have a `PropertyChanged` event with the right delegate type, and the compiler will refuse to compile your code until you keep that promise. If that's unnecessary with your class, don't promise to do it. I don't understand why this bothers you. When you write a class, think like you're writing a framework. Provide what reasonable people may need from your class. It's OK if some parts go unused, but if you blow off something they turn out to need, you failed to do your job. – 15ee8f99-57ff-4f92-890c-b56153 Mar 21 '17 at 12:50
@Bojje Your next question should be "OK, give me a general definition of reasonable!" Which I can't do. What I have instead is a heuristic: What Would the Framework Do? If you're writing winforms code, ask yourself how the winforms team would write the class. If you're writing WPF code, ask yourself how the WPF team would write it. Then your users will know what to expect, and you'll be stealing the successful results of a lot of hard thought and usability testing from some brilliant, lavishly-funded guys. – 15ee8f99-57ff-4f92-890c-b56153 Mar 21 '17 at 12:56

Does inheritance matter with events and delegates?

1 Answers1