I'm using the KeyDown Event in my MainWindow to get key strokes of the up/down key.
When typing in a TextBox I get huge delays between key stroke and the character showing up on the screen, because of handling the MainWindow.KeyDown event after each stroke.
Is there a possibility to catch the up/down keys no matter what control is focused (also TextBoxes) without having this delay?
I could disable the event while the TextBox has focus but then I would miss the up/down keys.
I also tried to handle up/down keys in the TextBox.KeyDown event and prevent bubbling to the MainWindow by setting e.Handled = true but this also prevents the TextBox from showing anything at all.
Thanks for any help in advance!
Related
Event not activates on entering values by using numbers on keyboard. It only activates when you use the up and down arrows. What I want is, It must activate on every keyboard stroke like textbox textchanged event.
I've tried few things but user had to press enter for activating the event. I don't want that.
It must be same like textbox event. Any ideas ? or another tool maybe ?
NumericUpDown control fires the value changed event in the following scenarios
When using Up/Down arrows of the control as you have mentioned.
When the control loses focus after changing the value using keyboard input.
When using Up/Down arrow keys in the keyboard.
Instead of ValueChanged you can use KeyPress event which fires for every keyboard key stroke.(but keep in mind this event will only fire for keyboard numeric key press)
private void numericUpDown1_KeyPress(object sender, KeyPressEventArgs e)
{
}
I have a custom WPF control that wants to handle both key down and up events as well as text input. For instance, if the user hits Home on the keyboard, I want to handle that in my custom control and prevent it from bubbling up to other controls.
Now, I can achieve this by handling the key down and up events in my custom control and setting KeyEventArgs.Handled to true. However, this has the unfortunate side effect that text input events then aren't getting generated.
How do I handle both key down and key up events as well as text input without letting the events propagate to parent controls (pretty much how a textbox control does)?
You can try setting the KeyEventArgs.Handled to true only for keys you are interested in handling, such as Home key from your example and allow the rest to bubble through.
So I have a window that handles the KeyDown event. Everything works as expected except under two conditions:
The up / down arrow keys are pressed and
A combo box on the window has more than one item.
Even if I've never clicked on the combo box it doesn't seem to matter. The SelectionChanged event on the combobox fires before the Window even fires its KeyDown event. This seems highly counter-intuitive to me.
I don't know enough about WPF event propagation to even know where to start looking for a solution. Any recommendations?
You should subscribe to PreviewKeyDown event instead.
I have a search screen in my WPF application. The screen is implemented as a UserControl in a TabItem of a TabControl. When the user switches to the Search tab, I want the focus to go into one particular field.
So I added a Loaded event handler to the UserControl tag in the Xaml and I called the Focus method of the control I want to have the initial focus in the Loaded event handler. This worked great until I upgraded the Telerik control library I'm using today. Now, when I switch to the Search tab, the focus is NOT in the field I want to have it, but I can't tell what control does have the focus.
The field I want to have focus already has GotFocus & LostFocus event handlers for other reasons. I remembered that in Win Forms, the LostFocus event handler arguments tell you which control is going to get the focus. So I put a breakpoint in my LostFocus handler & discovered that the arguments to the LostFocus event handler in WPF don't include that information.
How can I figure out where the focus is going without putting GotFocus handlers on every control in my UserControl?
Tony
You can try putting your breakpoint on the LostKeyboardFocus Attached Event instead of the LostFocus Event. It uses the KeyboardFocusChangedEventArgs Class which does have properties that show which element had focus and where the focus is going.
private void textBox1_LostKeyboardFocus(object sender, KeyboardFocusChangedEventArgs e)
{
textBox1.Text = ((FrameworkElement)e.NewFocus).Name ;
}
Try to press Tab Key and see if it helps you find the control in focus.
You can also use Snoop as suggested in this Q/A: Any tips on debugging focus issues in WPF?
For starters, Snoop shows the current focused element and the current
FocusScope in the status bar.
You can get it to show you all the GotFocus and LostFocus events:
1. Run your app.
2. Run Snoop.
3. Choose your app in the dropdown.
4. Click the binoculars ("Snoop") button.
5. On the right pane, click the Events tab.
6. Click to bring down the dropdown.
7. Scroll down to the Keyboard section and check GotKeyboardFocus, LostKeyboardFocus, and optionally the PreviewXXX events.
8. Now do what you need to do to manipulate focus and watch the Snoop window.
Similarly you can track the FocusManager events the same way.
My application have custom image control,button and a custom textbox.I implemented some key operations in window keydown event belonging to image and some key operations in textbox previewkeydown event.When the focus is on image or button,key operations of the window works well.When the focus is on the textbox,combination of two key operations doesn't work well.For example,when the focus is on textbox,if I pressed ctrl + up arrow,first it fires the keydown event of both textbox and window keydown event where e.key contain ctrl.second textbox's keydown event is fired but windows keydown event is not fired why..?
Might input binding help you out?
See: http://www.switchonthecode.com/tutorials/wpf-tutorial-command-bindings-and-custom-commands
Its what's used for keyboard input in WPF way more than the KeyDown and KeyUp events. I'm having my own issues with those right now, ugh.