Custom EventArgs classes should be derived from System.EventArgs (or System.CancelEventArgs)

[ghost]

Please change the implementations of all custom EventArgs classes in the Microsoft.Web.WebView2.Core namespace to be subclasses of System.EventArgs (or System.CancelEventArgs where appropriate) as prescribed in Events (C# Programming Guide).

Raising Event types that are not derived from System.EventArgs breaks interoperability with various WPF- and WinForms-related libraries and frameworks such as Microsoft.Xaml.Behaviors.

Examples of requested changes:

• CoreWebView2SourceChangedEventArgs should be implemented as
  public class CoreWebView2SourceChangedEventArgs : System.EventArgs { ... }

• CoreWebView2NavigationStartingEventArgs should be implemented as
  public class CoreWebView2NavigationStartingEventArgs : System.CancelEventArgs { ... }

AB#26932796

[pagoe-msft]

@djoe47441 thanks so much for bringing this up - we will look into this. Could you explain some scenarios where interoperability with WPF/WinForms libraries is broken?

[ghost]

Sure, no problem.

Several WPF-related frameworks (e.g. Microsoft.Xaml.Behaviors.Wpf, MVVM Light Toolkit) provide adapters between

• Control Events

and either

• Commands (e.g. MVVM Light Toolkit's EventToCommand, Microsoft.Xaml.Behaviors.Wpf's EventTriggerBehavior/InvokeCommandAction) or
• Method Calls (e.g. Microsoft.Xaml.Behaviors.Wpf's EventTriggerBehavior/CallMethodAction)

in order to decouple the ViewModel implementation of the event handling code from the View components in an MVVM-based architecture (see Sample Code).

Detailed analysis for Microsoft.Xaml.Behaviors.Wpf
When subscribing to an Event, the implementation of Microsoft.Xaml.Behaviors.Wpf's EventTriggerBase contains explicit code to verify the argument types of the targeted Events to be derived from System.EventArgs.

This will cause the EventTriggerBehavior to fail on all Events raised by WebView2 that do not follow the convention for Event signatures in C#.
End detailed analysis

I sincerely hope that I will be excused for not presenting similarly detailed proof for all other relevant MVVM-frameworks, or their WinForms-facing counterparts. Especially since my project depends on MXBW.

Suffice it to say that the WebView component being replaced by WebView2 does observe the convention for Event signatures in C# and consequently works well with Microsoft.Xaml.Behaviors.Wpf.

[ghost]

BTW: Apologies for citing the wrong *Behaviors-project in my initial post - I did mean to point to Microsoft.Xaml.Behaviors.Wpf in the first place.

[champnic]

This should now be available in WebView2 SDK 1.0.674-prerelease - our .NET events are derived from System.Event where applicable. If this is still an issue please let us know. Thanks!