Click here to Skip to main content
15,868,016 members
Articles / Programming Languages / C#
Tip/Trick

Generic Event Handler Using Extension Method

Rate me:
Please Sign up or sign in to vote.
2.22/5 (4 votes)
31 Oct 2013CPOL 23.9K   4   20
A handy approach to raise events.

Introduction

Very often we need to invoke events, usually in Model classes , where we set some property and raise an event in order to notify any listeners. 

Using the code

Following is a full length example of 'How to use a Generic Event Handler to Raise an Event'.

It is good to have some helper (extension) method that can be used at various places, thus reducing the amount of code and making it quite maintainable.

C#
using System;
using ExtensionHelper;

namespace EventHandlers
{
    public class MyModel
    {
        private string _name;
        private int _age;
        private decimal _salary;

        MyModel() { }

        public string Name
        {
            get { return _name; }
            set 
            {
                _name = value;
                NameChanged.Raise(this, EventArgs.Empty);
            }
        }

        public int Age 
        { 
            get { return _age; } 
            set 
            {
                _age = value;
                AgeChanged.Raise(this, EventArgs.Empty);
            } 
        }

        public decimal Salary 
        { 
            get { return _salary; } 
            set 
            { 
                _salary = value;
                SalaryChanged.Raise(this, EventArgs.Empty);
            }
        }

        public EventHandler NameChanged;
        public EventHandler AgeChanged;
        public EventHandler SalaryChanged;

    }

}

namespace ExtensionHelper
{
    public static void Raise(this EventHandler eventHandler, object sender, EventArgs e)
    {
        if (eventHandler != null)
        {
             eventHandler(sender, e);
        }
    }

    public static void Raise<T>(this EventHandler<T> eventHandler, 
           object sender, T e) where T : EventArgs
    {
        if (eventHandler != null)
        {
            eventHandler(sender, e);
        }
    }
}

History

This is my first article on CodeProject, and I am using the above mentioned code in my current assignments.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


Written By
Software Developer
India India
I am a Software Developer By Profession.

Comments and Discussions

 
GeneralMy vote of 1 Pin
Athari1-Nov-13 5:25
Athari1-Nov-13 5:25 
GeneralMy vote of 1 Pin
johannesnestler1-Nov-13 0:49
johannesnestler1-Nov-13 0:49 
QuestionThere is also a possibility for null exception there due to a well known race condition when dealing with events Pin
Sacha Barber31-Oct-13 7:03
Sacha Barber31-Oct-13 7:03 
AnswerRe: There is also a possibility for null exception there due to a well known race condition when dealing with events Pin
Athari31-Oct-13 9:58
Athari31-Oct-13 9:58 
GeneralRe: There is also a possibility for null exception there due to a well known race condition when dealing with events Pin
johannesnestler1-Nov-13 0:14
johannesnestler1-Nov-13 0:14 
GeneralRe: There is also a possibility for null exception there due to a well known race condition when dealing with events Pin
Athari1-Nov-13 2:48
Athari1-Nov-13 2:48 
GeneralRe: There is also a possibility for null exception there due to a well known race condition when dealing with events Pin
johannesnestler1-Nov-13 4:44
johannesnestler1-Nov-13 4:44 
GeneralRe: There is also a possibility for null exception there due to a well known race condition when dealing with events Pin
Athari1-Nov-13 5:03
Athari1-Nov-13 5:03 
GeneralRe: There is also a possibility for null exception there due to a well known race condition when dealing with events Pin
johannesnestler1-Nov-13 5:53
johannesnestler1-Nov-13 5:53 
GeneralRe: There is also a possibility for null exception there due to a well known race condition when dealing with events Pin
Athari1-Nov-13 6:31
Athari1-Nov-13 6:31 
GeneralRe: There is also a possibility for null exception there due to a well known race condition when dealing with events Pin
johannesnestler1-Nov-13 8:34
johannesnestler1-Nov-13 8:34 
AnswerRe: There is also a possibility for null exception there due to a well known race condition when dealing with events Pin
Bheeshm31-Oct-13 16:49
professionalBheeshm31-Oct-13 16:49 
QuestionNot following the convention... Pin
johannesnestler31-Oct-13 5:57
johannesnestler31-Oct-13 5:57 
AnswerRe: Not following the convention... Pin
OriginalGriff31-Oct-13 6:37
mveOriginalGriff31-Oct-13 6:37 
AnswerRe: Not following the convention... Pin
Bheeshm31-Oct-13 16:55
professionalBheeshm31-Oct-13 16:55 
GeneralRe: Not following the convention... Pin
johannesnestler1-Nov-13 0:46
johannesnestler1-Nov-13 0:46 
Hi Bheeshm,

So I try to elaborate what I mean.

* If you raise an Event from variouse places this can quickly lead to a maintanance nighmare - therefore we have a "convention" not to raise the same event from variouse places, but from a single "Point" - this is the On[EventName] method you can see everywhere in the framework. The other "twist" with this pattern is that you can completly disable the event in derived classes.

So the pattern is:

C#
EventHandler<SomeEventArgs> SomeEvent;

C#
protected virtual void OnSomeEvent(SomeEventArgs sea)
{
// Raise event here as Sasha showed (pinning handler variable locally)
}



Have also a look at the naming of the 3 parts: Event, EventArgs, name of the method raising the event. This is another convention.

So in the variouse parts of your codes in your class which needs to raise the Event you call the On method to raise the Event for you (giving it the needed (different) EventArgs as argument.

Another important thing:
* If this is a "Model" class (MVVM) you should implement INotifyPropertyChanged interface http://msdn.microsoft.com/en-us/library/system.componentmodel.inotifypropertychanged(v=vs.110).aspx[^]
This is another "convention" you are breaking (but this time your code won't work in some circumstances, cause some framework features are depending on it)

So your solution:

* Raises the same event (through your generic "raiser" from variouse places, no chance to disable it for derived types)
* Breaks the convention and therefore may be harder for others to understand
* Doesn't consider multithreaded scenarios (Sashas comment) and can lead to VERY nasty bugs.
* Your sample doesn't give the changed values to the events (shouldn't always use the generic variant with some specific EventArgs types?)
* Your method needs the parameter for the object raising the event (On... method pattern doesn't)
* Your Model classes should really implement INotifyPropertyChanged/-Changing pattern!

The only good thing I can see about your solution is: It saves some typing, and as I mentioned I can be much faster creating the whole pattern with a code snippet. (I can give it to you if you want - just have to change the german commenting... (Even the comments for this pattern follow always the same convention in the framework!)

But don't be sad about this topic, you tried to find a way for yourself, put the efford in to write this tip, and now you may learn that there is a convention and may decide to follow it.

Kind Regards Johannes
GeneralRe: Not following the convention... Pin
Bheeshm1-Nov-13 2:23
professionalBheeshm1-Nov-13 2:23 
GeneralRe: Not following the convention... Pin
johannesnestler1-Nov-13 5:00
johannesnestler1-Nov-13 5:00 
GeneralRe: Not following the convention... Pin
Athari1-Nov-13 5:20
Athari1-Nov-13 5:20 
GeneralRe: Not following the convention... Pin
johannesnestler1-Nov-13 5:59
johannesnestler1-Nov-13 5:59 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.