On 07/02/11 23:20, Albrecht Schlosser wrote:
> 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.
...Isn't this what they say they'll do with all their software? :-P
> 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.
Yep, that's why I shuffled things around, and I couldn't use GetKeyState
for the reasons described below.
> 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.
Yes, this is true, however GetKeyState() (which gets the state of keys
when events happened vs when they're processed) seemed to be static in
my tests - hitting right shift and then any left modifing key would see
the keyboard demo report a right key until right shift was hit *again*,
and I wasn't game enough to test with any of the "set" functions
(neither SetKeyboardState() nor SendInput() seemed to do anything to
help the left/right shift problem)
> Better always wrong, but deterministic (as good as the "OS" ;-) allows)
> than random...
>
> I'd close the STR w/o resolution.
Hmm, for now, I'll see what more I can find. Surely Windows can't be
/too/ badly broken!
Ben
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
