>Hi Dragan,
>
>I'll look into the issue of the paths. I can't remember what I did. I just remember it not working for me. Maybe I'll give it another try.
>
>Thanks!
>
>Hugh
>
>>>Hi Dragan,
>>>
>>>Thanks. I tried the API_AppRun class and it didn't work for me. Not sure why.
>>
>>One reason I had initial troubles with API_AppRun was incomplete paths. Once I gave it full paths (surrounded with quotation marks, if needed) for every file or directory mentioned in the command line, it worked fine. Could that be in your case?

It may not be API_APPRUN's fault entirely; DOS programs may be having problems with LFNs; even if they're launched, their own command line parser may not know what to do with a file with an LFN. You can convert your LFNs to DOS 8.3 compatible file names using the WSH Scripting.FileSystemObject or an API call.

Dragan is correct, there is a parameter passable at init (or you can treat it as a property after the class has run its init) that is used as the starting directory for the application. This is completely independent of the VFP CURDIR() - in fact, there's no reference back if you need something from there and have changed it! It's also not included in the search path for the launched executable. It's the second of three (in the release version) parameters - the command line, the starting directory, and the Windows Mode.

Two new parameters/properties will be making their public debut at GLGDW...bring your own floppies!