Does .Net Have a Built-In Eventargs<T>

Does .NET have a built-in EventArgsT?

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 its 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?)

Is there anything readily available in the .NET framework of the form EventArgsT?

No. Mainly because it fails the tests posed before something it added to the framework

• How useful is it? (Marginly -- only useful if you only need one data member. As opposed to EventHandler<> which is good for event handler regardless of the number of parameters used.)
• How hard is it to write yourself? (not very hard)
• Is it needed in the framework itself? (No. Distinct classes are used, so new members could be added in the future if needed. As opposed to Func<> & Action<> which are used by the framework.)

(UPDATED based on comments)

Why can't I just use EventHandlerint instead of deriving from EventArgs

If all you need to do is pass an int to the handler then what you are doing is fine.

It used to be the case (before .NET 4.5) that the EventHandler type argument TEventArgs was constrained to inherit from EventArgs but not anymore:

public delegate void EventHandler<TEventArgs>(object sender, TEventArgs e);

The fact that MS dropped the constraint should tell you that they were being too strict and what you are doing is fine.

In the case that you need to pass a complex type to the handler then you might aswell inherit EventArgs for reasons of polymorphism. Also, the EventArgs.Empty member is useful.

Generic EventArgs for built-in types

Short answer: it depends.

You can consider EventArgs<T> class like Tuple<T> for passing and returing data to/from the method. In some simple cases and for internal usage Tuple<T> is appropriate but for more complex cases or for public surface it would be more appropriate to use separate type.

With EventArgs<T> we have more or less the same dilema. For internal usage its OK to use this type, but for public API it could lead to maintainance nightmare.

In your particular case it seems OK to use EventArgs<T> at the first glance, but what if later you'll decide to add some additional information to this even like EndPoint? In this case you can use EventArgs<T, U> (like Tuple<T, U>) or you can switch to custom EventArgs class. In both case you'll break all your clients and if you only one client of this code - its ok, but if not...

Bottom line, for internal stuff its ok to use EventArgs, but for public surface I suggest to use custom event args.

P.S. General naming convention for events is CamelCase, and in your particular case it means that DataReceived is more appropriate name for your event.

.NET EventHandlers - Generic or no?

Delegate of the following form has been added since .NET Framework 2.0

public delegate void EventHandler<TArgs>(object sender, TArgs args) where TArgs : EventArgs

You approach goes a bit further, since you provide out-of-the-box implementation for EventArgs with single data item, but it lacks several properties of the original idea:

1. You cannot add more properties to the event data without changing dependent code. You will have to change the delegate signature to provide more data to the event subscriber.
2. Your data object is generic, but it is also "anonymous", and while reading the code you will have to decipher the "Item" property from usages. It should be named according to the data it provides.
3. Using generics this way you can't make parallel hierarchy of EventArgs, when you have hierarchy of underlying (item) types. E.g. EventArgs<BaseType> is not base type for EventArgs<DerivedType>, even if BaseType is base for DerivedType.

So, I think it is better to use generic EventHandler<T>, but still have custom EventArgs classes, organized according to the requirements of the data model. With Visual Studio and extensions like ReSharper, it is only a matter of few commands to create new class like that.

Ok to use DataEventArgsTData instead of customized event data class?

There's little reason not to use a generic EventArgs subclass for non-public events. However, for events that are part of a truly public API, things get a bit trickier due to potential backward compatibility concerns. For a publicly consumed event, creating an event-specific EventArgs subclass would give you flexibility to add members without affect the API consumers.

For an event that is not part of a public API, there would still be a bit of potential rework to be done if the EventArgs subclass was changed for a particular event because the generic subclass was no longer a good fit. However, this should usually be fairly minimal, and the compiler should catch any problems (whether explicit or anonymous handler methods are used). Obviously, there's a trade-off to be made there between the initial development effort and the potential change effort -- fwiw, I use a generic EventArgs for internal events where it's a good fit, and I've rarely needed to change one after initial release.

Generic built-in EventArgs to hold only one property?

I do not think there is.

Looks like you are not the only one to ask himself this question.

Take a look here

Should EventArgs contain EventArgs?

Personally it doesn't matter too much to me, but I would go for 2.

It just looks cleaner and I think it will be easier in use. It does need additional coding which could result in extra mistakes, but I wouldn't worry to much about it.

---

Related Topics