Opened 7 years ago

Closed 6 years ago

#63 closed defect (fixed)

Alt modifier key remains activated after alt+tabbing out and in of the program.

Reported by: Psiweapon Schuldigun Owned by: PulkoMandy
Priority: major Milestone: 2.6
Component: GrafX2 Version: 2.4
Keywords: Cc:

Description

At least in w10. If I alt+tab out of the program and then come back, the program behaves as if the alt key was being held down. If you press it once, it is "released" and the program works normally.

Change History (13)

comment:1 by PulkoMandy, 7 years ago

Unfortunately I'm not sure we can do much, that would be a problem in SDL.

What happens:

  • Press ALT: this is registered by SDL and GrafX2
  • Press TAB: window loses focus and does not receive keyboard events
  • Release everything
  • Activate window again: the program never received the keyboard release event

I'll see if SDL can tell us when the window is activated, and maybe we could release all keys when that happens.

comment:2 by PulkoMandy, 6 years ago

Milestone: 2.52.6

comment:3 by PulkoMandy, 6 years ago

Owner: changed from pulkomandy to PulkoMandy
Status: newassigned

comment:4 by yrizoud@…, 6 years ago

Priority: minormajor

Affecting all versions of Windows. It is 100% repro if you alt-tab out while your mouse cursor is not on the surface of the window, and then use the mouse to bring back the window. (and I suspect also if you alt-tab in, but computer is slow so you have time to actually release ALT before window gets focus)

I'm pushing the priority up, because many users encounter it, the symptom "the keyboard doesn't work anymore" is very severe, and pressing ALT is not a fix that people find by themselves.

It may be interesting to try intercept events of type SDL_ActiveEvent.
When gain==1 and type==SDL_APPINPUTFOCUS, it means we just re-gained keyboard focus.
If SDL really doesn't let us find the correct state of keyboard, then at least on Windows platforms it is preferable to use SDL_SetModState() to reset ALT to zero (keeping other modifiers unchanged). It may not be the reality but people don't naturally start a keyboard shortcut before getting focus.

comment:5 by Thomas Bernard, 6 years ago

I have to test under windows with SDL, everything is fine with FreeBSD SDL 1.2.15.
But indeed I see the problem

comment:6 by Thomas Bernard, 6 years ago

Yves, could you check if this commit :
https://gitlab.com/miniupnp/grafX2/commit/f8499a0abe6d8e0affdff9c7b27e1b7dd34f3b54
fixes the issue ?

comment:7 by Thomas Bernard, 6 years ago

I don't reproduce under Windows 7 with SDL 1.2.15...
I have to setup a dev environment under Win10

comment:8 by Thomas Bernard, 6 years ago

OK I have reproduced the issue under Windows 10 (version 1803) x64
and verified that my commit f8499a0abe6d8e0affdff9c7b27e1b7dd34f3b54 does solve it.

in reply to:  6 comment:9 by yrizoud@…, 6 years ago

Replying to Thomas Bernard:

Yves, could you check if this commit :
https://gitlab.com/miniupnp/grafX2/commit/f8499a0abe6d8e0affdff9c7b27e1b7dd34f3b54
fixes the issue ?

Tested OK on Windows XP

comment:10 by Thomas Bernard, 6 years ago

you've got the issue on Windows XP ?

that is strange that the bug is on Windows XP, Windows 10
but not on Windows 7...

comment:11 by yrizoud@…, 6 years ago

Argh, now I can't reproduce it exactly on 2.4....
An easy way to repro the issue is to press and hold Alt, and use mouse to give focus to a different window, release Alt, and then use mouse again to give focus to Grafx2.
Your fix solves this case, so it should solve whatever happens during alt+tab.

comment:13 by Thomas Bernard, 6 years ago

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.