Background: I am trying to display all available keyboard shortcuts when the user presses the Alt key - similar to the behavior in Office 2010.
But I am having trouble to detect when the Alt key is pressed because the PreviewKeyDown-Event is not always fired. More precisely: It is fired when the key is pressed for the first time, but when I release it and press it again, the event is not fired. That means, it is only fired every second time. I assume that this is related to the fact that the Alt key is a special system key and triggers the window's main menu which somehow swallows the second event. Interestingly, the event does work for the right Alt key. Also, the PreviewKeyUp-Event is always fired for both keys (left and right).
I have also tried to handle the WM_KEYDOWN and WM_SYSKEYDOWN messages directly, but the behavior is exactly the same.
I managed to get the desired behavior when I registered for the InputManager.Current.PostNotifyInput event, but this event is fired pretty often - even for every mouse movement etc. and I would like to avoid this overkill.
Any ideas how I can always be notified when the Alt key is pressed? How does Office 2010 do this? Maybe, is there an event which notifies if the window's menu is activated by pressing the Alt key?
Related
I have a Window which has a Frame containing a Page from another project. I want to get notified if the user presses the Enter button. The problem I'm facing:
When I press the Enter button not the event is triggered but instead the context menu shown in the picture appears. I have tried several things with Focus() and Keyboard.SetFocus() but nothing helped.
The MainWindow is maximized and the WindowStyle is set to none but even when I change it does not change anything. If you need further information feel free to ask.
if (e.Key == Key.Enter)
{
ValidateCredentials();
}
The problem was as following: As demanded it was necessary to navigate through the application with the function keys F1 to F12. F10 Key activates as default the menu bar.
F10 was the Navigation Key for the page from above. So when I pressed F10 to navigate to the page the menu bar has got the focus. When I press Enter the menu bar gets opened.
Solution is set the F10 key to handled.
A better answer is using the correct event.
You need to use the KeyDown event to trap keystrokes. The KeyPress or KeyUp events are too late in the pipeline and are referred back to default OS Context Menu behaviour. You could use Function keys but that's a hack the users will despise (many keyboards don't have function keys anymore).
See this example with the Mouse instead of the Keyboard, same device input logic applies: https://stackoverflow.com/a/53255798/495455
Using C#, .NET 4, WPF.
I have a Telerik rich text control that is losing certain key events (tab, backspace, delete, and the arrow keys are specifics).
For debugging purposes I have added handlers for PreviewKeyDown, KeyDown, CommandExecuting, and DocumentContentChanged. The behavior presents both with and without the handlers present, in both DEBUG and RELEASE mode.
If I press a key other than those listed above I get the events in the order listed above. As an example, if I press the 'a' key I get PreviewKeyDown, KeyDown, CommandExecuting, and DocumentContentChanged.
If I press the right arrow key I get PreviewKeyDown and no other of the events fire.
My suspicion is that there is something trapping the KeyDown event at some point in the message chain before it gets to me and setting e.Handled = true.
Is there any tool available that would allow me to detect the KeyDown event and see in what code it's e.Handled is modified? I know I'm stretching here...
Thanks!
rjsjr
You could use Snoop. It can tell you, which Element set handled = true.
If you need to process these events, you can use EventManager.RegisterClassHandler().
This is ridiculous. I have a KeyDown event I am interested in(to get DownArrow Key event) for a WinForm. I added a trackbar, which gets Autofocus(I dont know how). And now, when I press the DOWN arrow key - it automatically changes the value of the Trackbar and my code for the Winform is not working. I tried HIDING the Trackbar with a button but to no avail. I even have
e.SuppressKeyPress = true;
in my Form1_KeyDown() handler.
Help, I am going haywire.
You can override ProcessCmdKey method. check out below links for more information.
Up, Down, Left and Right arrow keys do not trigger KeyDown event
http://www.getdotnetcode.com/gdncstore/free/Articles/Overriding%20a%20Controls%20ProcessCmdKey%20Function.htm
http://msdn.microsoft.com/en-us/library/system.windows.forms.control.processcmdkey(v=vs.85).aspx
I have succesfully replaced the Windows Shell following the approach given in this SO question.
However, I have detected that the first key press is lost and is a bit of an annoyance for the user. The solution we have tried is to activate the form in the OnShown event:
private void OnShownLoginForm(object z_sender, EventArgs z_e)
{
Activate();
m_loginTextBox.Focus();
}
But this hasn't solved the problem. Do you have any clue of what is happening?
You could try using the System.Windows.Forms.SendKeys Class (MSDN Documentation) to send a key press event to the form when in the Form Load event. If that doesn't help, try sending the keyboard events in the Form.Shown event since Form.Shown is the last event in the form start-up process.
Sounds like something caused by maybe another control getting focus first. Does the textbox have a taborder, and can you set it to 0? Focus should then be on it after the form loads.
Otherwise try creating a new form to test with, it really doesn't seem reproducible.
I do not know if it is related but I had a similar problem where the tabindex property of a webform did not work by pressing the TAB key, after focusing on the first input at page load, until the user first clicked on the form with the mouse.
I did not have access to the source code so I tried solving it with javascript.
Until the first mouse click, all keyboard strokes, including the TAB key, activated the keypress event, TAB key was undetected by keydown/keyup on page load.
I learned that the TAB key activated the keypress event and I could access the keycode through it. simply registering the keypress event and manually switching to the next input with jQuery worked.
after the first mouse click the form behaved as expected, TAB key was no longer caught by keypress event.
here is a code sample:
function tabNext(e){
if(e.keyCode == 9){
// do work
}
}
$('input').keypress(tabNext);
Are the two events the same or are there differences that we should take note when coding the keyboard presses?
My answer here is just based on experimenting with different applications, not programming per se.
Handle the keydown. Let that be the trigger for your logic. That's what the user would expect based on interacting with other applications.
For example, try a key down in Notepad, and you'll see that the DOWN triggers the reaction in Notepad. It doesn't wait for the UP.
It doesn't matter if it's .Net or not, it matters what the user expects. Keydown is a good time to respond to the four arrow keys. Character input is a good time to respond to input of visible characters. Keyup is usually a good time to respond to any action that is going to have an effect on a document, but keydown would be better if it's a game where the user wants immediate effect.
It's not really "which is a better choice for .NET."
You really have to think about how you want to respond to key presses. If you want to what someone is typing in a text box it's usually best to wait until they've released before trying to decide what they're doing. But if it's something like a game where you want to respond the instant it's pressed, than you would use KeyDown.
KeyDown is the moment the key is pushed down.
KeyUp is after the key has been released.
One thing to consider that I've had a problem with before:
If you handle something on key down that changes the window or changes UI component focus, then the new UI element may sometimes get the key up event.
This happened to me at my last job. We had a control on a form that, on key down, would load a new form. If the new form loaded fast enough, then the new form would get focus before the user released the key, and the new form would get the key up event. We had a UI control on that 2nd form that reacted to key up, and it would sometimes get triggered unintentionally.
The moral of the story is; keep it consistent. Pick one or the other and stick to it :)
The key down event happens as soon as the user presses a key, the key up event happens when they release the key after pressing it.
So if you use the key up event, and the user presses a key and holds it for 5 seconds, nothing will happen until they let go of it.
(Note: I know nothing about .net, I've just used 'key up' and 'key down' events in other libraries.)
I allmost allways use KeyDown, because then I can use e.Handled=True and stop the keyevent to travel from textbox to container and down in the eventque if I want. You can use e.Handled in KeyUp also, but then its "to late" because the key the user entered will be seen in the textbox and you have to take it away manually if you for example want to stop the user to enter digits in the textbox.
Another thing to take into account: When holding modifiers, it's important to use keydown. I generally use keydown to set a variable like ctrlPressed=true; then use keyup to unset that variable ctrlPressed=false;
I generally use keyPressed for all alphanumeric characters.
This sort of system allows you to enable things like CTRL+K+C ala Visual Studio