I have a PreviewKeyDown handler on my mainwindow which handles up and down keys so I can navigate with the keyboard between my controls.
Now I have the problem that in some Textboxes I also want to use the up/down keys. This seems impossible because the other handler seems to swallow the keys first.
Is it possible that when one of these TextBox controls are focused they get the up/down keys first and then then swallow them so that the "global" PreviewKeyDown does not get them?
Sure I could disable the global handler somehow when such a TextBox got focus but is this good style?
You don't really have an option, aside from filtering out those keys in the global key handler.
The reason that you're having this problem is that all of the Preview* events are tunneling, meaning that controls higher in the visual tree get them first (starting at the root). The very reason why you're using this event in the first place is causing your problem.
One less than ideal option would be to register a class handler for TextBox.PreviewKeyDown (see EventManager.RegisterClassHandler()). While this would be called before your window's PreviewKeyDown handler, it will be called for all TextBoxes in your application. This may or not be what you want.
Related
Is there any way I can still catch the keypress if Enter is pressed on a clickable element.
Because the Windows Store Apps API treats Enter as click event rather than a keypress if the focus is on a clickable element (i.e. a GridViewItem).
Unfortunately I have to let the user right-click on a GridViewItem which sets the focus to the element.
Moving the focus would be an option but I'd prefer not to do that if I don't have to.
It seems, this is not in the nature of WInrt. You can follow the specification provided on MSDN:
https://msdn.microsoft.com/en-us/library/windows/apps/windows.ui.xaml.uielement.keydown.aspx
You can still try the Key Down event of GridView
In WinRT, some events are user-initiated only. As a result, some WinRT APIs can only be invoked in those types of events. Button.Click is one of those events. As a result, you cannot programmatically raise this event because it would undermine the security feature that limits certain API to those types of events.
Make sense?
Best of luck!
I have a user control which is not declared in the designer. I have a button that I want to have create this user control when I click it - it should initialize the user control and insert it in the main UI.
However, it happens that the user control has a key press event on it, which is not firing.
Why does this happen?
I already tried to attach the event on the user control itself but it seems that it's not firing at all. Is there some kind of bug?
It is very hard to fix problems with code that you can't see, but in WPF, there are often reasons why Bubbling events like the KeyDown event don't fire. Occasionally certain controls may make use of these events and set them as handled internally, thereby stopping them from bubbling up any further.
The normal solution on these occasions is to use the related Tunneling events instead, which are raised before the Bubbling methods and not used internally by controls. So, while I can't guarantee that this will fix your problem, it is certainly worth trying to handle the UIElement.PreviewKeyUp event instead of the UIElement.KeyUp event.
I'm working on a project that uses a RichTextBox. My project required me to make use of bold/italics/underline/colour/etc. To handle all of this, I downloaded a custom application from the Internet, "RicherTextBox".
This new control works well for formatting text, however events like KeyDown, KeyUp don't work. Other events that were present in RichTextBox like LinkClicked are missing.
Since I have the code for RicherTextBox, I can customize it as desired.
How can I make KeyDown, KeyUp work like it does for RichTextBox?
How can I add missing events like LinkClicked?
That entirely depends on what's going on inside that RicherTextBox control. Does it just extend the regular RichTextBox control? They could be intercepting and handling events. You'll have to check out the source code to be sure.
See if they're subscribing to the KeyDown and KeyUp events. There's a Handled property on the KeyEventArgs parameter for those events. If they set e.Handled = true, it'll prevent the event from going any further up the chain.
I don't see a Handled event in the LinkClickedEventArgs that's passed to the LinkClicked event, so I'm not sure. You'll have to dig into the source code.
I have a bug in my application that I don't know how to how to attack. Basically, key events "go missing" after some time. I have added event handlers to KeyDown, KeyPressed and KeyUp that write to the console (both for the Form and one of its TextBoxes). Here's the correct order of things:
control_PreviewKeyDown
ShellForm_KeyDown
control_KeyDown
ShellForm_KeyPress
control_KeyPress
ShellForm_KeyUp
control_KeyUp
In the failed state (which I can't reproduce consistently), I get these events when pressing a key (TextBox has focus):
ShellForm_KeyUp
control_KeyUp
Form.KeyPreview is true.
It's the same for all TextBoxes in the Form; they are not disabled and not set to readonly, but it's no longer possible to write text.
Problem is, I don't really know where to begin.
Begin with Application.AddMessageFilter(...) just to intercept the flow of events.
You can find some ideas here.
I am working with a TextBox, and need to fire some logic when the textbox has lost focus.
My problem is twofold:
The Leave event is firing on every keypress for some reason, meaning the logic is run with every keypress when it should not.
When using the Focused property of the Textbox as a double-check, simply exiting out if the property is still set, it now works when the user uses the mouse to leave, but not when the user tabs out.
The Focused property of the TextBox in question is False as of when its Leave event fires when the mouse is used to change focus, but it is still True when the Leave event fires due to a Tab keypress. Seriously?
I need a workaround, because the logic firing on every keystroke is causing a problem for users right now that needs to be fixed post-haste.
I created a form with a textbox on it and attached event handler to the leave event of that text box. I then typed a bunch of stuff into said textbox. The event was not raised. I hit tab, the event was raised. I then clicked back in the textbox, typed some more, and then clicked another control and the event was raised.
I'm just saying that something else is interfering with the textbox. I would look into that a little more, or post some code demonstrating the problem.