>>>>I have a small secondary VFP application, (performs basic housekeeping), I want to run from a primary application with control immediately returning to the primary application after launching the secondary VFP application.
>>>>
>>>>The secondary application simply shuts down on completion.
>>>>
>>>>What's the best approach please?
>>>>
>>>>Dennis
>>>
>>>Dennis,
>>>Use ShellExecute. That way each app you launch would run independetly as if they're launched separately.
>>
>>Actually, < shameless self-promotion > I'd recommend using API_APPRUN to do this < /shameless self-promotion >; it returns an hProcess which will allow you to modify the priority of execution and allows you to check on the completion state of the launched application. API_APPRUN can be downloaded from the Files Section.
>
>Ed,
>I'd do too :) However do you remember my question about it. It doesn't work well with multiple launches of some applications (ie:word). It returns immediately when another instance launched. As I remember it was using waitforsingleobject but not waiting. It's word's fault IMHO for it spawns all instances under the same pid. I created a .fll just for that. My fll is no superior to API_Apprun, just different it has enumerating of windows and checking completion explicitly with hWnd+caption (again a word thing. when an instance is exited (first one and there are others) hWnd stays there just setting the caption to 'nothing').
>Cetin

Yes, I remember, and ShellExecute() is even worse - it will try to use a DDE session to an existing development session rather than ever launching a new copy of the runtime < sigh >. Short of Finding an hWnd that stably remains open throughout the life of the edit with apps such as Word, there's little that can be done - I went ahead and implemented ShellExecuteEx() and in the event of launching a second thread in the app, it returns an hProcess of 0 (a really useless thing to do) and doesn't hand you a threadid, which could be used to instance an hThread which could be monitored.

It's a tough situation, that I can only see resolving by launching an InternetExplorer.Application instance, and having that then steer to a Word document; while the started Word session is just as indistinguishable from other Word sessions, if you code the InternetExplorer.Application instance to close itself after it returns from Word being invoked to handle it's document reference, then you can monitor the existance of the InternetExplorer.Application instance via Shell.Application's Windows collection - each member of the collection is an instance of the InternetExplorer.Application object running in the current desktop context, so by polling it with a timer and spinning through the collection with FOR...EACH to see when the instance of interest dies, you can indirectly track it that way, but nothing stops you from closing the Word doc and starting another one in the indirectly spawns Word instance.