Window losing focus - stopping the App?

[Sivak]

Hey all.  I've got my speed problems resolved, but now I have another one I was hoping to get fixed up:

If you click away from the window, I want to have it so the application stops running.

It's also a similar case when I try to drag the window around.  It'll stay frozen and update when you let go of the mouse.

Are there easy ways to detect this?  Thanks.

[Laurent]

If you click away from the window, I want to have it so the application stops running.

You can use the Event::LostFocus event.

It's also a similar case when I try to drag the window around. It'll stay frozen and update when you let go of the mouse.

On Windows, the OS runs an internal loop as long as you drag the window. So your app is stuck until you release the mouse button, and there's nothing I can do about it.

[Sivak]

On Windows, the OS runs an internal loop as long as you drag the window. So your app is stuck until you release the mouse button, and there's nothing I can do about it.

I was looking into this and found that Windows issues messages before and after such a loop so that your program can brace itself for it.

These are them, I believe...
WM_ENTERMENUMOVE / WM_EXITMENUMOVE
WM_NCLBUTTONDOWN / WM_CAPTURECHANGED
WM_ENTERSIZEMOVE / WM_EXITSIZEMOVE

Right now I have a sort of hackish solution to the drag problem, which is fine, but I think having something in SFML would be a good way to go.

Hope this can be done.  Thanks.

[Disch]

Hello, I've been helping Sivak with his program and am the one who suggested he posted those windows messages.

I just want to say that I've experienced this problem in Windows first hand.  An emulator I was writing way back had the problem where if you pressed alt, enetered a menu, or dragged/resized the window, the program would not only hang, but the audio would loop (I was streaming with directsound, and the loss of CPU attention prevented me from updating the buffer, causing the same 80 ms data to loop repeatedly -- yuk)

This was an unnacceptable situation for my program so I looked into solutions and found the messages Sivak posted.

I could pause my audio when the first message in the pair came, then unpause and resync my timing mechanism when the latter came.  Worked like a charm.

I think that having SFML forward these messages to programs would be of great use and a fantastic addition to SMFL.  I'd bet this is a common problem for many users.  And I know it would certainly solve the problem Sivak is having.

Thanks.


EDIT:

I should note that the problem Sivak is having is not that the program is pausing, it's that the timing mechanism is trying to "catch up" after the long pause.  So it runs at super speed after the pause.

So what he needs is a way to detect when the pause is starting/finished so that he can adjust the timing mechanism appropriately.

I just reread the thread and this point wasn't really made clear.

[Laurent]

I understand, thank you for sharing a "real life" problem caused by this behaviour

However if Sivak's problem is about catching up after a long pause, maybe he can just fix that directly, instead of focusing on this Win32 specific behaviour.
Maybe a simple test could be enough?

Code: [Select]

if (elapsedTime > 1.f) // more than 1 second
{
    elapsedTime = 0.f; // ignore the long pause
}

[Disch]

Heh, that's actually the solution he has in place right now, only he's using 150 ms instead of 1 second.

It works for the most part, but it's still possible for the problem to occur is the pause is short enough.

But whatever...  I'll let him field it from here since it's his problem and ultimately his decision on how he wants to go about fixing it.   I just wanted to chime in and explain the WM idea a bit more.

Thanks for your time!