Add RaiseEvent generic extension method

[mwpowellhtx]

Add a convenience extension method allowing for contemporary and planned language level features to be more prominently used.

namspace System.Windows
{
    // EventManager is already static, so this seems like the best placement for it
    public static class EventManager
    {
        public static void RaiseEvent<TArguments>(this DependencyObject source, TArguments e)
            where TArguments : RoutedEventArgs => source.RaiseEvent(e);

        // Then if folks wish to be a little more strict about the arguments, they can be
        public static void RaiseEvent<TSource, TArguments>(this TSource source, TArguments e)
            where TSource : DependencyObject
            where TArguments : RoutedEventArgs => source.RaiseEvent(e);
    }
}

And in practical usage, assuming appropriate event declarations, etc:

public class BubblesManager
{
    public static void RaiseEvent(DependencyObject source, int bubbles)
        => source.RaiseEvent<BubblesRoutedEventArgs>(new(BubblingEvent, source, bubbles));
        //                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
}

For sake of example:

public class BubblesRoutedEventArgs : RoutedEventArgs
{
    public int Bubbles { get; }

    internal BubblesRoutedEventArgs(RoutedEvent routedEvent, object source, int bubbles)
        : base(routedEvent, source)
        //     ^^^^^^^^^^^  ^^^^^^
    {
        Bubbles = bubbles;
    }
}

Tangentially, although at first glance, it seems counterintuitive why we would need to relay the RoutedEventArgs.RoutedEvent, especially given the event mechanism. Might seem better to do something like:

source.RaiseEvent(BubblesEvent, e);

And then since DependencyObject is handling the decoupled bookkeeping for us, we can focus more on the arguments properties themselves without having to also concern ourselves with the bookkeeping, even in raising the event.

[mwpowellhtx]

Maybe not an extension method, more akin to a UIElement method:

namespace System.Windows;

public class UIElement
{
    // ...
    private void OnRaisedEvent(RoutedEventArgs e) { /* ... */ }
    public void RaiseEvent(RoutedEventArgs e) => OnRaisedEvent(e);
    public void RaiseEvent<TArguments>(TArguments e) where TArguments : RoutedEventArgs => OnRaisedEvent(e);
    // ...
}

Anyway, you get the idea.

[miloush]

allowing for contemporary and planned language level features to be more prominently used.

What do you mean by this? Which language features?

Why do you need a generic method, what benefit does it have?

[mwpowellhtx]

allowing for contemporary and planned language level features to be more prominently used.

What do you mean by this? Which language features?

Why do you need a generic method, what benefit does it have?

I illustrated the benefit in the RaiseEvent example, i.e. new(BubblingEvent, source, bubbles), or more specifically, source.RaiseEvent<BubblesRoutedEventArgs>(new(BubblingEvent, source, bubbles)).

[lindexi]

It seems like an intriguing proposition, but the improvements appear to be minimal and it doesn’t seem to offer much convenience. Nonetheless, I appreciate your suggestion as it can spark inspiration.

[mwpowellhtx]

No problem. Admittedly, the scope is small, yes; that is my particular focus right at the moment, as I am evaluating attached routed events, whether it might help in an opportunity I have at the moment. I did not assess other functions, whether generic versions might benefit there as well.