>>>>>>RESOURCE=OFF in CONFIG.FPW, or pointed elsewhere where they do have rights, or put a FOXUSER.DBF and FPT there, flagged as read-only.
>>>>>
>>>>>This will not solve the problem. The temp files could be pointed to a network drive, but it will slow down the application.
>>>>
>>>>I've assumed that rights to C:\TEMP were explicitly granted, and not inherited downwards; if this isn't the case, then explicit granting of rights in the C:\TEMP directory is necessary, if that's where the problem lies. Unfortunately, what we are missing is the startup directory; if it's the root of C:, FOXUSER is the probable error.
>>>
>>>A couple of other thoughts this morning (I'm not so sleepy now). Try the WinNT temp directory (which is not C:\TEMP) or the user's profile directory.
>>
>>Agreed that using the NT temp file directory would be a solution, but it doesn't work unless you can resolve the path dynamically, or all stations have NT and Win9x installed to use the same absolute directory (CONFIG.FPW doesn't have a dynamic path resolution option AFAIK), and the profile directory is an even tougher nut to crack, since Win9x boxes may not have profiles enabled.
>>
>>Individual CONFIG files that point to a temp directory on a user-by-user basis based on the environment variable would be best in almost all cases, but it's more work when installing the app on each station, and when adding new users to the station.
>
>You can have your app generate a config for each station and use it next time. You can use any environment and other things while building it. The only problem is how to have your icons include the -cx:\wherever\mylocalconfig.fpw in the command line, which is beyond my powers.

I do generate the config file at each station as a part of my install, and then have a menu point to allow the end-user to change some of the settings (like where to put the temp files). If I don't have a local copy of a launcher application, whcih allows me to build a CONFIG.FPW in the startup directory for the application, I use the environment variable FOXPROWCFG to assign the local configuration file, and use a very minimalist CONFIG file - aside from turning off the resource and screen, and assigning the working file directories, I do all of my configuration settings using regitry entries or a configuration database.

If you don't use the Setup Wizard to put your application icons on the start menu and desktop, you can add the -c< whereever > to a shortcut's command line pretty easily. InstallShield has full access to the IShellLink API, and you can write a post-setup executable to manipulate the shortcut created by the VFP Setup Wizard - George Tasker's .DLL here on UT, as well as the WScript.Shell Automation object can read and modify the command line of an existing shortcut, as well as creating new shortcuts in the start menu and on the desktop.


It makes installation a bit tougher to write, but gives you much more flexibility. By not using the Setup Wizard to create your shortcuts, you can probably get around the problems you've noted.

>
>You may end up running your app from a batch file, and simply re-generate that batch file as well, so it contains the -c option pointing to the private config.fpw. Make sure your first batch file has some blanks to the end of the .exe calling line, because Windows/Dos will resume reading it (at exact byte position where the .exe calling line ended) when the app exits, and may actually find some extraneous characters when it gets a longer line now.

This I've seen :-)