Printable View
I have a legacy program (about 15+ years old) that pauses whenever it loses focus. I'd like it to continue running even if it loses focus.
My knowledge of assembly is very basic. I've searched for a focus test as well as pause instructions. However, I haven't had any luck.
It could be something very simple that I'm overlooking. So any insights would be appreciated. Thanks. :)
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.
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.