A colleague and I were chatting about routed events, and we came up with some things that didn't make a lot of sense. Primarily, what is the purpose of a Direct event, and why are both LeftMouseButtonDown and PreviewLeftMouseButtonDown direct events as opposed to bubbling and tunneling respectively?
According to the documentation, the LeftMouseButtonDown (and preview) events appear to behave as bubbling and tunneling events, except that the event is raised and reraised as these events traverse the tree. Since direct events can only be handled by the source of the event, it follows that any UIElement could handle a direct event since each one is raising the event and is also therefore the source. (Unless reraising the event is different than raising?). Why are these then not tunneling and bubbling like so many other similar events?
Neither my colleague nor I could come up with a use case in which we would ever create a custom event using a direct strategy (although we came up with some for tunneling and bubbling), yet LeftMouseButtonDown, one of the most common events (if not THE most common) is using this strategy.
Anyone have any ideas about the rational behind this?
Thanks!
My guess would be performance and there are considerations for having multiple events for the same thing.
There is already an event for MouseDown, to route both that and LeftMouseDown wouldn't make much sense. Finally, which would fire first and would cancelling\handling the first prevent the other? It sounds like it would be too easy to handle the same event twice.
Related
when we are suppose to use PreviewMouseRightButtonDown event instead of MouseRightButtonDown while handling mouse right button events ?
Please elaborate the ease of use.
There is no real difference between handling the PreviewMouseRightButtonDown and MouseRightButtonDown events except the timing of when each are called. Tunneling (Preview...) events are always called before the corresponding Bubbling events.
However #nit is correct... there is much written information relating to this online and so it is not worth writing again about that here. Please read the WPF Input Events section of the Routed Events Overview page on MSDN for further information.
Preview Events are Tunneling events i.e they tunnel through parent to the origin child (where event has actually occured). While the other one are Bubbling events i.e they bubble from origin child to parent.
you should understand bubbling and tunneling events in wpf to understand this. There are many article on this like
http://www.codeproject.com/Articles/464926/To-bubble-or-tunnel-basic-WPF-events
I just tried the new Marionette 1.0.0-beta with my existing project. After fiddling around with it for many hours, I must say the altered event handling confuses me.
Events seem to fire doubled. May be an artifact of the new triggerMethod() call?
Event bubbling in CollectionViews doesn't seem to work for standard events like 'item:rendered'. Those fire inside the ItemViews, but not the parent CollectionView. Is this intended?
What are the different event handling methods are meant to be used for? EventAggregator, EventBinder, Wreqr, native Backbone Events, …?
Would be great, if you could clear things up. It would also be great, if you could mark the existing documentation as being appropriate for what versions of Marionette.
Regarding the event bubbling in CollectionViews, there is a pull request to fix this as it is a bug
Basically we have a huge project, and we have an event handler that sometimes is triggered and some others it isn't. I think this is because somewhere in the jungle of code, we're handling that event, so it doesn't bubble up to where we need it. Is there anyway to find out where is it being handled?
Thanks!
Did you try to use Snoop..... there is an event Tab that tells us where the event is bubbled to and where its handled...
I have implemented a UserControl. Then I would like to handle an event that is originally handled by Window (keyboard press). What is the best way to route the event caught by another component (higher in the components' tree)?
Thanks in advance for the replies and hints!
Cheers
It depends on the event you're trying to access. If it's a Preview event and the Window is setting e.Handled to true you'll need to use the method Alex suggests to circumvent the Window's handling of the tunneling. If it is a bubbling event (i.e. KeyDown) you don't need to do anything special since bubbling events hit the handlers on child elements first and go up the visual tree so the Window handler won't occur until after your UC's.
One thing you need to be careful with using Key events is that the event is only going to get picked up by your UC in the first place if the Focus is on or inside of it. This isn't something you need to worry about with things like Mouse events since they start at a specific location in the tree.
I believe you cannot gurantee that.
Window class is wrapping Win32 message-based event model and this will be the only WPF entity which will have access to those information.
I suggest that you create an attached property (which will be used by the Window) and implement the routing of the events yourself so that controls could subscribe to.
You can attach the routed handler specifying that you want to handle handled messages as well:
this.AddHandler(routedEvent, handler, true);
where this is an UIElement or derived class.
However there may still be events (key presses in this case) which don't make it past the window, not sure.
A WPF window should have hundreds of objects (rows of rectangles) and mouse clicking on each of them should fire similar actions. These actions differ only by several parameters (say "No. of Row" and "No. of position in a row").
Should I have hundreds of almost the same event handlers or how I could optimize my code?
Please give me some tips, just to move to the right direction.
Best regards.
WPF mitigates this problem by introducing Routed Events. At any level in the element hierarchy you may intercept events from its child elements and base your logic depending on the actual element that received this event in the first place (as presented by the Source property of RoutedEventArgs).
I'm no expert in WPF, but in event handling you could write 1 dans point every similar event to this handler. In the handler use the senter parameter to know whish control it came from.
Instead of 100's of similar event hander you could have a big one with a switch
Hope that's help
Can't you just use an instance of ICommand on your viewmodel and use the command parameter to determine which rectangle was clicked?