One of the readers of my earlier post on routing and bubbling was left confused about when events are bubbled and when they are not.
The documentation is clearer about this in some places than in others. For example, the Mouse events documentation has this to say:
There are two things to notice here. One is that this particular documentation does clearly distinguish those events that bubble from those that do not.
The second is that the first sentence unfortunately seems to equate being a routed event with bubbling. What I think it means to say is "are routed events that bubble"
The documentation shows that MouseEnter (which does not bubble) is an event of type MouseEventHandler
and MouseEventHandler is a delegate for three non bubbling events:
So.... we can safely conclude that
- All bubbling events are routed events but
- Not all routed events bubble
( All C# Programmers are human, but not all humans are C# Programmers * )
So which events Do and Do Not Bubble and Why?
One rule seems to be that any event specific to a control does not bubble. That means that Button.Click and Slider.ValueChanged do not bubble.
Wait a minute! What would it mean for Slider.ValueChanged to bubble? Where would it bubble to? What could contain a slider that could possibly do anything with the ValueChanged event? Clearly that event needs to go to the Slider and nowhere else.
Okay, what about a ListBox which has SelectionChanged. Where should that bubble to?
We're beginning to see the pattern. Most of the time, it doesn't make sense for the events specific to a given control to bubble.
(Clearly not all of the time - Click is a good example where you might want a control event to bubble, but you can work around that as we did in the previous example with mouse up.)
In WPF you can decide because there are three types of Routed Events (Bubbling, Direct and Tunneling). In Silverlight, for Beta 1 at least, what has been put in place is that control-specific events do not bubble and what does bubble is many (though not all) of the more fundamental events such as MouseDown/Up/Move, which lets you get what you want, though not always as elegantly.
One of the other comments was that this "must be fixed." I'll post my own speculations on that tomorrow, but whether or not this is changed, a few things are becoming clearer:
- It is possible to accomplish all the event handling you might want as implemented
- There certainly will be some confusion for WPF programmers who have a superset of the capabilities of Silverlight
- We need to get our terminology straight and consistent
I hope this clarifies any remaining areas of confusion but if not, please do leave more comments and we'll see if we can't sort it out.
Thanks!
-jesse
* - Yes, yes, some computers no doubt write C# programs and I bet you've met some C# programmers about whom you've had your doubts.