>I see now. I had thought that this (CONFIG.FPW) was something that I would set-up on the development machine and the compiled EXE would be affected.
>
>Re: take an existing executable that doesn't have a CONFIG.FPW, and put this CONFIG.FPW in place
>
>I did this and it shows that it is running as a process in the Task Manager.
>
>I added the _SCREEN.visible = .T. line in the program in the appropruate spot and it works as desired.
>
>Where is this documented in Help?
>

A bunch of places; try starting with Chapter 3 of the Installation Guide, Configuring Visual FoxPro and Chapter 15 of the programmer's Guide, Optimizing Visual FoxPro - both are in the on-line help in their entirety.

>Also, I have an opinion about this CONFIG.FPW stuff: This is dangerous. All someone has to do is create a CONFIG.FPW file and screw things up. I have a CONFIG.DBF that I distribute with my EXE to set machine/directory-specific settings. I can encrypt the fields for security. CONFIG.FPW is not and cannot be encrypted (right?). This is a little scary.
>

There are things that can only be set in CONFIG.FPW when your VFP session starts. The option to start with the VFP main window completely hidden (SCREEN=OFF), the drive and path to use for temporary files (4 separate settings, only settable in CONFIG.FPW), the option to start VFP with no RESOURCE (FOXUSER) file opened at the beginning of execution, and none created if one isn't present, and the maximum number of variable names permitted within your VFP app are all set in CONFIG.FPW. You can embed a CONFIG.FPW in your project (not my preference, since it won't let you specify the temporary file locations on a station-by-station basis), or point to a file with an arbitrary name and location using the -c command line switch, which could easily be built into a shortcut, or you can point to a file using a DOS environment variable FOXPROWCFG.