If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register or Login
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Re: Program Pauses When Loses Focus

There is no reason why loosing focus would cause it to "pause", other than the application having been specifically coded to do so. Possibly as a way to increase the response of other apps when that app has been set to the background.

if it's a console app, then there's nothing at all that would realistically cause that (other than some funky windows hacks)
and if it's a GUI app, the obvious reason would be that it goes into a paused state when it has received a WM_ACTIVATE (with WA_INACTIVE) or a WM_SETFOCUS indicatng focus loss.

Other than that, it might give the impression it "stop reacting" because it's no longer receiving keyboard/mouse input, and as a result seems to be halted because it has nothing to process.
a GUI program that displays a caret will typically keep receiving carret on/off messages in some way (the 'undocumented' WM_SYSTIMER or message 0x0118).
If the app is not very well written, it could manifest a 'pausing' behaviour when it is trying to get windows messages when there are none queued.

Re: Program Pauses When Loses Focus

I agree to OReubens that the "idle inactivity" of your program may resut from the fact that the program's activity is solely driven by receiving and handlng window messages. If the handling you're after is done unconditionally inside the message loop (i.e. regardless of whatever message is received actually), it may already be sufficient to just allocate a Windows timer and have it fire WM_TIMER messages so the message loop's body gets executed. Otherwise you'd need to set up a WM_TIMER message handler and take appropriate action in there. (If the program originally was written for Windows 3.1x, or maybe Win95 too, that may not really have been an option back then: Windows timers were a rare and precious resource these days; IIRC there has been a total of four of them available - system-wide...)

The timer approach IMO is more of a hack, however. You may get considerably smoother response from your program by observing whatever you need from a worker thread and fire adequate messages/events towards your GUI thread from there. That also would require more effort on your side, though.

None of the above considerations are specific to assembly language, though, BTW.

I was thrown out of college for cheating on the metaphysics exam; I looked into the soul of the boy sitting next to me.

This is a snakeskin jacket! And for me it's a symbol of my individuality, and my belief... in personal freedom.