Possible Bug about Bubbled Events and Focusable

Possible Bug about Bubbled Events and Focusable

• michaelp

  Lastest Reflector 4.x is enough. Reflector is your best friend in the wpf world, for as long as the doucmentation will be in it's current lacking state.

  Highly recommendabe is TestDriven.net 2 with reflector, which lets you set breakpoints from reflector and have the joy of debugging the framework without the source.

  Back in the days, by integrating the reflector code, nunit used to be able to step into the decompiled code on the fly. Now that was one of the most useful features ever.

  
  
  

• we7313

  Sebastien, if that would be the case then Grid, with Focusable = true, putted in the middle would also 'swallow' the event, which actually doesn't happen. Appart of that you explanation was an interesting and original narrative ;)

  Thanks

  P.S.

  Just being pendantic perhaps we should add  'or hits a handled event e.g. e.Handled = true' after both 'reaches the root's. Of course it's not applicable to the 'brutal force' cases, when AddHanler is used. 

  
  

• Ranal

  Sebastien is right. The ScrollViewer "swallows" the Bubbling MouseDown event (similar to how a Button does) because it makes a change to the UI when it occurs. This is the pattern that Microsoft follows and recommends that developers follow when they create controls. If your control makes an observable change to the UI based on an event, it should mark that event as handled.

  If you want to see the MouseDown event for a subelement of a ScrollViewer, you should use the Tunelling PreviewMouseDown event.

  
  
  

• spennington

  Hi Josh, how do you mean 'the root element' If I have 8 grids per say nested into each other and click the very top one - the the very bottom one (as well as its parent if any) will get notified when using bubbling. Inwhich case the event will get fired 8 times, element -self, parent, grand parent so forth. Please, consider that. When using tunnelling, it works the way around - the very bottom element will get a notifcation first, after that grand..grand parent, parent, element self. At least that's how it works for me using RC1.

  The problem though you don't seem to be allowed to use both strategies concurrently, which as I figured out myself, kinda makes sense.

  Bubbling and Tunneling are not about 'End Stops' if I understand you correctly. They are about Routes, which is implied by their name. Beside that, if I replace that ScrollViewer with the Grid, everything works. Have you ever putted your theory on test  

  Thanks, Dmitry

  
  

• budbjames

  If you click on the Top grid (which is the grandparent of Bottom grid) then the MouseDown event shouldn't ever make it to Bottom. Routed events only tunnel/bubble between the root element and the element which caused the event to be raised (the target).

  In any case, the ScrollViewer is probably preventing the MouseDown from ever making it to the other elements. Have you tried hooking the PreviewMouseDown instead

  
  
  

• Ankith

  If it answers your question don't forget to mark it as such, it helps other people looking for the same thing.

  Thanks.

  
  
  

• The-Traveler

  Few comments:

  • Tunneling events: The PreviewXxx event gets called on the root first, then its child, all the way down the three to the element that was clicked.
  • Routed events: Thee Xxx event gets called on the element that was clicked, then goes up the tree until it reaches the root.

  With that in mind, if your top grid contains your scrollviewer which contains a grid, and you want to click on the top grid, it will have to be a click outside of the visible region of the scrollviewer. A click only happens on the element that is under your mouse pointer.

  Now if you MouseDown on your bottom grid, the preview event is going to go TopGrid -> MiddleElement -> BottomGrid, in theory.

  In the case of ScrollViewer, it is actually catching the Bubbling MouseLeftButtonDown, and try to get keyboard focus. If it does get focus, it will mark the event as handled, which will simply prevents the click from happening. In the case where you set the IsFocusable to false, the ScrollViewer will not get the focus and won't mark the event as handled.

  Two ways out of it, you found one already (remove the Focusable), but that will prevent any scrolling to be made using the keyboard. Or register to receive the event even when it's already handled. Using AddHandler(RoutedEvent, delegate, bool = true) should do the trick.

  I suspect ScrollViewer grabs keyboard focus on keydown because keyboard input is only received on the focused element, and it wants to make sure that whenever something happens within, it can start responding to the keyboard immediately.

  
  
  

• iampedro

  Now it makes much more sense:) Can you tell us please which reflector are you using to browse that stuff
  

• brettlee01

  Only if the grid was actually overriding the OnMouseLeftButtonClick, which it doesn't. ScrollViewer however does, and here's the code:

  protected override void OnMouseLeftButtonDown(MouseButtonEventArgs e)
  {
     if (base.Focus())
     {
        e.Handled = true;
     }
     base.OnMouseLeftButtonDown(e);
  }
  

  I'm not sure that'll make my narrative any more interesting, but it makes it accurate.

  To answer your implied question, the event does fire, you just don't get notified because it's been marked as handled.

  Thanks.

  
  
  
• Possible Bug about Bubbled Events and Focusable