RoutedEventArgs vs EventArgs

Berryl picture Berryl · Sep 15, 2009 · Viewed 14.4k times · Source

I am learning WPF / Silverlight and saw in an MS vidcast that it is now recommended to use RoutedEventArgs over EventArgs; although it didn't say exactly why.

I have a win forms app that uses interfaces for "widgets" in an attempt to not be tied to a specific display technology (in Presenters / ViewModels), so if my IButton Click event now needs to take the RoutedEventArgs now I guess it isn't as useful.

Can someone please explain if I should switch to RoutedEventArgs in all cases and why?

As an aside, does anyone else have experience / opinions about using interface widgets as I'm describing them?

Answer

Carlo picture Carlo · Sep 15, 2009

Well, basically a RoutedEvent travels through the Logical tree, either from the source element to root element (Bubble event route) or, less frequently from root element to sub levels elements (Tunnel event route). What this means is that if you have a Button inside of a StackPanel, that itself is inside of a Grid; if you define a Click event in the controls they will all trigger it unless one of them handles it.

If the event route is Bubble (named as a regular event Click), it will go:

Button -> StackPanel -> Grid

If the event route is Tunnel (named PreviewClick), it will go the other way around:

Grid -> StackPanel -> Button

So now with the handling, it's pretty simple. If it's a Bubble route and the Button sets the RoutedEventArgs.Handled to true, that StackPanel and Grid will not trigger it. Same with the RoutedEvent, if the Grid handles it, the StackPanel and Button will not trigger it.

This is my understanding in a nutshell, I avoided some stuff for simplicity.

I recommend this chapter for better understanding of this WPF feature.