I have wired PreviewLostKeyboardFocus event to TextBox. I handled the event. When I click on the ComboBox control, it fires twice.
If I not handled it fires only one time.
private void TextBox_PreviewLostKeyboardFocus(object sender, KeyboardFocusChangedEventArgs e)
{
e.Handled = true;
}
Can someone please help resolve this issue ?
When you set:
e.Handled = True;
You are effectively preventing the focus leaving the TextBox.
So if focus is in this TextBox and you click on another field (e.g. ComboBox) it will cause the event to fire, but the cursor will remain forever in the TextBox.
Remove this or make it conditional.
Related
I have a UserControl that contains several ComboBoxes and Buttons.
In the window that hosts the UserControl I need to update some properties when the UserControl gets the focus.
My problem is, that every time, when the focus inside the user control changes, that get a GotFocus event in the hosting windows.
Is there some kind of best practice to make sure, that I only get one GotFocused event in the hosting window? I mean, if I step through controls inside the UserControl the focus is always inside the UserControl, so I don't want a GotFocused event.
This is the solution I came up to:
First of all this post was the key for my solution: WPF UserControl detect LostFocus ignoring children .
And Refer to active Window in WPF? .
Using the functions in these posts I registered the LostFocus event in my UserControl.
private void UserControl_LostFocus(object sender, RoutedEventArgs e)
{
var focused_element = FocusManager.GetFocusedElement(Application.Current.Windows.OfType<Window>().FirstOrDefault(x => x.IsActive));
var parent = (focused_element as FrameworkElement).TryFindParent<KeywordSelector>();
if (parent != this) userControlHasFocus=false;
}
And then ...
private void UserControl_GotFocus(object sender, RoutedEventArgs e)
{
if (userControlHasFocus == true) e.Handled = true;
else userControlHasFocus = true;
}
This way I keep track of the focus. userControlHasFocus is false be default. When the GotFocus() happens for the first time it's false and the GotFocus event is not stopped form bubbling up. But userControlHasFocus gets set to true, because now the focus is inside the UserControl.
Whenever the focus moves to another control, LostFocus checks if the new controls parent is the UserControl. If not, it resets the userControlHasFocus to false.
I'm using WPF to design a borderless, movable application window.
In order to manually perform the ability to drag and drop the window, I've added an OnMouseDown event to the <Window> element, that executes a corresponding C# function (this.DragMove()).
Additionally, I need an <Image> button to allow some operation (with the OnMouseUp event this time). Note that it has to be an Image tag, and not a Button.
Unfortunately, the Image event fired only when the right mouse button is clicked, probably because the left button is held to the window event. Am I right?
When someone clicks the Image button, I want only the Image event to be triggered. How can I do it?
Problem you're facing is most probably related to event routing. The idea is that if your handler doesn't mark event as a Handled it will be routed to the next listener unless reach end of chain or one of listeners/handlers will set it as Hadnled.
So if you have MouseDown event handler for both Window and Image you should keep in mind that routing will stop at a point when you will set e.Handled = true;:
private void Window_OnMouseDown(object sender, KeyEventArgs e)
{
e.Handled = false; // will NOT break event chain;
}
You can always check a type of sender so it will make possible for you to differ Image and Window events:
private void Image_OnMouseDown(object sender, KeyEventArgs e)
{
if (sender is Image)
{
// Handle Image.MouseDown
e.Handled = true; // we don't need to push event further;
}
}
Its because of WPF bubbling and tunnelling events. so what u can do is whenever u handle event on button use bubbling for that means you can use previewevents for that for both button and window and whenever you just want to handle event for button then after last line of code in button click just write down like this.
e.handled=true;
// here e is the event argument which u will get in your preview event.so now window dragging event will not work.
i would just suggest first clear the idea of bubbling(preview mouse event) and tunneling in wpf.
Difference between Bubbling and Tunneling events
and go through some of the example of bubbling and tunnelling. you will get better idea.
http://www.codeproject.com/Articles/464926/To-bubble-or-tunnel-basic-WPF-events
If I type a letter into a TextBox, and its content changes according to my keypress, why does the KeyDown event continue bubbling up? I would have thought this would be 'handled' at this stage.
Since KeyDown event is a bubbling event, that's why its bubbled to its parent in your case Window. If you don't want that to bubbled to your window, you need to mark it as handled in your textBox handler itself like this -
private void TextBox_KeyDown(object sender, KeyEventArgs e)
{
e.Handled = true;
}
Whereas, if you try to hook the event PreviewKeyDown in your textBox, you will see that - Window's PreviewKeyDownEvent gets called first and later that of your textBox. Reason behind that is, it's a tunelling event. For routing strategies, refer to this link - Routing Strategies
EDIT
Morevoer, if you want to check if the KeyDown event comes from textBox, you can check the OriginalSource of your eventArgs -
private void Window_KeyDown(object sender, KeyEventArgs e)
{
// Check to make sure event comes from window and not from textbox.
if(e.OriginalSource is Window)
{
}
}
I have a window containing a textBox.
On both the window AND the textBox, I add a PreviewMouseDoubleClicHandler.
Handler in the window:
private void PreviewMouseDoubleClickHandler(object sender, MouseButtonEventArgs e)
{
Debug.WriteLine("handler in the window");
e.Handled = true;
}
handler in the textBox:
private void PreviewMouseDoubleClickHandler(object sender, MouseButtonEventArgs e)
{
Debug.WriteLine("handler in the textBox");
e.Handled = true;
}
now, when I double-click on the textBox, I expect to go first into the window's Handler, print the debug line, then handle the event, then nothing more. I thought the textBox's handler would not fire since the event has already been handled by the window.
This does not work like this though: I get both handlers fired.
The weird thing is: It works fine with the PreviewMouseDown event. If I do exactly the same thing but with PreviewMouseDownEvents, I get the behavior I expect, i.e.: the window handles the mouseDown and the textBox's handler is not fired.
so Why does this not work with the doubleClick event? Am I doing something wrong? Is it supposed to work like this? is the doubleClick Event managed in a different way that prevents me from using the advantages of tunneling?
The behavior is by design, please see: http://msdn.microsoft.com/en-us/library/system.windows.controls.control.previewmousedoubleclick.aspx
I creating a custonmized box class (inherits from ComboBox). I don't want the text box to react to right mouse clicks. I can get rid of the context menu by setting this to null in ApplyTemplate, but right mouse clicks move the cursor. I tried hooking up PreviewMouseRightButtonDown in ApplyTemplate and setting Handled to True, but the event still gets through which is strange as it seems to work for the left click.
The cursor actually moves when the mouse button is released, so you want mark the MouseRightButtonUp event as handled. You could override OnMouseRightButtonUp:
protected override void OnMouseRightButtonUp(MouseButtonEventArgs e)
{
base.OnMouseRightButtonUp(e);
e.Handled = true;
}
Or you could attach a class handler to the MouseRightButtonUp event to mark it as handled:
static MyComboBox()
{
EventManager.RegisterClassHandler(
typeof(MyComboBox),
MouseRightButtonUpEvent,
new MouseButtonEventHandler(MyComboBox_MouseRightButtonUp));
}
private static void MyComboBox_MouseRightButtonUp(
object sender, MouseButtonEventArgs e)
{
e.Handled = true;
}
That will also prevent the context menu from being created without you having to set it to null explicitly.