WZ keyboard doesn't light up key on the first key press

[GoogleCodeExporter]

#WZ 1.7; see title

I tried setting the thread to start immediately instead of sleep, but it
didn't help.

Original issue reported on code.google.com by seth.h...@gmail.com on 3 May 2009 at 2:42

• Blocking: #89

[GoogleCodeExporter]

Note that I found an "init" script that ran twice and fixed this. It shouldn't 
have
changed much... but something's different now:

1) Pressing & immediately releasing the key will cause it to quickly light up 
then
un-light.
2) Holding the key will cause it to wait.... then light up (once it gets a 
repeat press).

This leads me to believe that the general code is working, but for some reason 
an
"update" to the first keypress isn't caught until the next message. 

Note that the keyboard works like normal after the second keypress. 

I think I can fix this bug now that the code is more structured. But it's still 
a pain.

Original comment by seth.h...@gmail.com on 13 Jan 2010 at 8:31

[GoogleCodeExporter]

Now here's something fun:
  1) After creating the help keyboard, if I start the thread (with no queue,
obviously) it will exhibit the same bug.
  2) If, however, I MANUALLY add 117 ('u') to the key list, it will function
properly. (For any "first key", not just 117).

And, for the kicker, it always works in Debug mode if I step through it.

So... something in the... vector? ...is consistently slowing this down? 

I guess I could commit this workaround if needed, but I think I can find the 
solution
with this added info.

Original comment by seth.h...@gmail.com on 13 Jan 2010 at 8:58

[GoogleCodeExporter]

What CAUSES the problem is that IMMEDIATELY after calling the thread the first 
time,
the GetKeyState() function identifies that the key has been released. This is 
very
odd. Now looking up oddities in GetKeyState(); however, if the problem 
persists, I
don't mind implementing the workaround.

Original comment by seth.h...@gmail.com on 13 Jan 2010 at 9:22

[GoogleCodeExporter]

Fixed: implemented the workaround. (Pumping one event).

I feel that I understand this bug in general, but I have no idea WHY 
GetKeyState() is
behaving oddly. One could write a simple test program to try & prove that this 
is a
bug in Win32, I suppose. 

The "first" keypress is so important, though, that I'm committing this 
workaround for
version 1.8. I wish I could fully grasp what's causing this, but at least we 
have a
solution for now.

Original comment by seth.h...@gmail.com on 13 Jan 2010 at 9:37

• Changed state: Fixed