>I am wondering about vfp's behaviour when executing the run command.
>
>A user just started using my new application. In all my testing on my machine(s) the following code executes fine:
>
>**hey don't worry about the macro substitution its an old habit!
>run winzip\wzzip &lctzipfile export_temp\*.*
>copy file (lctzipfile) to (lczipfile)
>
>also similar code such as:
>
>copy file (lcsourcefile) to (lctargetfile)
>odoc.open(lctargetfile)
>
>executes fine on my machine(s) (pentium 3 700/win98 and pentium2 450/win2000server)
>
>but the same code fails on my clients machine. (pentium 3 700/win2k professional)
>
>
>I am wondering whether control will return to vfp before the run command is finished executing, such that the file could still be in the middle of being written to at the time the next command executes?
>
>If so, is there a way to control the behaviour of the run command such that vfp waits until it is finished before executing the next line? Or are there alternatives to run that should be considered?
>
>In the case of the copy file command - does vfp just hand off control to an OS call, and possibly return before the command is completed?
>
>With regard to a possibly related subject, I believe (but I'm not sure) that in previous testing, using relative paths in the source and target files failed under win2k but succeeded using full paths, and worked using both relative paths and full paths under win98. But I can't imagine that win2k wouldn't understand a relative path! But maybe I am confused about this. Is it possible that the copy command takes a 'few milliseconds longer' with a full path than with a relative path, and therefore, if in fact the run returns before the copy is complete, I have a failure related to this problem, not the relative pathing?
>
>
>TIA

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.