The "proper" way to detect an app context switch

I’ve got a full screen SDL based app that I’d like to pause (stop
blitting, stop sound, etc…) when the context is switched away. I’ve read
that one way of doing so is checking to see whether or not a blit fails,
and if it does, pause.

This seems like throwing a rock through a window to see if a light comes
on rather than knocking at the front door. :wink: Is it guaranteed that I’ll
get some sort of message (like SDL_ACTIVEEVENT) when my app is about to be
switched away (or back to), or do I need to check both the blitting result
code AND look for an ACTIVEEVENT message? Of course I want to remain as
compatible as possible across platforms.

Thanks!

–>Neil-------------------------------------------------------------------------------
Neil Bradley What are burger lovers saying
Synthcom Systems, Inc. about the new BK Back Porch Griller?
ICQ #29402898 “It tastes like it came off the back porch.” - Me

This seems like throwing a rock through a window to see if a light comes
on rather than knocking at the front door. :wink: Is it guaranteed that I’ll
get some sort of message (like SDL_ACTIVEEVENT) when my app is about to be
switched away (or back to), or do I need to check both the blitting result
code AND look for an ACTIVEEVENT message? Of course I want to remain as
compatible as possible across platforms.

Use SDL_ACTIVEEVENT, you are guaranteed to get it when your application loses
focus (and if you don’t, it’s a bug) :slight_smile:

See ya!
-Sam Lantinga, Software Engineer, Blizzard Entertainment

Neil Bradley wrote:

I’ve got a full screen SDL based app that I’d like to pause (stop
blitting, stop sound, etc…) when the context is switched away. I’ve
read that one way of doing so is checking to see whether or not a
blit fails, and if it does, pause.

Although Sam already provided the correct answer, there’s one more
thing… I believe the ‘blit failure’ method of detecting a context
switch is just a side-effect of the fact that DirectX has a tendency to
lose its surfaces when another application takes the focus. Therefore
you won’t always get this failure on Windows, and I don’t know if you
get it at all on platforms that do better surface management than
DirectX does. From the docs I have:

“If either of the surfaces were in video memory, and the blit
returns -2, the video memory was lost, so it should be reloaded with
artwork and re- blitted. […] This happens under DirectX 5.0 when the
system switches away from your fullscreen application. Locking the
surface will also fail until you have access to the video memory again.”–
Kylotan
http://pages.eidosnet.co.uk/kylotan

Use SDL_ACTIVEEVENT, you are guaranteed to get it when your application loses
focus (and if you don’t, it’s a bug) :slight_smile:

On X11, this gets triggered when your mouse leaves the window, even if you
Window Manager doesn’t switch the keyboard focus away. Is this a bug?

–ryan.

Use SDL_ACTIVEEVENT, you are guaranteed to get it when your application loses
focus (and if you don’t, it’s a bug) :slight_smile:

On X11, this gets triggered when your mouse leaves the window, even if you
Window Manager doesn’t switch the keyboard focus away. Is this a bug?

There are three different flags that can be associated with this:
application focus, mouse focus, and keyboard focus. You can gain
or lose any of the above to get an SDL_ACTIVEEVENT.

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

There are three different flags that can be associated with this:
application focus, mouse focus, and keyboard focus. You can gain
or lose any of the above to get an SDL_ACTIVEEVENT.

Crap, I always thought the “state” field was a boolean value. My bad.

Well, now I can handle those obnoxious instant messenger popups with the
ut2003 client, I guess. :slight_smile:

–ryan.