It is common practice in C# when creating an event, to define it as follows, taken from an example in the .NET Framework Guidelines:
public class CustomEventArgs : EventArgs
{
public CustomEventArgs(string s)
{
msg = s;
}
private string msg;
public string Message
{
get { return msg; }
}
}
...
public delegate void CustomEventHandler(object sender, CustomEventArgs a);
Often, I create events which don't need any arguments at all. I usually implement this simply using Action
for the event handler type.
public event Action LogonScreenExited;
I was wondering whether there is any reason why one would want to follow the 'traditional' pattern. Perhaps events like this indicate a design flaw? My reasoning however for using Action
is YAGNI, why implement something (and even show intent of) when it isn't used?
In programming, an event handler is a callback routine that operates asynchronously once an event takes place. It dictates the action that follows the event. The programmer writes a code for this action to take place. An event is an action that takes place when a user interacts with a program.
Yes, you can declare an event without declaring a delegate by using Action. Action is in the System namespace.
Use the EventHandler delegate for all events that do not include event data. Use the EventHandler<TEventArgs> delegate for events that include data about the event. These delegates have no return type value and take two parameters (an object for the source of the event, and an object for event data).
The EventHandler delegate is a predefined delegate that specifically represents an event handler method for an event that does not generate data. If your event does generate data, you must use the generic EventHandler<TEventArgs> delegate class.
It is not a requirement, merely a design guide.
You'll need to keep in mind that you cannot predict how the client code is going to use the event and you cannot predict the future. The sender argument is useful to the client programmer, it lets him use a single event handler method that handles events from multiple event sources. Deriving from EventArgs is useful since it lets you refactor the event, deriving from the original base class and adding extra arguments, without breaking the client code. You are free to ignore the benefits of this approach.
Because you can write a generic event handler and use it for many different kind of events (like a logging facility) taking advantage of contravariance in delegates.
Here's an example from the msdn:
// Event hander that accepts a parameter of the EventArgs type.
private void MultiHandler(object sender, System.EventArgs e)
{
label1.Text = System.DateTime.Now.ToString();
}
public Form1()
{
InitializeComponent();
// You can use a method that has an EventArgs parameter,
// although the event expects the KeyEventArgs parameter.
this.button1.KeyDown += this.MultiHandler;
// You can use the same method
// for an event that expects the MouseEventArgs parameter.
this.button1.MouseClick += this.MultiHandler;
}
Other than this, it is only a design guide, a recommended way. Following it makes your code maintainable and consistend with the rest of the .NET, helping a lot who will be using your classes.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With