Generic GwenEventHandler (aka Massive Code-Breaking Change (that needed to be done))

[halfof...@gmail.com]

Basically, it all boils down to this one change (that has been needed for a long time):

 

/// <summary>
/// Delegate used for all control event handlers.
/// </summary>
/// <param name="control">Event source.</param>
/// <param name="args" >Additional arguments. May be empty (EventArgs.Empty).</param>
public delegate void GwenEventHandler<in T>(Base sender, T arguments) where T : System.EventArgs;

Now, the basic GwenEventHandler takes in a 2nd argument. This 2nd argument should be event specific arguments. Right now, almost all events use the basic EventArgs and return EventArgs.Empty, however I implemented a few like ClickedEventArgs that pass around an X, Y, and MouseDown, as well as an ItemSelectedEventArgs, that should carry the newly selected (or unselected, if you are an OnUnselectedEvent) Base item.

I've also changed the first argument name to be "sender". I want it to be explicitly clear that 'sender' is the object you bound the event to, and not just some generic control that may be event specific.

If we need to pass event arguments for an event in the future, just make a new class that inherits from System.EventArgs, change the event type, and we're good, and it requires minimal changes (if any) for the end-user. Since all 2nd arguments inherit from type EventArgs, if we change the argument type in the future, it shouldn't break their code since it will cast down (untested, but it SHOULD do that).

ie:

public event GwenEventHandler<EventArgs>OnClicked;

//changed to...

public event GwenEventHandler<ClickedEventArgs>OnClicked;

This breaks a lot of end-user code, but it is something that needed to be done, and this seems like the most correct way to do it. To fix your code, simply make a 2nd argument "EventArgs args" and ignore it.

public void CopyText(Base sender){
 sender.UserData.CopyTheText();
}

//changed to...

public void CopyText(Base sender, EventArgs args){
 sender.UserData.CopyTheText();
}

If you have any questions or concerns, this would be the place to discuss them. Hope you all agree with how it was designed. :)

[halfof...@gmail.com]

I've confirmed the "if we change the argument type in the future, it shouldn't break their code since it will cast down (untested, but it SHOULD do that)."

To state explicitly how it works: If we change the 2nd argument type in the future (from EventArgs to something else), it will not break the end-user code. This is because the 2nd argument type must be assignable from EventArgs (the 'where T : System.EventArgs' part).