>Thanks MARK, but I try to call WINZIP32.EXE, what can I do???

Three easy choice for launching and waiting on a WinApp:

(1) My API_APPRUN class, which can be downloaded from here on UT, can fire and wait on any other application to finish, Win32, Win16, DOS, batch files, etc. API_APPRUN uses the Win32 CreateProcess() API call to implement its functionality. It's pure VFP and API calls, and works on VFP 5 and 6 (VFP 3 requires a one-line change to a constant definition.)

(2) The ShellExecuteEx() API call can also wait on the termiantion of an app launched through it. I think there's code in Christof lange's STRUCT class here on UT; the last I looked it required you to include an external file that made some heap management functions available to VFP< but he was going to modify it to use the RtlMoveMemory() API call approach I use in CLSHEAP to implement things at one point, and I haven't checked on it in over a month.

(3) If you use the WSH (Windows Script Host) on all target machines, the Wscript.Shell automation object has a Run method that allows you to wait on the termination. This would require that you install at least WSH version 1.0 on all machines (built into Win98 and Win2K; it can be added to Win95 and WinNT either by installing IE4 or later, or by installing the self-extracting executable available from msnd.microsoft.com/scripting on any target with a late enough revision of Win95/WinNT, which basically means anything but bare-bones Win95 without SP1 or WinNT 4.0 before SP3 can handle it.) There's a lot in favor of the WSH if you deal with functionality that isn't easily available with VFP, including the ability to generate and execute VBScript and JScript within a VFP app and run it.

Win98 base incorporated WSH 1.0, and Win2K base includes WSH 2.0, which has lots of extra stuff. The current self-extracter and IE5 both have at least extended WSH 1.0 support, including updated VBScript virtual engines, and by now may well include full WSH 2.0 - WSH 2.0 was still in beta a month ago.