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?
Well, basically a
RoutedEventtravels through theLogicaltree, either from the source element to root element (Bubbleevent route) or, less frequently from root element to sub levels elements (Tunnelevent route). What this means is that if you have aButtoninside of aStackPanel, that itself is inside of aGrid; if you define aClickevent in the controls they will all trigger it unless one of them handles it.If the event route is
Bubble(named as a regular eventClick), it will go:Button -> StackPanel -> GridIf the event route is
Tunnel(namedPreviewClick), it will go the other way around:Grid -> StackPanel -> ButtonSo now with the handling, it’s pretty simple. If it’s a
Bubbleroute and theButtonsets theRoutedEventArgs.Handledto true, thatStackPanelandGridwill not trigger it. Same with theRoutedEvent, if theGridhandles it, theStackPanelandButtonwill 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.