I'm doing a C # application for Windows that will detect when a key is no longer pressed.
So how can I do this?
PS: I know how to detect when a key is pressed.
Thanks for your atention.
You handle the KeyDown event to detect when the key goes down, and then handle the KeyUp event to detect when it goes back up.
Related
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?
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 a windows form and an OnKeyPress function. I also have KeyPreview turned on.
The function responds to most keys except up, down, left, right, home, pgdown, end and so on...
It's like whenever I press those keys, it doesn't send them to the form, it just toggles between the buttons and the other controls.
Anyone experienced that and can help out?
From MSDN
The KeyPress event is not raised by noncharacter keys; however, the noncharacter keys do raise the KeyDown and KeyUp events.
The key up event gets triggered when a key is released. This holds true for normal keys like a, b etc. However, holding down the arrow key or escape key produses different results.
Instead of firing a key up event when the key is released, it gets fired soon after the key down event. So, holding down a arrow key becomes equal to pressing and releasing the key many times very fast.
Any explaination and work around to determine when the key is actually released?
The KeyUp event isn't actually fired (for all keys not just arrow keys etc.) until you release the key, there are just many repeated KeyDown events. At least, that's the way it looks to me from some test code.
My workaround is to disable the KeyDown handler after a KeyDown event is detected using
RemoveHandler Me.KeyDown, AddressOf Form1_KeyDown
and then re-enabling when the KeyUP event is fired.
AddHandler Me.KeyDown, AddressOf Form1_KeyDown
Of course if you want to handle simultaneous multiple key presses then this won't work. You'll have to store whether or not the Key in question is already down and ignore the respective KeyDown event.
I've just run into similar problem. Keyboard handler behaves weird:
If focus and handlers are in textbox:
When alphanumeric key is held down, I got multiple Press and Down events
Arrows and function keys produce multiple Down events
If handling events for a form with KeyPreview enabled, only KeyUp event for the arrow keys is handled.
It's possible to handle all keys on lower level by overriding ProcessCmdKey.
If you want to handle a left arrow key:
Protected Overrides Function ProcessCmdKey(ByRef msg As System.Windows.Forms.Message, ByVal keyData As System.Windows.Forms.Keys) As Boolean
Select Case keyData
Case Keys.Left
Debug.WriteLine("Left")
Return True
Case Else
Return MyBase.ProcessCmdKey(msg, keyData)
End Select
End Function
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