>when updating program files on client computers i have been sending a zip of
>the new .prg (about 30 at a time usually) then once downloaded at the other end,
>client vfp shuts down - then at startup i have vfp remove all .fxp files.
>
>the problem here is that the program is sluggish for first few run throughs as the
>fxp files are re-created.
>
>Is there a better way of handling the fxp files? for example can i send the new .prg 's together with
>the related fxp from my computer and eliminate the removal of all fxp files at the other end.
>
>any suggestions appreciated.
>
>tnx k

We've always used a .EXE for distribution, and actually a two-part .EXE system. We have LAUNCHER.EXE, which can be named anything, but reads a .DBF file of the various versions installed. Whenever more than one version is available it will ask the user which one they want to run, or there are switches to allow it to automatically run the latest version, and so on. In that way we simply distribute versions like this:

* Version 1.00 through 1.02
myapp_100.exe
myapp_101.exe
myapp_102.exe

* Version 2.00 and so on...
myapp_200.exe

The launcher.exe never changes, but reads in a table which has information about the user settings. This usually has a user table as well with login abilities, so a superuser can log in and make changes to the settings, remove bad versions, run fixes, etc. Once the launcher has been setup, its purpose is to read the table and see what executable is supposed to be run, and then run it with a "DO (table.cDosName)" command, which runs the executable as per its information stored in the table. There is error checking and what not to make sure the file exists, but in general that's what happens.

Distributing the .PRG files is a good thing in terms of sharing your source code. You could also consider sending them the .FXP files as well, and then not deleting them at startup.