Alt-F4 not working on Windows

SDL Development
61

What part of the SDL does actually prevent the WM_DESTROY event that
every other windows program gets when I hit ALT-F4?

none, you just have to catch the ALT-F4 key combo and do what you
must…

This is not true since every other windows program will get a WM_DESTROY
event if you hit ALT-F4 or if you press the [X] icon. If you were right
every other windows program would have to catch keyboard events and look
for ALT_F4, but this is done (AFAIK) by the window manager and not by
the application.

if ALT-F4 caused the SDL_QUIT event then how do you tell the difference
between a SDL_QUIT that was caused by the [X] icon and the key combo?

This is true, you would not be able to tell the difference from the view
of the SDL app. But why should one care how the Program closes? I think
you can’t tell either if your program was terminated by clicking [X] or
by using the task manager to terminate the process. But that’s the
point, there are several ways to terminate a Program (ALT-F4, [X],
Taskmanager, etc.) but all a windows program gets is the WM_DESTROY
message.

it
just gets very obscure and silly… nothing here is broken, if you want
ALT-F4 to close the app/game then just catch the key combo and do what
you
do for SDL_QUIT event… simple!

It’s not that simple because on other systems I don’t want ALT_F4 to
terminate the program but to use that systems key combination, which can
be different from ALT-F4.

And if I want ALT-F4 on Windows to not close the window but do something
else ?? im buggered!!

You could as well try to use ALT-TAB or CTRL-ALT-DEL in your application but these are pre-defined key in windows and as well is ALT-F4. It’s very poor design using ALT-F4 on windows for anything else than quitting the program.

if this was to be implemented in SDL then you can bet your ass than many
programs that already exist and use ALT-F4 for other reasons will not work
as expected… instead of doing what was intended of the combo it quits the
program!!! this would be a bug!!

and on other systems its the same story regardless you mixing up user
interface ethics with bugs here! if you want ALT-F4 to call WM_DESTROY
catch the combo and pump the SDL_QUIT event.

My main question still is: Why is ALT-F4 in the SDL not generating a WM_DESTROY event? With every other program this is working fine, so there has to be something that prevents the event. I’m not insisting that this is a bug (although I think so) but I’m asking WHY.On Sat, 03 May 2008 17:36:21 +0100 “Graham Houston” <graham.houston at rushpark.co.uk> wrote:

On Sat, 03 May 2008 17:23:53 +0100, Christoph Kobe <@Christoph_Kobe> wrote:

On Sat, 03 May 2008 16:59:30 +0100 “Graham Houston” <graham.houston at rushpark.co.uk> wrote:

On Sat, 03 May 2008 16:49:27 +0100, Christoph Kobe <@Christoph_Kobe> wrote:

Graham.

– Using Opera’s revolutionary e-mail client: http://www.opera.com/mail/

–
Christoph
from Hamburg, Germany

62

What part of the SDL does actually prevent the WM_DESTROY event
that

every other windows program gets when I hit ALT-F4?

none, you just have to catch the ALT-F4 key combo and do what you
must…

This is not true since every other windows program will get a
WM_DESTROY
event if you hit ALT-F4 or if you press the [X] icon. If you were
right
every other windows program would have to catch keyboard events and
look
for ALT_F4, but this is done (AFAIK) by the window manager and not by
the application.

if ALT-F4 caused the SDL_QUIT event then how do you tell the
difference

between a SDL_QUIT that was caused by the [X] icon and the key combo?

This is true, you would not be able to tell the difference from the
view
of the SDL app. But why should one care how the Program closes? I
think
you can’t tell either if your program was terminated by clicking [X]
or
by using the task manager to terminate the process. But that’s the
point, there are several ways to terminate a Program (ALT-F4, [X],
Taskmanager, etc.) but all a windows program gets is the WM_DESTROY
message.

it
just gets very obscure and silly… nothing here is broken, if you
want

ALT-F4 to close the app/game then just catch the key combo and do
what

you
do for SDL_QUIT event… simple!

It’s not that simple because on other systems I don’t want ALT_F4 to
terminate the program but to use that systems key combination, which
can
be different from ALT-F4.

And if I want ALT-F4 on Windows to not close the window but do something
else ?? im buggered!!

You could as well try to use ALT-TAB or CTRL-ALT-DEL in your application
but these are pre-defined key in windows and as well is ALT-F4. It’s
very poor design using ALT-F4 on windows for anything else than quitting
the program.

if this was to be implemented in SDL then you can bet your ass than many
programs that already exist and use ALT-F4 for other reasons will not
work
as expected… instead of doing what was intended of the combo it quits
the
program!!! this would be a bug!!

and on other systems its the same story regardless you mixing up user
interface ethics with bugs here! if you want ALT-F4 to call WM_DESTROY
catch the combo and pump the SDL_QUIT event.

My main question still is: Why is ALT-F4 in the SDL not generating a
WM_DESTROY event? With every other program this is working fine, so
there has to be something that prevents the event. I’m not insisting
that this is a bug (although I think so) but I’m asking WHY.

perhaps the developers realised this would break existing code that
expects ALT-F4 to not generate WM_DESTROY? I don’t know? but I do use
ALT-F4 in some apps I’ve developed to do other things and right or wrong
if it was changed my code would not function as intended…

I do see your point regarding Windows apps always generating WM_DESTROY on
the combo, but I guess this can be changed even in non SDL applications to
do what you want. So way break existing code by changing the behaviour and
leaving less room for options??

GrahamOn Sat, 03 May 2008 17:47:43 +0100, Christoph Kobe wrote:

On Sat, 03 May 2008 17:36:21 +0100 “Graham Houston” <@Graham_Houston> wrote:

On Sat, 03 May 2008 17:23:53 +0100, Christoph Kobe wrote:

On Sat, 03 May 2008 16:59:30 +0100 “Graham Houston” <@Graham_Houston> wrote:

On Sat, 03 May 2008 16:49:27 +0100, Christoph Kobe wrote:

–
Using Opera’s revolutionary e-mail client: http://www.opera.com/mail/

63

My main question still is: Why is ALT-F4 in the SDL not generating a WM_DESTROY event? With every
other program this is working fine, so there has to be something that prevents the event. I’m not insisting
that this is a bug (although I think so) but I’m asking WHY.
Because SDL hooks the keyboard input at a low enough level that it receives the keypresses before the window manager does. - is defined as a menu shortcut for the Close command in the window’s system menu, and then the Close command generates a WM_DESTROY message. But since the window manager never gets the keypress, the shortcut can’t be activated. (Opening the system menu with the mouse and selecting Close works just fine.)

----- Original Message -----
From: christoph@kobenetz.de (Christoph Kobe)
To: sdl at libsdl.org
Sent: Saturday, May 3, 2008 9:47:43 AM
Subject: Re: [SDL] Alt-F4 not working on Windows

64

My main question still is: Why is ALT-F4 in the SDL not generating a WM_DESTROY event? With every
other program this is working fine, so there has to be something that prevents the event. I’m not insisting
that this is a bug (although I think so) but I’m asking WHY.
Because SDL hooks the keyboard input at a low enough level that it receives the keypresses before the window manager does. - is defined as a menu shortcut for the Close command in the window’s system menu, and then the Close command generates a WM_DESTROY message. But since the window manager never gets the keypress, the shortcut can’t be activated. (Opening the system menu with the mouse and selecting Close works just fine.)

Thanks, this is something I was expecting. But since ALT-TAB and CTRL-ALT-DEL still work one could say that this is a flaw in the Windows operating system / window manager. Easy enough to blame Microsoft for this :-)On Sat, 3 May 2008 10:46:01 -0700 (PDT) Mason Wheeler wrote:

----- Original Message ----
From: Christoph Kobe <@Christoph_Kobe>
To: sdl at libsdl.org
Sent: Saturday, May 3, 2008 9:47:43 AM
Subject: Re: [SDL] Alt-F4 not working on Windows

–
Christoph
from Hamburg, Germany

65

Thanks, this is something I was expecting. But since ALT-TAB and CTRL-ALT-DEL still work one could say
that this is a flaw in the Windows operating system / window manager. Easy enough to blame Microsoft for
this :slight_smile:
Now, I’m all for blaming Microsoft for their multitude of screwups, but this is really just a design issue, and it’s perfectly consistent behavior. - is supposed to be handled by the application, but - and -- are system-level commands that get handled by the OS. If you press those keystrokes, SDL will probably generate the appropriate keypress event, but since the handler’s registered at the OS level and not the application level, you don’t see any blocking behavior. -, on the other hand, is a menu shortcut that has to be handled by the application.

----- Original Message -----
From: christoph@kobenetz.de (Christoph Kobe)
To: sdl at libsdl.org
Sent: Saturday, May 3, 2008 11:16:23 AM
Subject: Re: [SDL] Alt-F4 not working on Windows

66

Thanks, this is something I was expecting. But since ALT-TAB and CTRL-ALT-DEL still work one could say
that this is a flaw in the Windows operating system / window manager. Easy enough to blame Microsoft for
this :slight_smile:
Now, I’m all for blaming Microsoft for their multitude of screwups, but this is really just a design issue, and it’s perfectly consistent behavior. - is supposed to be handled by the application, but - and -- are system-level commands that get handled by the OS. If you press those keystrokes, SDL will probably generate the appropriate keypress event, but since the handler’s registered at the OS level and not the application level, you don’t see any blocking behavior. -, on the other hand, is a menu shortcut that has to be handled by the application.

Thanks again, I think today I’m learning quiete a lot. I always thought ALT-F4 was handled by the window manager, but apparently this is not true for windows, maybe for KDE. So maybe it would be a solution to remove the ALT-F4 shortcut from the menu entry, because I think nobody will argue that it’s a bug in every SDL program when the menu says but ALT-F4 is not working.On Sat, 3 May 2008 11:22:40 -0700 (PDT) Mason Wheeler wrote:

----- Original Message ----
From: Christoph Kobe <@Christoph_Kobe>
To: sdl at libsdl.org
Sent: Saturday, May 3, 2008 11:16:23 AM
Subject: Re: [SDL] Alt-F4 not working on Windows

–
Christoph
from Hamburg, Germany

67

Thanks again, I think today I’m learning quiete a lot. I always thought ALT-F4 was handled by the
window manager, but apparently this is not true for windows, maybe for KDE. So maybe it would be
a solution to remove the ALT-F4 shortcut from the menu entry, because I think nobody will argue that
it’s a bug in every SDL program when the menu says but ALT-F4 is not working.

That would be difficult. The System menu and its contents are provided by the OS as standard features of every ordinary window. I’m not completely certain, but I think that if you wanted to modify it, you’d have to go and design your own window that’s identical in every way, except for whatever it was you were modifying.

----- Original Message -----
From: christoph@kobenetz.de (Christoph Kobe)
To: sdl at libsdl.org
Sent: Saturday, May 3, 2008 11:49:36 AM
Subject: Re: [SDL] Alt-F4 not working on Windows

68

Mason Wheeler skrev:> ----- Original Message ----

From: Christoph Kobe
To: sdl at libsdl.org
Sent: Saturday, May 3, 2008 11:49:36 AM
Subject: Re: [SDL] Alt-F4 not working on Windows

Thanks again, I think today I’m learning quiete a lot. I always thought ALT-F4 was handled by the
window manager, but apparently this is not true for windows, maybe for KDE. So maybe it would be
a solution to remove the ALT-F4 shortcut from the menu entry, because I think nobody will argue that
it’s a bug in every SDL program when the menu says but ALT-F4 is not working.

That would be difficult. The System menu and its contents are provided by the OS as standard features of every ordinary window. I’m not completely certain, but I think that if you wanted to modify it, you’d have to go and design your own window that’s identical in every way, except for whatever it was you were modifying.

My KDE window manager has a context menu for the window title bar. It
shows a close action and the keyboard shortcut Alt+F4. Someone already
wrote that the KDE window manager catches Alt+F4 and sends a quit event
to the client.

If the MS Windows window manager also shows such a context menu for the
title bar and says that the keyboard shortcut for quit is Alt+F4, it
must also catch Alt+F4 and send to a quit event to the client. Otherwise
the window manager is lying, which is clearly a bug in it. It can not
simply show Alt+F4 in the context menu and hope that the client catches
Alt+F4 and handles it as if it received a quit event from the title bar
context menu, X button or task manager context menu.

69

Mason Wheeler skrev:

Thanks again, I think today I’m learning quiete a lot. I always
thought ALT-F4 was handled by the window manager, but apparently
this is not true for windows, maybe for KDE. So maybe it would be
a solution to remove the ALT-F4 shortcut from the menu entry,
because I think nobody will argue that it’s a bug in every SDL
program when the menu says but ALT-F4 is not
working.

That would be difficult. The System menu and its contents are
provided by the OS as standard features of every ordinary window.
I’m not completely certain, but I think that if you wanted to
modify it, you’d have to go and design your own window that’s
identical in every way, except for whatever it was you were
modifying.

My KDE window manager has a context menu for the window title bar. It
shows a close action and the keyboard shortcut Alt+F4. Someone
already wrote that the KDE window manager catches Alt+F4 and sends a
quit event to the client.

If the MS Windows window manager also shows such a context menu for
the title bar and says that the keyboard shortcut for quit is Alt+F4,
it must also catch Alt+F4 and send to a quit event to the client.
Otherwise the window manager is lying, which is clearly a bug in it.
It can not simply show Alt+F4 in the context menu and hope that the
client catches Alt+F4 and handles it as if it received a quit event
from the title bar context menu, X button or task manager context
menu.

For my two cents worth, this is the most concise (and IMHO correct)
explanation I’ve seen so far, assuming this is the way it works. If
the WM advertises this functionality, then it’s the one responsible for
dealing with it, not the application.

If Windows isn’t honouring the key-combo, it means the application is
free to catch it (or not). So if the application has a choice, it
isn’t a bug in SDL not to deal with it; SDL is making a valid choice.

Put another way, if other Windows applications that don’t use SDL are
free to ignore Alt-F4, then SDL shouldn’t be forced to handle it
either, as it’s obviously not a hard requirement to do so.

SteveOn May 3, 2008 5:28:20 pm Erik wrote:

----- Original Message ----
From: Christoph Kobe
To: sdl at libsdl.org
Sent: Saturday, May 3, 2008 11:49:36 AM
Subject: Re: [SDL] Alt-F4 not working on Windows

70

Hmm… btw… I have to take a quick stab at the RIGHTS issue
flamebait with my own flamebait remark.

The user is given the RIGHT to use whatever program they’re running,
they are not entitled to it :). Extend this argument to EULA’s,
public domain, GPL, they don’t HAVE to use the program, etc etc etc
:). Then, continuing the ‘RIGHTS’ argument, most agreements include
clauses stating no fitness of purpose, indemnity, warranty, guarantee,
etc etc etc. If you’re going to insist the user has a RIGHT to common
OS/WM controls, then does not implementing them mean apps that don’t
support them fall under malware, viruses, abusive, etc ?

I’d skip the whole rights issue and focus on where it should be
implemented in the design aspect of things :). I, personally, dislike
an extra layer in the event pipeline, but, having the WM part of SDL,
or an SDL_wmconvention library offer an _Init() or something seems the
most plausible. Then you get the fun of if() vs function pointer
goodness, etc etc etc. And, best of all, I’d imagine it’d only take
an hour or three to implement such a system… meaning we’d have a
stop-gap solution in the interim. I, sadly, have a 24/7 on call life,
and therefore don’t have time to implement it personally :(.

I wouldn’t mind seeing something available to catch these common OS/WM
commands to aid in cross platform goodness… although having them
forced down your throat would undoubtedly have ALOT of people up in
arms.

Back to securing a server, blech :(.

-Will

71

And if I want ALT-F4 on Windows to not close the window but do something
else ?? im buggered!!

Holy crap, people. Can’t we all just get along? And by "get along,"
I mean: I suggest we DO have SDL support ALT+F4 keypresses. It keeps MY life
simple. (I don’t have to add "#ifdef WINDOWS if (event.type == yadayada…)“
in every event loop of every app, when I’m already doing
"if (event.type == SDL_QUIT)”)

For those of you who feel ‘buggered’ by adding this functionality to SDL,
which, again, I feel keeps programmers’ lives simple, we should add an
API or env var that determines whether SDL listens out for ALT+F4 on Windows
(and whatever else some OS might dream up that it’d be a kluge to handle
in our own code).

if this was to be implemented in SDL then you can bet your ass than many
programs that already exist and use ALT-F4 for other reasons will not work
as expected… instead of doing what was intended of the combo it quits the
program!!! this would be a bug!!

This is why, for historical/compatibility reasons, at least under SDL 1.2,
the default behavior should be: “pass the ALT+F4 along to the event queue
as keypresses.” The enhanced behavior, which 99% of people would want
to enable, should be “listen for ALT+F4 on Windows and send SDL_QUIT event”.

and on other systems its the same story regardless you mixing up user
interface ethics with bugs here! if you want ALT-F4 to call WM_DESTROY
catch the combo and pump the SDL_QUIT event.

Or… let SDL do that for us, so that three lines of #ifdef’d code doesn’t
need to pollute everyone’s app-level code. :DOn Sat, May 03, 2008 at 05:36:21PM +0100, Graham Houston wrote:

–
-bill!
bill at newbreedsoftware.com
http://www.newbreedsoftware.com/

72

Can we just drop this whole thing? Seriously, this is too weird to
believe…

No? Ok, everyone who disagrees with me is a NAZI!

Now, I invoke Godwin’s law and proclaim this over and moot. :slight_smile:

Bob PendletonOn Sat, May 3, 2008 at 6:47 PM, Bill Kendrick wrote:

On Sat, May 03, 2008 at 05:36:21PM +0100, Graham Houston wrote:

And if I want ALT-F4 on Windows to not close the window but do something
else ?? im buggered!!

Holy crap, people. Can’t we all just get along? And by "get along,"
I mean: I suggest we DO have SDL support ALT+F4 keypresses. It keeps MY
life
simple. (I don’t have to add "#ifdef WINDOWS if (event.type ==
yadayada…)“
in every event loop of every app, when I’m already doing
"if (event.type == SDL_QUIT)”)

For those of you who feel ‘buggered’ by adding this functionality to SDL,
which, again, I feel keeps programmers’ lives simple, we should add an
API or env var that determines whether SDL listens out for ALT+F4 on
Windows
(and whatever else some OS might dream up that it’d be a kluge to handle
in our own code).

if this was to be implemented in SDL then you can bet your ass than many
programs that already exist and use ALT-F4 for other reasons will not
work
as expected… instead of doing what was intended of the combo it quits
the
program!!! this would be a bug!!

This is why, for historical/compatibility reasons, at least under SDL 1.2,
the default behavior should be: “pass the ALT+F4 along to the event queue
as keypresses.” The enhanced behavior, which 99% of people would want
to enable, should be “listen for ALT+F4 on Windows and send SDL_QUIT
event”.

and on other systems its the same story regardless you mixing up user
interface ethics with bugs here! if you want ALT-F4 to call WM_DESTROY
catch the combo and pump the SDL_QUIT event.

Or… let SDL do that for us, so that three lines of #ifdef’d code doesn’t
need to pollute everyone’s app-level code. :smiley:

–
-bill!
bill at newbreedsoftware.com
http://www.newbreedsoftware.com/

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–

±-------------------------------------+

73

Or… let SDL do that for us, so that three lines of #ifdef’d code doesn’t
need to pollute everyone’s app-level code. :smiley:

Possibly replaced with a single environment push or similar disabling call :).

Obviously there’s been enough of a fervor to implement this thing, but
I’d really like to see it as either optional or disable-able (take
your connotative pick depending on which side of the fence you’re on
heh). Hopefully it’s done in a modular way to make other OS/WM
support easy, and with the possibility of other hooks for similar
desires (outside of just program exit… there might be other traps
needed such as iconify/fullscreen).

The fun comes in how to deal with different window managers on less
restrictive systems (unixes). I imagine they might present
alternative command sets for things, so making it a compile time
option might not fit some platforms… and then attempting to
automagically determine your window manager might yield some fun.
Granted, an immediate solution for Win/Mac is easy enough.

-Will

74

Holy crap, people. Can’t we all just get along? And by "get along,"
I mean: I suggest we DO have SDL support ALT+F4 keypresses. It keeps MY life
simple. (I don’t have to add "#ifdef WINDOWS if (event.type == yadayada…)“
in every event loop of every app, when I’m already doing
"if (event.type == SDL_QUIT)”)

Traditionally, in GUI toolkit, what happens is that either the
application provides a callback to the toolkit that gets called for
each messages and returns whether the application handled the message
or not, or there is a “get message” function, and an application is
supposed to call some “dispatch message” if it’s not a message that it
found “interesting” (i.e. it didn’t handle it). SDL does not provide
this mechanism: either the application handles the message, or it’s
dropped on the floor without further processing.

If I remember correctly, what happens on Windows is that the
application gets the Alt-F4 key pressed (well, okay, released,
actually, if I’m not mistaken, but you get the idea) message, and if
you want to do something with it, you do so, and don’t call
DispatchMessage. If your application didn’t handle it and calls
DispatchMessage, it will post itself a WM_DESTROY (or WM_CLOSE? I
don’t remember) message, which the application will then shortly
receive.

IMHO, the real bug is that SDL doesn’t have this structure that
usually handles that case, making it just plain hard in general to
"fit in" and forcing applications to re-implement those default
behaviours itself, and often in weird ways (the game I work on,
Quadra, quits with Alt-F4 on every platforms!).

Note that someone used to Xlib programming might think that this is
incorrect (there is no equivalent to DispatchEvent in Xlib), but it’s
just that Xlib is at lower level. The morally equivalent layer would
be Xt (among others, X11 is well known for giving a lot of choices,
for better or for worse), where you will find that an application does
XtAppNextEvent and XtAppDispatchEvent.On Sat, May 3, 2008 at 7:47 PM, Bill Kendrick wrote:

–
http://pphaneuf.livejournal.com/

75

Alt-F4 not generating an SDL_QUIT event on Windows is a bug and has been
entered into bugzilla. It will be fixed for the next release.

'nuff said.

Thanks!
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment

76

Pierre Phaneuf wrote:

Traditionally, in GUI toolkit, what happens is that either the
application provides a callback to the toolkit that gets called for
each messages and returns whether the application handled the message
or not, or there is a “get message” function, and an application is
supposed to call some “dispatch message” if it’s not a message that it
found “interesting” (i.e. it didn’t handle it). SDL does not provide
this mechanism: either the application handles the message, or it’s
dropped on the floor without further processing.

If I remember correctly, what happens on Windows is that the
application gets the Alt-F4 key pressed (well, okay, released,
actually, if I’m not mistaken, but you get the idea) message, and if
you want to do something with it, you do so, and don’t call
DispatchMessage. If your application didn’t handle it and calls
DispatchMessage, it will post itself a WM_DESTROY (or WM_CLOSE? I
don’t remember) message, which the application will then shortly
receive.

That’s an idea that has occurred to me as well at one point, in the
context of handling menu keyboard equivalents on Mac OS. My application
is cross-platform for the most part, but has a Mac-specific part that
sets up and handles a Cocoa menu bar. Some menu items in there have
keyboard equivalents, but they don’t work unless I check for them
manually in my SDL event handling. It would be nice to have an
SDL_PassEvent() function or something that could be called when the
application wants to pass an event that it doesn’t want to handle itself
back to the OS, where, on Mac OS, a key event would eventually be
matched against the menu keyboard equivalents. (I totally agree with
everyone that the application needs to get a chance to process a key
event itself first, before it is eaten up by the keyboard equivalent
handling of the OS (or windowing toolkit or window manager or whatever).)

I have no idea how easy this would be to implement on different
platforms, though.

I have no particular opinion on the immediate Alt-F4 issue at hand. Just
wanted to express my interest in an idea that may be worth looking into
for SDL 3 or something. :slight_smile:

-Christian

77

This will break a common windows game convention of using the F*
buttons for game actions, and will also make cross platform games
harder to write.

It will also break behaviour of past games and applications that
relied on ALT+F4 not quitting.

What is the work around for those not wanting this behaviour?

Is this change happening in the 1.3 or 1.2 series?On Sun, May 4, 2008 at 11:20 AM, Sam Lantinga wrote:

Alt-F4 not generating an SDL_QUIT event on Windows is a bug and has been
entered into bugzilla. It will be fixed for the next release.

'nuff said.

Thanks!
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

78

Ahh, the good old bikeshed debate…

http://www.bikeshed.com/

Seriously: It’s certainly OK to discuss this (mis)feature, but this
thread has totally lost proportion to the importance of this subject
sigh.

Bye,
Max

79

Trying to argue for or against the functionality is futile.
Decision’s been made :).

I’d trust he wouldn’t make it a
no-option-but-to-follow-this-hard-set-behavior patch. They’ll let us
know how it’s implemented and how to tune the behavior (if
applicable)… and hopefully have some kind of mention of where to
poke around to add similar support for the behavior on other platforms
:).

My only concern left is updating a system library / DLL out from under
an existing closed source app that expects to not have the
functionality on by default. But… how many closed source SDL apps
are there anyway ? And do they package their own SDL library in their
path so as to not use the system one if provided, etc … making this
a moot concern ?

-WillOn Sun, May 4, 2008 at 11:42 PM, Ren? Dudfield wrote:

This will break a common windows game convention of using the F*
buttons for game actions, and will also make cross platform games
harder to write.

It will also break behaviour of past games and applications that
relied on ALT+F4 not quitting.

What is the work around for those not wanting this behaviour?

Is this change happening in the 1.3 or 1.2 series?

80

That’s an idea that has occurred to me as well at one point, in the
context of handling menu keyboard equivalents on Mac OS. My application
is cross-platform for the most part, but has a Mac-specific part that
sets up and handles a Cocoa menu bar. Some menu items in there have
keyboard equivalents, but they don’t work unless I check for them
manually in my SDL event handling. It would be nice to have an
SDL_PassEvent() function or something that could be called when the
application wants to pass an event that it doesn’t want to handle itself
back to the OS, where, on Mac OS, a key event would eventually be
matched against the menu keyboard equivalents. (I totally agree with
everyone that the application needs to get a chance to process a key
event itself first, before it is eaten up by the keyboard equivalent
handling of the OS (or windowing toolkit or window manager or whatever).)

I have no idea how easy this would be to implement on different
platforms, though.

That’s a very interesting idea. I think it would need to be implemented in one of
two ways. Under Windows, events are sent to the application from the OS as
"messages," which SDL intercepts and processes to create SDL events. I
assume a similar system is at work in other OSes. So if you want to pass a
SDL event back to the OS, you either need to extend the SDL event structure
with a pointer back to the original message (which means keeping the message
in memory somewhere until the SDL event that it’s connected to has been taken
care of) or implementing a system that will run the process in reverse, creating an
OS message from an SDL event.

Neither of these are particularly efficient. If the only issue is menus, I think a better
solution would be to extend the event system as follows:

1.) Optionally, upon initialization, check to see if the current window has menus. (This
could be skipped under Windows, as every window has a System menu with one
registered keyboard shortcut by default. This may or may not be true under other
OSes.) Also, if it’s possible to not have a menu, set up an SDL_EnableMenu() routine
that the app calls when it creates menus.

2.) If menus are currently enabled, when trapping keystrokes, the event system should
automatically run each keypress by the window manager’s menu system to see if it’s
a valid shortcut, in addition to generating an SDL event. (This is probably the simplest
way to do it. It would be the application programmer’s job to make sure that the control
set doesn’t overlap with the registered menu shortcuts, to keep the same keypress from
having two effects.)

Good idea? Bad idea? What do you think?

----- Original Message -----
From: cwalther@gmx.ch (Christian Walther)
To: sdl at libsdl.org
Sent: Sunday, May 4, 2008 6:19:38 AM
Subject: Re: [SDL] Alt-F4 not working on Windows