>If the Windows Script Host is an option, you can use the WScript.Shell object's Run method. It has an optional parameter that will force VFP to wait until the other program closes. It's decribed in last October's issue of the VFUG Newsletter (www.vfug.org), in the second in a series of article written by Ed Rauh and myself. You can check the article or series out on-line at the site.

In addiion, API_APPRUN, available in the Files Section, provides an alternative to the RUN command that can execute a WinApp modally; Doug Hennig used this in conjunction with WinZip in his article in the May, 2000 FoxTalk. API_APPRUN offers significantly better control than RUN, and needs no add-on DLLs to work.

Also, I'll be releasing LaunchDoc, a class based on ShellExecuteEx(), that will permit you to fire a document in a similar fashion to ShellExecute(), but with the exception of OLE servers that use a DDE interface to launch the documents, can wait on the launched document to be terminated before returning control to VFP - it doesn't handle certain MDI applications like Word, where the document may be closed but Word remains running. It will require CLSHeap and a new class library, SHELLEXECUTEX.VCX, which I'll be releasing once the beta tester finish nickle and diming me with anomaly reports and documentation is finished; it works quite elegantly with spawned VFP processes, launched Zip documents and the like. The class is in a closed beta, and once this completes, I'll release it here on UT. (IOW, don't ask for a pre-release copy to play with; testing is by invitation only.)

PS (George, you're on the invited list if you have time to play...)

Ed