>I have a FPW 2.6 app and in one place it calls a VFP simple app which sends data down a serial port to an external device.
>
>In my FPW 2.6 app it does a: RUN /N MYVFP.EXE
>Control is returned immediately to my FPW app, whereas MYVFP.exe can take a few seconds to run, and I only want to return to the calling App when my called App has finished. I tried putting a time delay in but this was not 100% satifactory as I am not quite sure how long the app will run for .. 3 seconds or 5 seconds or 7 seconds ......
>
>Is there any way of not returning to the calling APP until the called App has finished ?
>

In FPW (or pretty much any Win16 app), not really; the RUN with the /N parameter does not wait on completion.

Your best line of attack is to use RUN without the /N, to execute a DOS VDM. This will wait on termination, but can't run a WinApp directly. So you're looking at a .BAT file, with the VFP app executed with the START verb, using the /WAIT command line switch added to force the WinApp to terminate before returning control to the DOS VDM. You'll have to have a DOS box appear, but that's realtively minor compared to the other issues.

If the VFP app is launched with the command:

C:\MyPath\MYVFPAPP.EXE

the batch file would read something like:

ECHO OFF
START /WAIT C:\MyPath\MYVFPAPP.EXE
EXIT

Depending on your OS version, you may be able to add command line switches to prevent a second executable window from being opened as a result of the START command; the /B switch will try to use the existing console for the launched app, but is not supported by all platforms; you can also add the /MIN switch to run it minimized. You have to add switches to START before you specify the actual executable. You'll want to pre-create the .BAT file, and create a matching .PIF for it to ensure that it closes on exit from the batch file.

Your best bet is to get out of the Win16 environment and port your FPW into VFP, so that everything is Win32- it's actually a bigger problem than a DOS environment. You can't use automation, so WSH is out entirely; you might want to look at DDE as a mechanism for cross-process control, since FPW can be a DDE client, and create the VFP app as a DDE server.

Eventually, if you stick withy FPW and you need to perform IPC, you're going to paint yourself into a corner that you can't get out of. FPW is going to pose porting problems, and trying to rely on detecting program termination is ignoring the other possible results that might occur - how to deal with the child not successfully running, or hanging, or completing but failing while shutting down the app.