>>(a) AFAICS it doesn't work because the parameter to GetFile() requires a path in the first place,
>>
>>Not if the file's in the current working directory.
>
>True. But if it's not you get an OLE error and if it is you may as well have used CURDIR() in the first place :-)

Not really, wherever the application is started from is the working directory. Plus Windows will search the path.

>>(b) we can't rely on Scripting being available
>>
>>Well, if anyone is still running Windows 95...you've got a point. However, it's a required file for Windows 2K.
>
>It's installed by default but 'required'? IAC it's the work of a moment for an admin to delete Wscript.exe and I'm afraid we certainly come across too many of those to rely on it being available.

Any web page running either jscript or vbscript will require it. Further, Windows since 2K has a habit of repairing itself. So if a file is required, you've got to jump through major hoops to get out permanantly. Lastly, do they delete cscript.exe as well? How about command.com?:-)

>>One question. Do you set the temp path in config.fpw? I do. I assume that you're do this for the same reason I set it...Cleanup old tmp files.
>
>It's set in the registry on my development machine and SYS(2023) returns this path. We don't specify a path at installation so for most users it tends to be the 'Documents and Settings' pathed temp folder.
>The problem seems to be that SYS(2023) relies on a call to Windows GetTempPath() if there is no VFP environmental setting and it is this that is returning the DOS path name. Another implication of the use of GetTempPath() is that SYS(2023) will not neccesarily return a valid path - something I had not previously been checking for...

GETENV() with either TMP or TEMP will return the temporary file path name, but, like before, it will be the short path.