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:
-
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.
-
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.
-
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.
-
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
SET PATH TO
Data
ELSE
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.
|
