Mandy,
I'm near a conclusion. One thing I found out early already is, that the _VFP.hwnd is what GetForegroundWindow() will report as the OS foreground process foreground window, before anything else like your own main form becomes a foreground window. So even a windowless background process you compile as an EXE with hidden screen will take the active process and foreground window status away from your first starting EXE.
Which means it's true, you can do SetForegroundWindow too early.
I added waiting for the background process window to appear using GetWindowTitle. But even then and even adding an extra wait time, SetForegroundWindow has no effect in the first EXE trying to get back the active state. So it seems to me none of the conditions necessary for SetForegroundWindow to work are satisfied once the bakground.exe has become the last started process with the last started form and therefore the foreground process. One detail is maybe important for it: I added an editobox to the background process main form, so this window actually has an input control that can become an active input.
But I'd not give up at that point to be able to start a background process EXE and still stay being the active form should be possible. There is one obvious solution, of course: Turn it around. Let the user start what becomes the background process. When this EXE starts your main foreground process EXE, that EXE and its main window become active and focused without any efforts of using API routines at all.
So it's just a matter of accepting that the foreground process shouldn't be started first - and the problem is solved.
I also second Steve, that it's a mere click into your main app. If that annoys you, I think just turning it around , as said, would get rid of the focus problem. The only price you pay, maybe, is that now the EXE name the user starts and will associate with your application is actually not what he'd need to look for in the Task Manager. He'll find it there, but it actually is just the background process.
I think there are still possible simple ways out of this "dilemma": Name the exe the user starts Applaunch.exe and your main application process App.exe and the user will know he just started the launcher and App.exe is the main process. The Applauncher.exe can stay an active process and do background tasks or whatever you intend this background process to do after it did RUN /N App.EXE.
The only thing that would make it worthwhile is if a main process.exe should be able to start many background processes, with none of them taking the foreground process/form state away from it. Perhaps looking into
would give a solution to that. It's the main concern of this project to enable parallel processing. Not as elegant as using multiple threads, which would actually be another possibility, albeit even more complicated. Since even single CPUs nowadays have several cores that allow running multiple processes truly parallel it is a nice thing to have the possibilies of it at your finger tips.
I think the way to get to multiple background processes is to use CreateProcess and gain fuller control about what actually happens in these child processes so they don't take away the foreground status from the main process that starts them.
Chriss