事件处理程序 <T> 和EventHandler

Question

I want to ask the different between EventHandler and EventHandler<T> .

Previously I have implemented a EventHandler , with a custom EventArgs which can be passed to the parent page from the user control.

I thought I need to apply EventHandler< T > , however it can be implemented by using EventHandler . (in fact there is weird error when I trying to apply EventHandler<T> , the program is worked but error is shown in the IDE which I couldn't solve [ C# Custom EventHandler ])

Thus, I want to know in what situation I need to apply EventHandler < T > ?

public event EventHandler AppendProcess;
public event EventHandler<MyEventArg> AppendProcess;

---Update--- this is how I invoke the event in the user control (as i said, i can pass object to parent page by doing this (although i don't know if it is correct to do so)

if (AppendProcess == null) { }
else
    AppendProcess(this, new Common.WinLose_ProgressStage(Common.WinLose_SP_Parameter.upper, displayLevel + 1, 
                                                            (int)Common.WinLose_Level.lvChild4, thename, refundratio, 
                                                            selfproportion, -1, -1, loadlevel, isPlayer, betsource, gamecategory, false));

Answer 1

EventHandler<T> is just a generic EventHandler type, which avoids you having to declare a new delegate type for each kind of EventArgs you want to use.

Consider Control.KeyPress for example. It's declared as an event of type KeyPressEventHandler . That delegate is just declared as:

public delegate void KeyPressEventHandler(object sender, KeyPressEventArgs e)

If EventHandler<T> (and generics) had been around when that was created, the event could have been declared as an EventHandler<KeyPressEventArgs> instead, saving a delegate declaration. There are many, many delegates which are just like EventHandler , and only vary in the type of the second parameter - EventHandler<T> avoids that redundancy.

No if you don't have your own custom EventArgs subclass, there's no reason to use EventHandler<T> ... but if you do, it's much better to use it, so that the method handling the event receives your custom EventArgs subclass in a strongly-typed way.

As an aside, your way of invoking the event handler isn't thread-safe. Another thread could unsubscribe the final event handler after your nullity check. If you're using C# 5, you should write it as:

var handler = AppendProcess;
if (handler != null)
{
    handler(this, new Common.WinLose_ProgressStage(...));
}

If you're using C# 6 or later, you can use the null conditional operator:

// If AppendProcess is null, the arguments won't even be evaluated
AppendProcess?.Invoke(this, new Common.WinLose_ProgressStage(...));

Answer 2

EventHandler<T> is the generic variant of EventHandler . Usually, you would override EventArgs and EventHandler to come up with an own event type. You still need to derive EventArgs if you want to pass in custom properties to the e argument, but you don't need to create a custom delegate for EventHandler any more. You now can just say:

public event EventHandler<SomeEventArgs> SomeEvent;

Which is more convenient than:

public delegate void SomeEventHandler(object sender, SomeEventArgs e);

public event SomeEventHandler SomeEvent;

When your delegate signature doesn't change, EventHandler<T> is much more straightforward to use.

Answer 3

From your other question:

 Common.WinLose_ProgressStage wps = (Common.WinLose_ProgressStage)e; 

That's a cast that could potentially fail, depending on how the method is invoked. There is nothing guaranteeing that your event handler only gets called with Common.WinLose_ProgressStage that can be inspected without checking your full program. It could be called with a plain EventArgs too: you made that possible by making the parameter type EventArgs .

EventHandler<T> causes more compile-time type checking. If other code attempts to pass in EventArgs.Empty , the call would simply fail to compile.

It's basically the same as "why shouldn't I make all my parameters of type object "? Sure, you could do that. And if you do that, casting back wherever needed, your code would work. But I know I prefer

long Add(long x, long y) { return x + y; }

over

object Add(object x, object y) { return (long)x + (long)y; }

and I suspect that in this case, you do too. Yet this is exactly what you're doing when you make the parameter type EventArgs rather than Common.WinLose_ProgressStage .