[SDL] Alt-F4 not working on Windows

[Mason Wheeler]

----- Original Message ----
From: Will Langford <unfies at gmail.com>
To: A list for developers using the SDL library. (includes SDL-announce) <sdl at lists.libsdl.org>
Sent: Thursday, May 1, 2008 10:17:53 AM
Subject: Re: [SDL] Alt-F4 not working on Windows

>Clicking on the lil X, red circle, etc etc etc, causes the window
>manager or similar to give SDL an eventual SDL_QUIT message.  It's
>therefore up to window manager to signal the 'please close'.

That's the thing.  In ordinary circumstances, <ALT>-<F4> sends the same signal.  It is 100% functionally equivalent to clicking the X button, identical in every way. The only difference is that one is done with the mouse and the other is done with the keyboard.

Under SDL's input-handling scheme, however, this creates a discontinuity that shouldn't be there.  If you click the mouse somewhere that's not within the window's active area (including on the frame,) the mouse click is intercepted by the window manager, not passed on the application.  This is why clicking the X works.  Keyboard input is handled differently.  Unless what you typed is a system command, such as <ALT>-<TAB> or the Windows key, it's passed to the application automatically.  <ALT>-<F4> is technically defined as the keyboard shortcut for the Close command that's present in the "system menu" of every Windows window, even fullscreen ones where the menu bar isn't visible.  So pressing it invokes the Close command in the menu, which is hardwired into Windows to generate a "quit" message, exactly like clicking the X button.

Most programming schemes for creating windows work around some sort of widget set that handles input signals from the keyboard, and they give their first priority to menus because that's how a Windows program is supposed to work.  SDL doesn't do this.  It grabs all keyboard input if its program has input focus, and it doesn't have a widget set because it's optimized for blit-oriented game programming, not form-building.  So the "menu shortcuts have priority" functionality has to be faked instead.

>I've played plenty of games under windows where ALT-F4 doesn't close
>the game.  And in my humble opinion it shouldn't.  Granted, ALT-F4 is
>a strange keyboard combination, but what if it was plausible to bind
>something as such ?  Similar to CTRL-number, ALT-number, etc.
>
>If ALT-F4 is supposed to generate an SDL_QUIT under windows, then what
>about lining up code that generates an SDL_QUIT via some automagical
>window manager / OS detection routine and associated keyboard
>combinations ?  And what if I wanted to make any of those given key
>combinations usable within my application rather than force a program
>close ?

I can't agree with that.  Conventions and standards exist for a reason, and this one has a very good reason behind it.  If you don't have an arbitrarily defined and universally observed "close now" command, then the only way to quit out of a game is to select the game's own in-game close command, which is generally found in a menu somewhere.  Menus aren't always accessible--during cutscenes, for example-- and sometimes it's necessary to go through several menus to find the "Exit" command.  This can be a real nuisance if you need to get out of a program quickly, especially a fullscreen game.  I've also played some games where <ALT>-<F4> doesn't quit, and a few where it does but doesn't quit *properly*, leaving the screen corrupted or various other nuisances. This is very bad programming and annoys users that are used to using <ALT>-<F4> to quit, and it shouldn't be associated with SDL.