0

Why there is no any such PreviewMouseEnter event is WPF?

question is generic also for other nonexistent Preview events.

OR

Why some events are direct event in WPF? Can't they make all events as routed events? This could have saved some extra programming we have to do. example : a TreeView

Were there any disadvantages to do so?

Community
  • 1
  • 1
Kylo Ren
  • 8,551
  • 6
  • 41
  • 66

1 Answers1

4

It's because MouseEnter is not routed through the element tree.

There are three different routing strategies for routed events:

  • Bubbling: these are the events that are travelling upwards in the element tree from the source of the event, like bubbles in your pop. :)

  • Tunneling: these are the events that are travelling downwards in the element tree. These are the ones prefixed with Preview.

  • Direct: only the source has the chance to handle the event. The MouseEnter uses this routing strategy.

The overview HERE probably gives you a better understanding than my answer.

Update: Theoretically as I see there is nothing that would have prevented the implementation of MouseEnter as a bubbling or tunneling event. I think it was just a design decision of the developers of WPF. I was able to find one reference in the book "Programming WPF: Building Windows UI with Windows Presentation Foundation" which talks about the MouseEnter event specifically.

Direct events work like normal .NET events: only handlers attached directly to the originating element are notified - no real routing occurs. This is typically used for events that make sense only in the context of their target element. For example, it would be unhelpful if mouse enter and leave events were bubbled or tunneled - the parent element is unlikely to care about when the mouse moves from one child element to another. At the parent element, you would expect "mouse leave" to mean "the mouse has left the parent element", and beacuse direct event routing is used, that's exactly what it does mean. If bubbling were used, the event would effectively mean "the mouse has left an element that is inside the parent, and is now inside another element that may or may not be inside the parent," which would be less useful.

Source

Szabolcs Dézsi
  • 8,743
  • 21
  • 29
  • thanks but what i meant was... why not make MouseEvent a routed event? Why did they choose to make it a direct event we could have definitely used this as advantage. – Kylo Ren Jan 25 '16 at 04:44
  • I updated the answer. I think this is just a design decision they went with. As the book explains probably the developers of WPF thought that by implementing `MouseEnter` as bubbling or tunneling, it would distort the expectation of what the event means when it's raised travelling upwards or downwards the element tree. – Szabolcs Dézsi Jan 25 '16 at 06:33
  • Not totally convinced by your answer. I was working on this post http://stackoverflow.com/questions/34977008/how-to-get-mouseenter-event-to-trigger-only-on-the-topmost-control/34977579#34977579 When it really started to nagging me. Look at the Visual tree of TreeView (it raises mouseenter event on all parent nodes, may be that's the logical reason of not making it a routed event cause none the less mouse has already entered the parent if entered over child. do you agree?). I thought if mouse enter event would be a routed event we could have done some things easily. – Kylo Ren Jan 25 '16 at 10:04