views:

218

answers:

5

I am getting ready to create a generic EventArgs class for event args that carry a single argument:

public class EventArg<T> : EventArgs
{
    // Property variable
    private readonly T p_EventData;

    // Constructor
    public EventArg(T data)
    {
        p_EventData = data;
    }

    // Property for EventArgs argument
    public T Data
    {
        get { return p_EventData; }
    }
}

Before I do that, does C# have the same feature built in to the language? I seem to recall coming across something like that when C# 2.0 came out, but now I can't find it.

Or to put it another way, do I have to create my own generic EventArgs class, or does C# provide one? Thanks for your help.

+14  A: 

No. You probably were thinking of EventHandler<T>, which allows you to define the delegate for any specific type of EventArgs.

I personally don't feel that EventArgs<T> is quite as good of a fit, though. The information used as a "payload" in the event args should be, in my opinion, a custom class to make it's usage and expected properties very clear. Using a generic class will prevent you from being able to put meaningful names into place. (What does "Data" represent?)

Reed Copsey
Thanks, Reed. That's exactly what I was thinking of.
David Veeneman
+2  A: 

Or to put it another way, do I have to create my own generic EventArgs class, or does C# provide one?

Have to create your own. There are some samples already out there, like this one... http://www.c-sharpcorner.com/UploadFile/rmcochran/customgenericeventargs05132007100456AM/customgenericeventargs.aspx

kekekela
Best to not make a generic one, though; keep with the existing pattern for EventArgs classes, since anything not embarassingly trivial will likely require creation of a new class to use with the generic one anyway.
Chris Charabaruk
A: 

The reason this does not exist is because what would end up happening is you implement this, and then when you go to fill in the T you should create a class with strongly typed unambiguous properties that acts as the data bag for your event arg, but halfway through implementing that you realize there's no reason you don't just make that class inherit from EventArgs and call it good.

Unless you just want a string or something similarly basic for your data bag, in which case there are probably EventArgs classes standard in .NET which are meant to serve whatever simple purpose you're getting at.

Jimmy Hoffa
+1, would upvote again.
Chris Charabaruk
-1. I have EXACTLY this sitaution now, and my payload would be an immutable object that is a "message" coming from a bus... and isu sed in other places, too. The custom EventArgs.... creates a redundant class here. Unusual, but the application is so.
TomTom
A: 

The problem with a generic type is that even if DerivedType inherits from BaseType, EventArgs(DerivedType) would not inherit from EventArgs(BaseType). Using EventArgs(BaseType) would thus prevent later using a derived version of the type.

supercat
A: 

I must say I don't understand all the 'purists' here. i.e. if you already have a bag class defined - which has all the specifics, properties etc. - why the hack create one extra unnecessary class just to be able to follow the event/args mechanism, signature style? thing is - not everything that is in .NET - or is 'missing from' for that matter - is 'good' - MS's been 'correcting' itself for years... I'd say just go and create one - like I did - cause I needed it just like that - and saved me lot of time,