On 07.02.2011 03:40, Ben Stott wrote:
> As noted in #2527, the keyboard demo fails to pick up the right shift
> key, instead claiming it to be a left shift.
> This is because lParam&(1<<24) is 0 for the shift key, and only the
> shift key, though I've no idea why this is the case (it *is* noted in
> the keyboard demo as a known bug of Windows - at least, on 2.0).
> Now, I'm no Windows API guru, thus my posting here. A quick patch to fix
> this is as follows:
>
> Index: src/Fl_win32.cxx
> ===================================================================
> --- src/Fl_win32.cxx (revision 8393)
> +++ src/Fl_win32.cxx (working copy)
> @@ -976,10 +976,10 @@
> break;
> case WM_KEYDOWN:
> case WM_SYSKEYDOWN:
> + // save the keysym until we figure out the characters:
> + Fl::e_keysym = Fl::e_original_keysym = ms2fltk(wParam,(lParam&(1<<24))
> || GetAsyncKeyState(VK_RSHIFT));
> case WM_KEYUP:
> case WM_SYSKEYUP:
> - // save the keysym until we figure out the characters:
> - Fl::e_keysym = Fl::e_original_keysym = ms2fltk(wParam,lParam&(1<<24));
> // See if TranslateMessage turned it into a WM_*CHAR message:
> if (PeekMessageW(&fl_msg, hWnd, WM_CHAR, WM_SYSDEADCHAR, PM_REMOVE))
> {
>
>
>
> The problem I have with a patch like this, aside from the fact that it's
> more of a hack than a patch, is that it no longer modifies the keysym on
> KEYUP events, which I'm guessing was intentional behaviour.
> In any case, is anyone able to shed some light on this issue, or comment
> on the validity of the above patch either way?
IMHO it's not worth the effort, because it will fail anyway in some or
more cases - unless MS decide to do it The Right Way. To your questions:
Yes, we need the right keysym for KEYUP events, but this could easily
be achieved (partly) by modifying your patch slightly, so that wouldn't
be the major problem. However, you couldn't do the same guess you're
doing above using GetAsyncKeyState(), because the key would have been
released already.
Using GetAsyncKeyState() however is *wrong* per definition, because of
the OS's event queueing mechanism. You wouldn't get the key state of the
time when the event *happened*, but the state of the key when the event
is *processed*. This can really be different, if event processing falls
behind key pressing speed, and so you will only get *random* behavior.
Better always wrong, but deterministic (as good as the "OS" ;-) allows)
than random...
I'd close the STR w/o resolution.
Albrecht
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
