>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.

:) Yes it was though at least for me. I also used ShellExecuteEx and it was a challenger to get correct hWnd (wish winapi coding made easier in VFP8 so we don't sort to fll:).
Cetin