Add CAPS LOCK state detection
Posted Monday, 8 November, 2010 - 00:44 by Chris The Avatar| Project: | The Open Toolkit library |
| Version: | 1.0-2010-10-06 |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | open |
Description
Under Windows 7 x64 I have the following issue:
Nearly all control keys do not fire the key_down event correctly. This seems isolated on Windows, The issue does not exist on my SuSE 11.3 machine running on mono. Additionally after pressing the tab key, the next time I press a key it causes windows to ding... The next key press is still processed and caught by OpenTk even though it causes windows to catch it as well. The key_up for these keys are being caught correctly it seems.
Additionally there needs to be a way in OpenTK to check if the CAPSLock key is currently on/off. If there is a way it does not seem easy to tell.
Comments
#1
#2
I cannot reproduce this on my Windows 7 x64 installation with SVN trunk. What kind of keyboard are you using? (Mine is a Microsoft Digital 3000).
Also why do you need to detect the caps lock state? For text input you should use the
KeyPressevent instead ofKeyDown/KeyUp.#3
It is a generic dell keyboard... I cannot find the model number on it, though it is nothing fancy.
Key Up/Down is useful for things like CTRL+Shift+ Alt... For hot keys in games. Caps Lock would be useful in the same regards if a letter should be capitalized when handeling characters for key up/down however I did not even see the KeyPress event, I was looking under keyboard when I setup all my events, I do see that it returns the appropriate capitalization character. Though I would still need the key Up/Down for CTRL/Shift/Alt states... CAPS Lock state might not be a major issue since Key Press events, but certainly would be nice. Most of the other engines I have dealt with only give key up/down so I usually need to implement my own upper/lower case methods, so I apologize for not seeing the key_press event.
The Tab ding is the most annoying problem ..... I still cannot get it to quit. As a side note I previously used OpenTK 0.9.6 via agatelib and did not have the issue at that time.
Thanks for your help
Chris
#4
Ive been testing with key press, it seems even worse, almost every other key stroke is missed. It seems like it is some kind of timing issue, with key repeat on, if I hold down a key it will take a about 2 seconds before registering the first press and then capture maybe 5 - 10 characters then lag capturing and recapture. If you have a newer build I can try I would be happy to see if that helps.
Thanks
Chris
#5
Just a follow up: I downloaded the latest from SVN.. I still have the same problem. I discovered the problem occurs for pretty much on any system key such as arrows, tab alt/ctrl etc. The problem does not happen every time one of the listed system keys is pressed though so it may be difficult to track. I am fairly new to this framework, but this seems like it was very straightforward to setup (not much to input), is it possible I am misconfiguring something?
Thanks
Chris
#6
As a sanity check, does the problem occur in the attached test case?
SVN contains the latest code and there is no configuration to speak of. This could be a bug in OpenTK and I have a feeling it won't be easy to hunt down.
#7
Ill give it a shot this evening when I get home from work. Thanks for taking the time to look at my problem.
#8
Bingo... The root cause is Application.DoEvents() , when the function call is placed in RenderFrame it causes the issue... Placing it in update frame instead solved my problem, it is not inherintly obvious to programmers why this shouldnt work though. Maybe a note on this would be good (maybe you already have one that I didnt read :-))
Thanks for your help. definately one to note. Good down to earth test.
CAPS LOCK would still be a nicety I know I have some rework to do if I am going to use key_press instead, where if caps lock state was available would be nice.
Something to think about.
Thanks Again
BTW a side note it looks like Audio library section has changed qutie a bit, there is no audio reader, how do I load audio?
#9
Using GameWindow and WinForms in the same thread is not supported (likewise, you cannot mix WinForms and GTK# or SDL and GLUT in the same thread). Application.DoEvents is a WinForms method and is probably stealing input events before OpenTK has a chance to process them. The recommended workaround is to launch GameWindow on a different thread.
I would suggest adding AudioReader directly to your application but this is getting slightly off-topic.
#10
For Caps Lock:
On linux you can add this to X11Input:
keyboard[Key.CapsLock] = ((e.KeyEvent.state & 2) == 2);
and this to WinGLNative:
if (key == Key.CapsLock)
keyboard[Key.CapsLock] = Console.CapsLock;