| Summary: | incorrect (not) handling of windows on-screen cursor keys | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Alex Denisov <ad> |
| Component: | events | Assignee: | Ryan C. Gordon <icculus> |
| Status: | REOPENED --- | QA Contact: | Sam Lantinga <slouken> |
| Severity: | minor | ||
| Priority: | P2 | CC: | ad, cameron.gutman, icculus |
| Version: | HG 2.1 | Keywords: | target-2.0.16 |
| Hardware: | x86_64 | ||
| OS: | Windows 10 | ||
...
if (bIsExtended) {
change to
else if (bIsExtended) {
(Sorry if you get several emails like this, we're marking a bunch of bugs.) We're hoping to ship SDL 2.0.11 on a much shorter timeframe than we have historically done releases, so I'm starting to tag bugs we hope to have closed in this release cycle. Note that this tag means we just intend to scrutinize this bug for the 2.0.11 release: we may fix it, reject it, or even push it back to a later release for now, but this helps give us both a goal and a wishlist for the next release. If this bug has been quiet for a few months and you have new information (such as, "this is definitely still broken" or "this got fixed at some point"), please feel free to retest and/or add more notes to the bug. --ryan. We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc). As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change! Thanks, --ryan. We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc). As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change! Thanks, --ryan. Fixed, thanks! https://hg.libsdl.org/SDL/rev/3d991f099f58 Closing this bug... I got some pushback about this fix: https://twitter.com/voidpnt/status/1250803819484573698 Reopening this so I remember to look at it. It might just be we stuff a hint in here and call it a day. --ryan. |
When using Win10 on-screen keyboard (tooltip.exe), the left and right cursor keys in it do not produce SDLK_LEFT and SDLK_RIGHT events. Windows messages generated by the on-screen keyboard, for some reason, have their scancodes set to zeroes. Here is the log from Spy++: WM_KEYDOWN nVirtKey:VK_LEFT cRepeat:1 ScanCode:00 fExtended:0 fAltDown:0 fRepeat:0 fUp:0 WM_KEYUP nVirtKey:VK_LEFT cRepeat:1 ScanCode:00 fExtended:0 fAltDown:0 fRepeat:1 fUp:1 Regular physical keyboard produces VK_LEFT (ScanCode:4B) and VK_RIGHT (ScanCode:4D) which are interpreted correctly. With on-screen keyboard, the switch statement in VKeytoScancode() does not check for VK_LEFT and VK_RIGHT, returning SDL_SCANCODE_UNKNOWN, which in turn does not get mapped to anything (because the scan codes are zeroes). Suggested fix. In WindowsScanCodeToSDLScanCode, after code = windows_scancode_table[nScanCode]; add the following: if ((code == SDL_SCANCODE_UNKNOWN) && (nScanCode == 0)) { if (wParam == VK_LEFT) { code = SDL_SCANCODE_LEFT; } else if (wParam == VK_RIGHT) { code = SDL_SCANCODE_RIGHT; } }