How to specify a config.fpw file
The actual file name does not matter as you can specify the configuration file which Visual FoxPro is to use as a command line parameter by using the '-c' switch in the command line which is used to start Visual FoxPro. So to set up your own configuration file (for example for a specific application) use the following command line:
G:\VFP60\APPS\MYAPP.EXE –cG:\VFP60\myconfig.txt
How VFP locates its configuration file
The default behavior of Visual FoxPro, in the absence of a specific configuration file, is to search the following locations for a file named 'config.fpw' in this order:
- The current working directory
- The directory from which Visual FoxPro is being started
- All directories in the DOS path
If you are using the '-c' switch to specify a file named other than the default, or in a specific location, you must include the fully qualified path and file name. This provides a simple method of handling the initialization of different applications installed on the same machine.
How VFP starts up when no configuration file is found
If no configuration file is found or specified, then Visual FoxPro will be started with only those settings that are specified in the Options Dialog (located on the TOOLS pad of the main Visual FoxPro menu).
Why these settings in particular?
The answer is simply that all of the settings from this dialog are actually stored in the
Windows Registry and can be found under the Registry Key:
HKEY_CURRENT_USER\Software\Microsoft\VisualFoxPro\6.0\Options
Including a configuration file in the project
One little "trap" to watch out for – if you add a configuration file named 'config.fpw' to your project as a text file, it will be INCLUDED in the project by default. When you build an .exe from the project, the config.fpw file will be built into the resulting file. Since Visual FoxPro looks for a file named 'config.fpw' during startup, it will always find the built-in version first and will not look any further. This would apply even if you were to explicitly specify a different configuration file using the '-C' switch! Your specified file would be ignored, and the built-in congfiguration file would be executed. The best solution is NOT to add your configuration file to the project at all, but if you do, to make sure that it is marked as 'excluded' from the build.
How to suppress a configuration file
Starting Visual FoxPro with the command line parameter '-c' alone suppresses the default behavior and prevents any configuration file that may be found from being run. The result is that you can force Visual FoxPro to start up with its default settings only.
How to determine which configuration file is being used
One of the commonest problems with configuration files is failing to ensure that Visual FoxPro is reading the correct CONFIG.FPW. As noted above, if Visual FoxPro can't find a configuration file, it will search the DOS path and simply use the first one it finds. This could be anywhere on a network. The SYS(2019) function will return the full path and file name of the configuration file that Visual FoxPro actually used. If no configuration file was found, the function merely returns an empty string.
What goes into the configuration file?
Now that we know something about how the configuration file is used, the next question is what can we put into it? The answer is quite a lot! Essentially there are three categories of things that can be specified in the configuration file as follows:
Special settings
There are a number of settings that can ONLY be made in a configuration file. (For full details see the "Special Terms for Configuration Files" topic in the Visual FoxPro online Help and the entry under "Configuring Visual FoxPro" in the online documentation.) Notice that the ability to set the location for temporary files is also available in the Options Dialog. Specifying the TMPFILES location in the configuration file will override any setting that is made there and can be useful when you need to differentiate between development and run time locations for temporary files.
One other setting that can be used in the configuration file only, but which is not included in the Help file list is "SCREEN = OFF". This prevents the Visual FoxPro main screen from being displayed when your application starts and prevents the annoying 'flash' of the VFP screen that still occurs even if your startup program turns off the main screen with the command _Screen.Visible = .F. (which enables you to present your application's initial form, or a "splash" screen, without displaying the main VFP window first).
SET Commands
Virtually all of the standard SET commands can be issued in a configuration file. The only thing to watch out for is that some settings are actually scoped to the datasession. (See the "Set DataSession" topic in the online Help for a full listing.) So, there is little point in specifying them in the configuration file if you plan to use Private DataSessions for your forms. The syntax for specifying SET commands in the configuration file is a simple assignment in which the keyword 'SET' is omitted:
DEFAULT = C:\VFP60\TIPSBOOK
DATE = BRITISH
Commands
Well actually you can only specify one (count 'em!) command, and it must be the last line of the configuration file. Like other configuration file entries, it is entered as a simple assignment:
COMMAND = DO setupfox
What is the use of just ONE command? Well, quite a lot really because that one command can call a FoxPro program, and that can do a lot of things!
One of the main limitations of the configuration file is that you cannot actually set things that are internal to Visual FoxPro (e.g. system variables) because, when the configuration file runs, Visual FoxPro hasn't actually started. Using this setting allows you to specify a program file to run immediately after Visual FoxPro has started up – even before the command window is displayed.
This program can then be used to set up your development environment the way that you really want it. For example, here are some of the things that are in our standard setup file:
*** Standard 'SET' options (These could be entered directly into the Config File)
SET TALK OFF
SET BELL OFF
SET SAFETY OFF
SET STATUS OFF
SET STATUS BAR ON
SET DATE BRITISH
SET CENTURY ON
*** Re-define Function Keys
SET FUNCTION 2 TO "CLOSE TABLES ALL;CLEAR WINDOWS;"
SET FUNCTION 3 TO "CANCEL;SET SYSMENU TO DEFA;ACTIVATE WINDOW COMMAND;"
SET FUNCTION 4 TO "CLEAR ALL;SET CLASSLIB TO;SET PROC TO;"
SET FUNCTION 5 TO "DISP STRU;"
SET FUNCTION 6 TO "DISP STAT;"
SET FUNCTION 7 TO "DISP MEMO LIKE *"
SET FUNCTION 8 TO "CLEAR;CLEAR WINDOWS;"
SET FUNCTION 9 TO "MODI FORM "
SET FUNCTION 10 TO "MODI COMM "
SET FUNCTION 11 TO "DO setpath WITH "
SET FUNCTION 12 TO "=CHGDEFA(); "
***Set up the Screen properties
_SCREEN.CAPTION = "VFP 6.0 (Development Mode)"
_SCREEN.CLOSABLE = .F.
_SCREEN.FONTNAME = "Arial"
_SCREEN.FONTSIZE = 10
_SCREEN.FONTBOLD = .F.
*** Run Cobb Editor Extensions
DO G:\VFP60\CEE6\CEE6.APP
*** Set up some On Key Labels
ON KEY LABEL CTRL+F10 suspend
ON KEY LABEL CTRL+F11 o=SYS(1270)
ON KEY LABEL CTRL+F12 RELEASE o
*** Set up any system variables required
_Include = HOME() + "Foxpro.h"
_Throttle = 0.1
*** Set up any standard "Public" variables
PUBLIC gcUserName, gcAppPath, gcDataPath
STORE "" TO gcUserName, gcAppPath, gcDataPath
*** Run Standard Path Set-up
DO setpath WITH 1
As you can see, apart from setting up the basic VFP system environment and handling our own particular requirements, this 'one' command available in the configuration file has now been used to run a couple of other programs (CEE and our own SetPath procedure) so we get three for the price of one. By putting these settings in a program, we also have a simple way of re-initialising the environment by re-running this program at any time.
Giving VFP a path
Visual FoxPro has the ability to use its own search path and, as a general rule, you should always specify a path for Visual FoxPro for both development and production environments - although they may be very different (see above for one way of handling this requirement). Setting a path for Visual FoxPro does not change the normal DOS search path but can significantly speed up your application by limiting the places that Visual FoxPro has to search in order to find its files – especially in a network environment.
How VFP looks for files
By default Visual FoxPro uses the current directory as its 'path' and you can always restore this setting by simply issuing: SET PATH TO
However for more sophisticated applications, and in development, you will normally have some sort of directory structure and you should always set a proper search path to include all required directories.
Setting the default directory Normally you still will want to set a default (or "working") directory – this is where Visual FoxPro will look first for any file that it requires. This can be done in a number of ways,
depending on your requirements:
- Specify a default in the Configuration File using DEFAULT = <path to directory>
- Set the default directly in code using SET DEFAULT TO <path to directory>
- Change to a directory using the CD <path to directory> and issue SET PATH TO
Note that using the Get, Put or Locate functions (e.g. GetDir()) does not change either the default directory or the path. To change the default directory interactively use: SET DEFAULT TO ( GetDir() ). (The 'CD' (or 'CHDIR') command can also be used to change both drive and directory to the specified location).
Using the SET PATH command
Setting the path is simplicity itself. Just issue the SET PATH command followed by a list of the directories that you wish to include. You do not need to fully qualify subdirectories – separating them with either commas or semi-colons is sufficient. The example shows a typical Visual FoxPro search path:
SET PATH TO G:\VFP60;C:\VFP60\TIPSBOOK\;DATA;FORMS;LIBS;PROGS;UTILS;
To retrieve the current path setting you can use the SET() function (which will work with most of the Visual FoxPro SET commands) as shown below. You can assign the result directly to a variable or, as shown below, directly to the clipboard so that you can then paste the current path into a program or documentation file:
_ClipText = SET( 'PATH' )
Visual FoxPro allows the use of both UNC path names, like:
\\SERVERNAME\DIRECTORYNAME\.
and allows the use of embedded spaces (when enclosed in quotation marks) in directory names like:
"..\COMMON DIRECTORY\"
However, while the latter may be allowed, we tend to subscribe to the principle that 'although you can use embedded spaces, arsenic is quicker.' (The same, by the way, applies to file names with spaces!) While improving readability, spaces can also cause problems when trying to handle files and directories programmatically and we still feel that the best advice is to avoid them wherever possible in applications. For example, the following code works perfectly well for conventional directory names, but will fail if the selected directory contains embedded spaces:
LOCAL lcDir
lcDir = GETDIR()
IF ! EMPTY(lcDir)
SET DEFAULT TO &lcDir
ENDIF
Making sure VFP is only started once
So far so good! We have managed to cover the process of starting VFP and setting up the basic environments for both development and production. At this point one of the things we all come across is the absent-minded user who minimizes an application and then, ten minutes later, starts a fresh copy from their desktop. Within the hour they have six copies of the application running and are complaining that their machine is slowing down. What to do? (Apart from shooting the user which, appealing though the idea may be, is generally frowned upon and, depending on their seniority, may also be a career-limiting move.)
Closing VFP down
Thus far we have been concentrating on setting up and managing the Visual FoxPro environment, however, the way in which you close down Visual FoxPro is just as important. In the run-time environment there are two ways of initiating the closing down process. Firstly through the use of the CLEAR EVENTS command, either within a menu or in the Release method of a form. Secondly through the standard windows close button of the main Visual FoxPro window. Fortunately, Visual FoxPro provides us with a global handler for the close down process, irrespective if how it is initiated – the ON SHUTDOWN command.
What is an On ShutDown procedure?
Like other ON commands, the ON SHUTDOWN command is implemented by a special handler that is outside of the normal Visual FoxPro event processing loop. When invoked, control is immediately transferred to whatever command, or function, has been specified as the target. This is by far the best way (if not the only way) to ensure that Visual FoxPro closes down cleanly without the irritating the 'Cannot Quit Visual FoxPro' message.
What triggers an On Shutdown procedure?
The command specified in ON SHUTDOWN is executed if you try to exit Visual FoxPro by clicking the 'Close' button in the main Visual FoxPro screen, by choosing Exit from the FoxPro control menu, or by issuing the QUIT command in a program (or the command window!). Additionally it will be triggered if you try to exit Windows while Visual FoxPro is open. (Control is returned to Visual FoxPro and the specified ON SHUTDOWN procedure is executed.)
Great information about foxpro configuration files.
ReplyDeleteVisual FoxPro to .Net
VB.Net Migration
Convert ASP to ASP.Net