>>>Sorry to pick your brain again, but you said you put it in the config.fpw. So you allow the users to change this config file?
>>>
>>>I don't feel comfortable hard coding the temp to always be say C:\TEMP, their C: drive might be the smallest drive and not have the room available. We have our config.fpw compiled into the exe. Is this not a good idea? I thought that would make sure the application was using the right config file.
>>
>>The problem is that if you compile it into the executable, you can't override it, and if you set TMPFILES in the CONFIG.FPW, you need to be sure that the directory specified exists and the user has full rights in the directory, and that the drive has plenty of space for it to work with.
>>
>>I find that building a CONFIG.FPW on each user system, and placing that and the executable on the local system, pay big dividends, especially in conjunction with a launcher application that can keep the required local files up to date before firing off the actual application.
>
>One thing that crosses my mind is that one can always read the config.fpw from the app, check the TMPFILES setting, and then check the space on the drive where it resides. If there are other local drives (this would need some API, I gues) with more space, we could simply dump all our files (older than, say, two days) from the old temp directory, create it on another local drive, and rewrite the config.fpw for the next launch of the application. I'm assuming there's a local config.fpw.

Actually, DISKSPACE(), in conjunction with DRIVETYPE(), could do this pretty easily! If you're using a launcher, the launcher could do this and shut down/restart itself if it discovered that the CONFIG.FPW needed to be changed.

SYS(3056) implies that it will re-read a CONFIG.FPW setting; under VFP6, it may be possible to do this check, rewrite the CONFIG.FPW (it'd have to be a replacement of the same file pointed to by SYS(2019)) and issue a SYS(3056,0) to re-read the configuration. It doesn't seem to work, so I may be misinterpreting things, or it may be that running a VFP executable on a system with the development version of VFP installed reads the registry values.