Chris The Avatar's picture

Add CAPS LOCK state detection

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

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Chris The Avatar's picture

#1

Version:1.0.0-rc1» 1.0-2010-10-06
the Fiddler's picture

#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 KeyPress event instead of KeyDown/KeyUp.

Chris The Avatar's picture

#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

Chris The Avatar's picture

#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

Chris The Avatar's picture

#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

the Fiddler's picture

#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.

AttachmentSize
KeyTest.cs4.52 KB
Chris The Avatar's picture

#7

Ill give it a shot this evening when I get home from work. Thanks for taking the time to look at my problem.

Chris The Avatar's picture

#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?

the Fiddler's picture

#9

Title:Control Keys (TAB, ENTER, Arrows, etc...) Not firing Key_Down + CAPS LOCK» Add CAPS LOCK state detection
Category:bug report» feature request

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.

jdomnitz's picture

#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;