Visual FoxPro at development and runtime

There are times when you need your program to behave differently at runtime than it does in the VFP development environment. It might be that you do not want to be using the live data for development so you must switch between test and live data when you distribute the database. It might be that you want to see some debug information in the development environment without showing it to the user. You can make changes to your code just before you distribute it but if you do this manually then there is the danger that one day you will forget. It's better to switch automatically.

The problem falls into two parts:

  • detecting the environment.
  • changing the behaviour.

Detecting the environment

At different times I have used four techniques to determine whether or not the executable is running from within the development environment. Each has its advantages and drawbacks:

  1. Use the VERSION(2) function to determine which version of FoxPro is running. This returns 0 for RunTime, 1 for Standard, and 2 for Professional.
  2. Use the SYS(0) function to get the user's logon name. SYS(0) returns a string in the form:
      user name#machine name.
    I use FoxPro's AT() function to find the position of the hash character in this text and then read all the characters to the left of that position. If the user name is 'GF' then I assume that this is me working in development mode. A simple approach that can give me debugging information in the runtime environment on any machine. It will of course fail if any a user on a another site just happens to have 'GF' as their username.
  3. Pass a parameter into the executable. Treat Main.Prg as though it were a procedure by starting with an LPARAMETERS statement and pass the parameter in by adding it to the command line in the desktop shortcut. Use the PCOUNT() function early in Main.Prg to detect whether or not a parameter has been supplied. If there's no parameter, I must be in development mode.
  4. Use the FILE() function to see if there is an INI file in the same directory as the executable. I can either use the simple existence of the file to indicate whether Fox is in runtime or development mode or I can read setup parameters from this file to fine-tune the program's behaviour.

Whichever technique I have used to detect the environment, I always set up a global flag at the start of the application so that I can use it throughout the program to set development options like SET ESCAPE ON or SET PATH

Switching to a new path

You can either use the SET PATH command to tell FoxPro where to find its data files or build a fully-pathed name for each file explicitly. I prefer to use the general SET PATH technique because it will apply throughout the application. It can be useful to store other files - such as an audit log for example - in the data folder too.

There are two techniques to use with the SET PATH command. One option is to name the data path explicitly:

IF glDevMode
   *-- Use the test files in the local Data folder.
   SET PATH TO Data
ELSE
   *-- Use the data on network drive J
   SET PATH TO j:\LiveData
ENDIF

The other technique is to build (or read) the path as a string and use macro substitution:

SET PATH TO &lcDataPath

In both cases remember that you will have to add quotes around the path if it includes spaces.

Other behaviour to change

The position of the data files is perhaps the most common thing that has to change between development and runtime. Other changes that might be useful are:

  • Send all reports to proview or to a file by default when in development mode. A lot of user reports go straight to printer so that the user doesn't have to click twice. Developers don't need to produce a paper report each time. Most of the time we just need to see a preview so it makes sense to default to PREVIEW in development mode.
  • Show the true primary key of a table as well as the supposedly-unique ID seen by the user.
  • Display the messages from SET NOTIFY and SET TALK.