So far I can only make this happen in Windows, not Linux. I think I
remember seeing something about it on the list ages ago, but I can’t
find it anymore. If I hold a mouse button down, Alt-Tab into my game,
and then release the mouse button, WIN_CheckWParamMouseButton() does
not receive the release event and SDL_GetMouseState() shows a non-zero
state as if the button is still held down. Clicking any mouse button
again fixes it.
This part is a little stranger. If button 1 release is not received,
you can press button 3. This immediately causes the receipt of button
1 release and button 3 press. So it’s as if the release event was just
delayed somewhere.
I was able to duplicate this behavior in testsprite2 by adding a
little test code at the end of the main loop:
I suspect this is a corner case where Windows isn’t delivering all
events, but maybe I’m missing something. Does anyone know how the
measurement of the mouse state can be made more robust so SDL doesn’t
think buttons are held down when they’re not? I see that SDL_mouse.c
contains SDL_ResetMouse() for fixing this kind of problem, but it
isn’t in use at the moment.–
Terry Welsh http://www.reallyslick.com
The real trick of this is that SDL needs to release all buttons when the focus is lost (synthesizing its own events for the purpose).
This is a well-known problem on Windows, some variants of this problem can occur on X11 as well but the rules there are a bit more well-defined regarding mouse leaving the window during a drag.–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier
Is this with a recent SDL build (2.0.2 RC1 or newer)?
This happens with the current Mercurial revision and revision 8086. It
has probably been an issue for a long time.
The real trick of this is that SDL needs to release all buttons when the focus is lost (synthesizing its own events for the purpose).
This is a well-known problem on Windows, some variants of this problem can occur on X11 as well but the rules there are a bit more well-defined regarding mouse leaving the window during a drag.
Looking a little closer: When I click the mouse outside my game window
and alt-tab to the game window, the game window receives the button
press event even though the button was pressed outside the window. It
does not receive the release event whether or not the mouse is now in
the window. So this particular problem is not happening when the game
window loses focus.
There could be a lot of corner cases like this now and in the future,
and you can bet Microsoft won’t rush to fix them. It would be good to
have something like SDL_ResetMouse() as a workaround.
I’m calling the Windows function GetOpenFileName() which opens a system
dialog. When I double-click a file in the dialog, it returns to my program
with the mouse button stuck down. If I click, the new mouse down event
doesn’t happen and I get the new mouse up event instead of the old one
(which is lost completely). If I Alt-Tab out and back in again, I also get
a new mouse up event without clicking at all. Clicking other mouse buttons
does not affect the stuck one.
I remember the exact issue being brought up with the other version of sdl.
That person was told that it was a ridiculously small number of users that
would ever experience this and so it’s not worth looking into . I’m pretty
sure the common consensus was that operating systems were just built this
way so if it’s good enough for them it’s good enough for us. I’m not saying
I believe any of that I’m just saying that’s what came up before in case
other people don’t remember or were not here .On Mar 4, 2014 3:34 PM, “Jonathan Dearborn” wrote:
I might have just come across the same problem.
I’m calling the Windows function GetOpenFileName() which opens a system
dialog. When I double-click a file in the dialog, it returns to my program
with the mouse button stuck down. If I click, the new mouse down event
doesn’t happen and I get the new mouse up event instead of the old one
(which is lost completely). If I Alt-Tab out and back in again, I also get
a new mouse up event without clicking at all. Clicking other mouse buttons
does not affect the stuck one.
I remember the exact issue being brought up with the other version of sdl.
That person was told that it was a ridiculously small number of users that
would ever experience this and so it’s not worth looking into . I’m pretty
That’s too bad. I hope someone with commit privileges changes their
mind about this. The problem is solved by calling SDL_ResetMouse()
when I receive a SDL_WINDOWEVENT_FOCUSE_GAINED event. But
SDL_ResetMouse() is not currently exposed, so that would need to get
changed. I looked into injecting my own mouse button events just like
SDL_ResetMouse(), but it appears I don’t have access to the mouse
instance id which is needed to create the events.–
Terry Welsh http://www.reallyslick.com
FYI, I’m not sure who said this, but it wasn’t anyone with SDL commit
access.
This kind of bug is extremely important to certain types of applications,
like games.
Has anybody reported it in bugzilla? I think it’s something we want to look
at for 2.0.3. http://bugzilla.libsdl.orgOn Tue, Mar 4, 2014 at 1:58 PM, R Manard wrote:
I remember the exact issue being brought up with the other version of sdl.
That person was told that it was a ridiculously small number of users that
would ever experience this and so it’s not worth looking into . I’m pretty
sure the common consensus was that operating systems were just built this
way so if it’s good enough for them it’s good enough for us. I’m not saying
I believe any of that I’m just saying that’s what came up before in case
other people don’t remember or were not here .
On Mar 4, 2014 3:34 PM, “Jonathan Dearborn” wrote:
I might have just come across the same problem.
I’m calling the Windows function GetOpenFileName() which opens a system
dialog. When I double-click a file in the dialog, it returns to my program
with the mouse button stuck down. If I click, the new mouse down event
doesn’t happen and I get the new mouse up event instead of the old one
(which is lost completely). If I Alt-Tab out and back in again, I also get
a new mouse up event without clicking at all. Clicking other mouse buttons
does not affect the stuck one.
I remember the exact issue being brought up with the other version of
sdl. That person was told that it was a ridiculously small number of
users that would ever experience this and so it’s not worth looking into
. I’m pretty sure the common consensus was that operating systems were
just built this way so if it’s good enough for them it’s good enough for
us. I’m not saying I believe any of that I’m just saying that’s what
came up before in case other people don’t remember or were not here .
Did we really say that? This sounds like a fixable bug in SDL to me.
