Resolved Form keyboard event handlers stopped being fired !?

cbreemer

Well-known member
Joined
Dec 1, 2021
Messages
184
Programming Experience
10+
Weird problem here.... I have a Windows form Main with two keyboard event handlers, Main_KeyPress() and Main_KeyUp(). They used to work fine but now for some reason they are not being fired anymore (as I have verified by setting breakpoints in them). Lots has changed in the form since I last tested them, but I can't think of anything that would now prevent these event handlers from being fired. They are duly added in Main.Designer.cs:

Handlers in Main.Designer.cs:
this.KeyPress += new System.Windows.Forms.KeyPressEventHandler(this.Main_KeyPress);
this.KeyUp += new System.Windows.Forms.KeyEventHandler(this.Main_KeyUp);

None of the components in the form have their own keyboard event handlers.
Before I go and isolate the problem I just wanted to to see if anybody here has an idea or has perhaps experienced something similar ?
 
It doesn't matter whether child controls have keyboard event handlers or not. If a child control has focus then it will still swallow the event if the form's KeyPreview property is set to false. If it's true, the form will raise keyboard events before the active control does.
 
It doesn't matter whether child controls have keyboard event handlers or not. If a child control has focus then it will still swallow the event if the form's KeyPreview property is set to false. If it's true, the form will raise keyboard events before the active control does.
Yes I thought so too. Then I got unsure and checked it for good measure.
But you are spot on with that KeyPreview property ! It was set to false, and now that it's true the handlers sprang to life again. Thanks a bunch ! 👍

Reading up on this property got me to the bottom of it. Suddenly I noticed something odd - one of my two radiobuttons was always grabbing the focus. That explains why it did not work until setting KeyPreview=true.
And the reason they did that was that they both had TabStop=true. I can't remember setting that but I must have done at some stage. Having set this to false all is well again without having to worry about KeyPreview.

Thanks again !
 
Unfortunately, this Chinese site seems to be the last place that still has a copy of Jessica Fosler original blog post: "Probably more than you want to know about keyboarding in Windows Forms…"

Probably more than you want to know about keyboarding in Windows Forms - 刺客mrchenzh - 博客园

Yay! Microsoft kept a copy alive as well:
Sheesh... that is indeed way more than I want to know, as long as things work like I want 😁
But potentially very useful, I've saved it for reference. Thanks.
 
Reading up on this property got me to the bottom of it. Suddenly I noticed something odd - one of my two radiobuttons was always grabbing the focus. That explains why it did not work until setting KeyPreview=true.
And the reason they did that was that they both had TabStop=true. I can't remember setting that but I must have done at some stage. Having set this to false all is well again without having to worry about KeyPreview.
The first control in the Tab order always gets focus by default when a form is first displayed. Setting TabStop to false may not be desirable, because then the user can't Tab to those controls. It may be better to change the Tab order or, if that's not possible, set the ActiveControl property to null or some other control in the Shown event handler. Just note that, if a RadioButton did have focus, it will also be checked, so you may need to uncheck it in code too.
 
The first control in the Tab order always gets focus by default when a form is first displayed. Setting TabStop to false may not be desirable, because then the user can't Tab to those controls. It may be better to change the Tab order or, if that's not possible, set the ActiveControl property to null or some other control in the Shown event handler. Just note that, if a RadioButton did have focus, it will also be checked, so you may need to uncheck it in code too.
Yes, makes sense. In my program I'm not interested in making the controls tabbable (is that even a word ??) but I'll keep that ActiveControl property in mind. The case is now well and truly resolved 😀 Thanks !
 
Interesting... in another thread, you wanted your control accessible via keyboard shortcuts, but in this thread you don't want the controls to be accessible using the keyboard by letting the user use the tab key to go from control to control.

<joking>Is it back to Lotus-1-2-3 days where your only choices for activating menu items was to press the menu mnemonic, but couldn't use the tab key to go through the menu?</joking>
 
Interesting... in another thread, you wanted your control accessible via keyboard shortcuts, but in this thread you don't want the controls to be accessible using the keyboard by letting the user use the tab key to go from control to control.

<joking>Is it back to Lotus-1-2-3 days where your only choices for activating menu items was to press the menu mnemonic, but couldn't use the tab key to go through the menu?</joking>
Not a contradition in my opinion. I'm just not interested in using Tab to cycle through controls. Why would I want to tab to the Save or Cancel button, then press Enter or space bar ? If my program was for the general market it would be different, but I am the only user.
 
If you were following the Windows UI guidelines, Save should have been marked as the default control, so the Enter key would activate it no matter where the focus is at, and Escape key would map to the Cancel button. The user should not need to tab to them, but they can do so to comply with accessibility requirements.

But as you said, you are the only user, so there's no real need to follow the Windows UI guidelines. You can even make the program look and act like a Mac if you want to. :)
 
Last edited:
Back
Top Bottom