Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I don't think there's anything wrong with what you want to do. For the most part, I suspect that the <code>object sender</code> parameter remains in order to continue to support pre 2.0 code.</p> <p>If you really want to make this change for a public API, you might want to consider creating your own base EvenArgs class. Something like this:</p> <pre><code>public class DataEventArgs&lt;TSender, TData&gt; : EventArgs { private readonly TSender sender, TData data; public DataEventArgs(TSender sender, TData data) { this.sender = sender; this.data = data; } public TSender Sender { get { return sender; } } public TData Data { get { return data; } } } </code></pre> <p>Then you can declare your events like this</p> <pre><code>public event EventHandler&lt;DataEventArgs&lt;MyClass, int&gt;&gt; SomeIndexSelected; </code></pre> <p>And methods like this:</p> <pre><code>private void HandleSomething(object sender, EventArgs e) </code></pre> <p>will still be able to subscribe.</p> <p><strong>EDIT</strong></p> <p>That last line made me think a bit... You should actually be able to implement what you propose without breaking any outside functionality since the runtime has no problem downcasting parameters. I would still lean toward the <code>DataEventArgs</code> solution (personally). I would do so, however knowing that it is redundant, since the sender is stored in the first parameter and as a property of the event args.</p> <p>One benefit of sticking with the <code>DataEventArgs</code> is that you can chain events, changing the sender (to represent the last sender) while the EventArgs retains the original sender.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload