I realised that when using an InvokeCommandAcction associated to an EventTrigger, the original event was still routing up to the parent elements until it is handled. Well, I guess it is an expected behavior. But my question is how I can mark the event as Handled so it does not propagate up through the whole UI tree?
Actually, as you handle this event in a command, everything will be handled in this command, therefore it does not need to propagate. And in one corner case I found, it causes some unwanted behavior. For example, I open a new window when a user double click an element (MouseDoubleClick event). The problem is that the new windows opens and then the main window come back in front of the new one because the MouseDoubleClick event just reached the top element in the UI tree. The wanted behavior would be to keep the new window in front, but as the InvokeCommandAction lets the event propagate up, the main window takes back the focus...
What I could do is to use the CallMethodAction asset instead but as I am in a MVVM scenario, I don't want UI event arguments in my code. Even if this would let me implicitely mark the event as handled and fix the issue.
<UserControl x:Class="..."
xmlns:i="http://schemas.microsoft.com/expression/2010/interactivity">
<i:Interaction.Triggers>
<i:EventTrigger EventName="MouseDoubleClick">
<i:InvokeCommandAction Command="{Binding Path=DisplayReportCommand}"/>
</i:EventTrigger>
</i:Interaction.Triggers>
...
</UserControl>
You could implement your own EventTrigger that marks events as handled.
public class HandlingEventTrigger : System.Windows.Interactivity.EventTrigger
{
protected override void OnEvent(System.EventArgs eventArgs)
{
var routedEventArgs = eventArgs as RoutedEventArgs;
if (routedEventArgs != null)
routedEventArgs.Handled = true;
base.OnEvent(eventArgs);
}
}
Then replace <i:EventTrigger EventName="MouseDoubleClick"> with <local:HandlingEventTrigger EventName="MouseDoubleClick"> and add
xmlns:local="clr-namespace:HandlingEventTrigger's namespace here"
to your usercontrol's atributes.
Add attached event to user control
CommandManager.PreviewCanExecute="PreviewCanExecute"
and in event handler
e.ContinueRouting = false;
Hope this will help!
MouseDoubleClick Event is actually not a bubbling routed event but a direct routed event.
However, this event is raised along the element tree, which can be checked with Snoop tool. Moreover, even if Handled for MouseDoubleClick is set to true, this event will occur along the element tree.
Although this routed event(MouseDoubleClick Event) seems to follow a bubbling route through an element tree, it actually is a direct routed event that is raised along the element tree by each UIElement.
If you set the Handled property to true in a MouseDoubleClick event handler, subsequent MouseDoubleClick events along the route will occur with Handled set to false. This is a higher-level event for control consumers who want to be notified when the user double-clicks the control and to handle the event in an application. (From MSDN)
As above, your problem may be not caused by the propagating as you mentioned. There is Window.ShowActivated property, which determines whether a window is activated when first shown. You can set the property in a sub window(xaml) as below but please note that though ShowActivated can give the focus to the main window, it cannot let the main window visually keep in front of the sub window. I have tried to find the solution but have no idea until now.
<Window ShowActivated="False" ....>
....
</Window>
Related
I have a slider that represents position in an audio file. The user requirement is to automatically play when the user double clicks on the slider.
When I use this:
<Slider.InputBindings>
<MouseBinding Gesture="LeftDoubleClick" Command="{Binding PlayCommand}" />
</Slider.InputBindings>
The Play Command is not called. However, if I use this:
<Slider.InputBindings>
<MouseBinding Gesture="RightClick" Command="{Binding PlayCommand}" />
</Slider.InputBindings>
or this
<Slider HorizontalAlignment="Stretch" (...) MouseDoubleClick="slider1_MouseDoubleClick" >
</Slider>
The play command is called.
What prevents the use of the gesture with the double click, yet allows the right click gesture or the double click event to be called?
OK, I think I've figured out what's happening here:
The RepeatButton in the Track is intercepting the MouseLeftButtonDown event and setting Handled = true. Note that the MouseLeftButtonDown event is an off-shoot of MouseDown, so if you set Handled for one, you're really setting it for both. In this case, the mouse-down events are being handled when ClickCount = 1, and the act of marking the events as Handled prevents those events' handlers from being invoked on the second click (i.e., when ClickCount = 2). Input gestures are evaluated on the MouseDown event, so suppressing the MouseDown handlers for the second click means the Slider won't get probed for input bindings, and commands with double-click gestures will never get a chance to execute.
So, if the mouse-down handlers don't get invoked during the second click, why do the MouseDoubleClick handlers get invoked? Well, it turns out that MouseDoubleClick originates from a class-level handler in Control, and that handler gets invoked even when the original mouse-down event(s) were marked as Handled. Note the last argument to RegisterClassHandler below:
EventManager.RegisterClassHandler(
typeof(Control),
UIElement.MouseLeftButtonDownEvent,
new MouseButtonEventHandler(HandleDoubleClick),
/* handledEventsToo: */ true);
And thus the MouseDoubleClick event gets raised even though the LeftDoubleClick input binding never got a chance to execute. This is perhaps not the most intuitive behavior, and I'm unsure whether it was a conscious design decision or a simple oversight.
What is the difference between sender and source in wpf event handling?
For example, say I had an ellipse in a canvas, and clicked on the ellipse: the ellipse would be both the sender and the source.
However if the ellipse doesn't handle the event but the main window does, the event will pass through the canvas... so the canvas would be the sender of the event to the main window but the source would be the ellipse.
Do I have that right?
The difference between the two is not often seen, as usually the sender and Source are the same. Most code written like Windows Forms will basically ignore the difference and send them along as the same reference. However, given how WPF's event routing works they represent two different concepts.
sender is the object at which the event handler was attached. This is the owner that raised the handler to begin routing the event. From MSDN:
A difference between sender and Source is the result of the event being routed to different elements, during the traversal of the routed event through an element tree.
Source is the object where the event originates. In the case of tunneling and bubbling, the Source will be one of their child elements. You can use the OriginalSource property to peel back any event tree encapsulation.
Bubbles!
The sender is the object that the event is being raised from, whereas source was the original element that is causing the event to be raised.
Like in this case:
<TabControl Name="tc1" SelectionChanged="tc1_SelectionChanged">
<TabItem Header="1">
<TabControl Name="tc2">
<TabItem Header="1" />
<TabItem Header="2" />
</TabControl>
</TabItem>
<TabItem Header="2" />
</TabControl>
private void tc1_SelectionChanged(object sender, SelectionChangedEventArgs e)
{
}
In this case, if you change the SelectedItem on the Sub-TabControl, sender will equal tc1, Source will equal tc2.
Sender: Current element that is handling the event
OriginalSource: original object that first raised the event
Source: object that raised event. This is usually the same as OriginalSource but when dealing with Composite Controls it can be the parent that contains the OriginalSource object.*
RoutedEvent: Provides the RoutedEvent object for the event triggered by your event handler (such as the static UIElement.MouseUpEvent object). This information is useful if you’re handling different events with the same event handler.
Handled: Allows you to halt the event bubbling or tunneling process. When a control sets the Handled property to true, the event doesn’t travel any further and isn’t raised for any other elements.
Hope this helps :)
RoutedEventArgs.OriginalSource - original object that first raised the event
RoutedEventArgs.Source - object that raised event. This is usually the same as OriginalSource but when dealing with Composite Controls it can be the parent that contains the OriginalSource object.*
Sender - Current element that is handling the event
*Common cases where the source may be adjusted include content elements inside a content model for a control (the contents of a list item, for instance, will report the list item element as the Source and the actual element within the list item will be the OriginalSource).
References:
http://msdn.microsoft.com/en-us/library/system.windows.routedeventargs.originalsource.aspx
http://msdn.microsoft.com/en-us/library/system.windows.routedeventargs.source.aspx (Includes mention of Sender)
I am using the method described here to attach a ViewModel ICommand to the LostFocus event of a Combobox, by setting CommandBehavior.RoutedEventName="LostFocus". I expected the event to fire at the same time the binding for UpdateSourceTrigger=LostFocus fired, but this turns out not to be the case.
The selecteditem Binding UpdateSourceTrigger=LostFocus fires whenever the keyboard tabs away, or after the user actually selects an item from the dropdown by clicking (not sure why this causes lostfocus, but at least it fires AFTER a selection is made).
The attached behavior event fires anytime the user clicks on the Combobox. Immediately. If using the keyboard it behaves normally, firing when you tab away from it. However, when using the mouse, the event fires when the control GAINS focus, before the user has even made a selection. Is there any way to make this behave like lostfocus does for the selecteditem?
Edit: I am curious if another answer exists, but I found a way around this problem, by setting up an additional binding. SelectedItem updates by defualt, handling the normal property change notifications, and selectedvalue updates on lostfocus, handling only the command I was trying to run. Binding looks like this:
SelectedItem="{Binding Path=SelectedCustomer, Mode=TwoWay}"
SelectedValuePath="CM_CUSTOMER_ID"
SelectedValue="{Binding Path=CustomerLostFocus, UpdateSourceTrigger=LostFocus}"
You would need to check the OriginalSource of the event arguments for the LostFocus event:
The LostFocus event is a bubbling event. This means that if multiple
LostFocus event handlers are registered for a sequence of objects
connected by parent-child relationships in the object tree, the event
is received by each object in that relationship. The bubbling metaphor
indicates that the event starts at the object that directly receives
the input condition, and works its way up the object tree. For a
bubbling event, the sender available to the event handler identifies
the object where the event is handled, not necessarily the object that
actually received the input condition that initiated the event. To get
the object that initiated the event, use the OriginalSource value of
the event's RoutedEventArgs event data.
So for the ComboBox, you may receive events for the various focusable elements inside the ComboBox.
I'm trying to write an event handler that fires every time a node in a TreeView gets the focus. The problem I'm running into is that the event handler fires on the TreeViewItem (node) that I click on with the mouse, and then it continues to bubble up the control tree, even though I've set e.Handled = true on the RoutedEventArgs provided to the handler. Does anybody have an idea what the problem could be ? I've double checked my code and I can see no reason why this should be happening.
Are you using TreeView.GotFocus when you really want TreeViewItem.Selected?
<TreeView TreeViewItem.Selected="treeView1_Selected" />
If you really want focus, use TreeViewItem.Focus instead so that items are targeted instead of the whole tree.
<TreeView TreeViewItem.GotFocus="treeView1_GotFocus"/>
I want to get notified when an item in a ListBox gets clicked by the mouse, whether it is already selected or not.
I searched and found this: (http://kevin-berridge.blogspot.com/2008/06/wpf-listboxitem-double-click.html see the comments)
private void AddDoubleClickEventStyle(ListBox listBox, MouseButtonEventHandler mouseButtonEventHandler)
{
if (listBox.ItemContainerStyle == null)
listBox.ItemContainerStyle = new Style(typeof(ListBoxItem));
listBox.ItemContainerStyle.Setters.Add(new EventSetter()
{
Event = MouseDoubleClickEvent,
Handler = mouseButtonEventHandler
});
}
//Usage:
AddDoubleClickEventStyle(listView1, new MouseButtonEventHandler(listView1_MouseDoubleClick));
This works, but it does it for a DoubleClick. I can't get it working for a single click though. I tried MouseLeftButtonDownEvent - as there doesn't seem to be a MouseClick event, but it's not being called.
A bit more general side question: How can I see what events do exist and which handlers correspond to them and when they actually do something? For example, what tells me that for a MouseDoubleClickEvent I need a MouseButtonEventHandler? Maybe for a MouseLeftButtonDownEvent I need some other handler and that's why it's not working?
I also tried subclassing ListBoxItem and override OnMouseLeftButtonDown - but it doesn't get called either.
Marc
I believe that your MouseLeftButtonDown handler is not called because the ListBox uses this event internally to fire its SelectionChanged event (with the thought being that in the vast majority of cases, SelectionChanged is all you need). That said, you have a couple of options.
First, you could subscribe to the PreviewLeftButtonDown event instead. Most routed events have a routing strategy of Bubbling, which means that the control that generated the event gets it first, and if not handled, the event works its way up the visual tree giving each control a chance at handling the event. The Preview events, on the other hand, are Tunneling. This means that they start at the root of the visual tree (generally Window), and work their way down to the control that generated the event. Since your code would get the chance to handle the event prior to the ListBoxItem, this will get fired (and not be handled) so your event handler will be called. You can implement this option by replacing MouseDoubleClickEvent in your sample with PreviewMouseLeftButtonDown.
The other option is to register a class handler that will be notified whenever a ListBoxItem fires the MouseLeftButtonDown event. That is done like this:
EventManager.RegisterClassHandler(typeof(ListBoxItem),
ListBoxItem.MouseLeftButtonDownEvent,
new RoutedEventHandler(this.MouseLeftButtonDownClassHandler));
private void OnMouseLeftButtonDown(object sender, RoutedEventArgs e)
{
}
Class Handlers are called before any other event handlers, but they're called for all controls of the specified type in your entire application. So if you have two ListBoxes, then whenever any ListBoxItem is clicked in either of them, this event handler will be called.
As for your second question, the best way to know what type of event handler you need for a given event, and to see the list of events available to a given control, is to use the MSDN documentation. For example, the list of all events handled by ListBoxItem is at http://msdn.microsoft.com/en-us/library/system.windows.controls.listboxitem_events.aspx. If you click on the link for an event, it includes the type of the event handler for that event.
There is also another way - to handle PreviewMouseDown event and check if it was triggered by the list item:
In XAML:
<ListBox PreviewMouseDown="PlaceholdersListBox_OnPreviewMouseDown"/>
In codebehind:
private void PlaceholdersListBox_OnPreviewMouseDown(object sender, MouseButtonEventArgs e)
{
var item = ItemsControl.ContainerFromElement(sender as ListBox, e.OriginalSource as DependencyObject) as ListBoxItem;
if (item != null)
{
// ListBox item clicked - do some cool things here
}
}
Was inspired by this answer, but it uses listbox by name, I propose to use sender argument to avoid unnecessary dependencies.
I think the first option in Andy's answer, of using PreviewMouseLeftButtonDown, is the way to go about this. In XAML it would look like this:
<ListBox Name="testListBox">
<ListBox.ItemContainerStyle>
<Style TargetType="{x:Type ListBoxItem}">
<EventSetter
Event="PreviewMouseLeftButtonDown"
Handler="ListBox_MouseLeftButtonDown" />
</Style>
</ListBox.ItemContainerStyle>
</ListBox>
There is another way to get MouseDown event in ListBox. You can add event handler for events that are marked as handled by using handledEventsToo signature of AddHandler method:
myListBox.AddHandler(UIElement.MouseDownEvent,
new MouseButtonEventHandler(ListBox_MouseDown), true);
Third parameter above is handledEventsToo which ensures that this handler will be invoked no matter if it is already marked as Handled (which ListBoxItem does in ListBox).
See Marking Routed Events as Handled, and Class Handling for explanation.
See How to Attach to MouseDown Event on ListBox for example.
You can use Event="MouseLeftButtonUp"
Unlike "PreviewLeftButtonDown" it will get the ListBoxItem handled too.
You can use the SelectionChangedEventArgs argument of the SelectionChanged event to find what item is add or removed through AddedItems and RemovedItems, usually only have the latest clicked on, or if not, then look at the last item which is the count-1.