What is the preferred practice for event arguments provided by custom events?

Question

In regards to custom events in .NET, what is the preferred design pattern for passing event arguments? Should you have a separate EventArgs derived class for each event that can be raised, or it is acceptable to have a single class for the events if they are all raised by events from the same class?

Answer 1

It depends on what the events are, but for the most part, for the sake of whoever is going to consuming your events, create a single custom class deriving from EventArgs.

Answer 2

I typically create a base EventArgs class that has common data for each event. If a particular event has more data associated with it, I create a subclass for that event; otherwise I just use the base class.

Answer 3

I would, like OAB, create a custom 'base' args class that extends EventArgs by adding data specific to the component or application I use it in. E.g. in an accounting export application, my base ExportEventArgs would add an AccountNo property.

Answer 4

You don't need to have a separate EventArgs derived class for each event. It's perfectly acceptable and even desirable to use existing EventArgs-derived classes rather than reinventing the wheel.

These could be existing framework classes (e.g. System.Component.CancelEventArgs if all you want to do is give the event handler the possibility to cancel an action.

Or you can create your own EventArgs-derived classes if you have data specific to your application to pass to event handlers. There is no reason why two events from the same class or different classes shouldn't use the same EventArgs-derived class if they are sending the same data.