We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 1555 - ALT+F4 does not produce a SDL_WINDOWEVENT_CLOSE event on Win, neither CMD+Q on OSX
Summary: ALT+F4 does not produce a SDL_WINDOWEVENT_CLOSE event on Win, neither CMD+Q o...
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: events (show other bugs)
Version: 2.0.1
Hardware: All Windows (All)
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-23 16:58 UTC by Gabriel Jacobo
Modified: 2013-11-13 14:20 UTC (History)
2 users (show)

See Also:

Attachments
Let DefWinProc handle keypresses (579 bytes, patch)
2012-07-23 17:00 UTC, Gabriel Jacobo 		Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Gabriel Jacobo 2012-07-23 16:58:42 UTC 
Under Windows, pressing ALT+F4 does not produce a WM_CLOSE event from the system (which would in turn generate a SDL_WINDOWEVENT_CLOSE) because we are "eating" all the keypresses. The attached patch lets DefWindowProc handle all keypresses, I'm not adding this directly to hg because I'm not sure of the side effects.
Under OS X, the same thing happens, CMD+Q does not generate a SDL_WINDOWEVENT_CLOSE event, though I don't know the cause yet.
Comment 1 Gabriel Jacobo 2012-07-23 17:00:14 UTC 
Created attachment 911 [details]
Let DefWinProc handle keypresses
Comment 2 Gabriel Jacobo 2013-02-12 09:49:05 UTC 

*** This bug has been marked as a duplicate of bug 1320 ***
Comment 3 Sebastien Lussier 2013-11-06 01:29:23 UTC 
Reopened, since this bug was marked as a duplicate of the same issue under OS X, and was closed without integrating the patch for Windows provided by Gabriel Jacobo.

Issue is still present in SDL 2.0.1
Comment 4 Daniel Scharrer 2013-11-06 01:36:03 UTC 
As it is now, SDL correctly handles the quit shortcut under OS X (according to the linked bug) and under Linux / X11 (via the WM), but SDL users still need an OS-specific hack for Windows. In #576 slouken decided not to change this behavior for SDL 1.2, but can this please be reconsidered for SDL 2, especially now that it has been fixed for the other desktop platforms?
Comment 5 Sam Lantinga 2013-11-06 05:32:21 UTC 
Have you tried this patch to see what other side effects this might have?
Comment 6 Gabriel Jacobo 2013-11-06 12:33:28 UTC 
I think the side effect will be that all keyboard shortcuts on Windows start having their default behaviour...which is a ... good thing?

Here's a list: http://support.microsoft.com/kb/126449
Comment 7 Sam Lantinga 2013-11-07 07:57:09 UTC 
Not a good thing?

Here's a report from James Haley about this on SDL 1.2:

We’ve had some problems in the Eternity Engine and Chocolate Doom projects after switching over to use the windib driver by default where Windows’ alt+space key combo starts causing the system menu to open, which locks up the program and causes any currently pressed keys to become stuck in the “down” state once the menu is closed. This is a serious problem for DOOM, Heretic, Hexen, Strife, and Duke 3D based projects as the default control scheme for those games places “use” on spacebar and “strafe” on ALT. This means trying to use something while running at an angle pulls you out of the game and, if the modal menu loop lasts long enough, can disconnect network games.
--

Maybe we can manually handle Alt-F4?
Comment 8 Gabriel Jacobo 2013-11-13 14:20:09 UTC 
Should be fixed now: https://hg.libsdl.org/SDL/rev/1b49b680f319