In regard of nShowWindow paremeter of ShellExecute, you can experiment a little with an own EXEcutable you create wth VFP
Default behviour of applications is to restart their main window in the size, position and state it was when you last exited from them. That happens, when you doubleclick it. That should also happen when using 5.
4 means the active should stay the active window, that doesn't say anything about the z-order, the active window can still be overlayed with the new (Explorer) window.
That already indicates you should handle either the new or your own apps window as aftermath.
What adds to this is, that the code inside an EXE may override what the OS does with the main window, in the anner as VFP code can set _SCREEN.WindowState. Simply test with an own EXE and have the code _SCREEN.WindowState=2, that will maximise the _SCREEN, no matter how Windows sets the size and position, also if you set the _SCREEN to normal size and resized and repositioned before your last exit.
I'm unsure what happens in which order, so you may get quirky behaviour anyway. If your application window actually is kept active, but still the Explorer Window draws in front of it, this will also not casue the deactivate event, so one further thing is becoming handy, or should I say handly? If the return value of ShellExecute is no error code (<=32) but a larger number (>32) it's the hwnd handle for the new main window, so you can act both on _screen and the main Window of the application you started.
Besides SetForegroundWindow you also have BringWindowToTop and SetWindowPos, which handles the Z-Order and x,y positions. I haven't experimented with this myself, though.
Bye, Olaf.