This topic is currently a bit messy (sorry about that). If you know anything about Variable Scope
, and if you have talent for improving technical documents, please consider editing
the topic to organize or otherwise improve it.
Each Variable or Constant has a specific "scope" (or range) in which it is valid.
This range is different for Public And Private Variables, LocalVariables, CompileTimeConstants, and more.
"While we all know about Public, Private and Local variables, what about runtime variables? How about design-time and compile-time variables? These are extremely useful."
Compile-time constants are set at compile time, in a header file. Say you want two different versions of your app, one for each of two different companies. You need two application titles. You could go in and change the properties each time, but better yet, set it in the header file with
#DEFINE SPLASH COMPANY1SPLASH.JPG
Or, how about you want a debug version which has a developer-friendly On Error statement, and a production version. You can set
#DEFINE DEBUGMODE .T. In code you can then use:
* Do something
A note from Christof Lange on asserts: Never, never, never use VFP keywords for #DEFINE statements unless you want to replace a native VFP function with a user defined function for some reason. -- Christof Wollenhaupt
A tip from Dave Noal: Use
#DEFINE SUSP *** To eliminate suspend statements you might have left in your code.-- Dave Noal
SCOPING A VARIABLE TO STARTUP.
How would you like to have a variable set at startup? Itís pretty useful. Say you want a procedure to run at startup depending upon a certain condition. Just put a file in a known location and have your startup routine check for it. For example, if you want your application to automatically update itself on startup, have it check for the existence of UPDATE.TXT. If it is there, have the update code run; if not, let it start up as usual. Any variable you want can be set through the use of a startup variable.
APPLICATION SCOPING: The well-known configuration file is a use of application scope. The information in the CONFIG.FPW file is read at startup and sets up the environment as needed for that specific application. Application scope is when your app is being run by your user.
DESIGN-TIME VARIBLES: You can decrease your development time by the use of design-time variables. In this case, it is done through a config file that VFP uses on startup. I have a VFP icon for each application that I am working on. The config file sets the path that I want, sets the title in the bar to something sensible and opens the project for me. One click is all it takes to open up the project that I want to work on.
Set your icon up like this:
"G:\Microsoft Visual Studio\Vfp98\VFP6.EXE" "-TCG:\COMMON\ProjConf\FW_config.fpw"
(all in the target line of your icon under properties)
The -T switch suppressed the VFP splash screen, the -C switch gives the path to the config file which in this case is on my G: drive.
Switches themselves are a good example of setting startup variables. They are very useful.
Here is an example of misscoping and the consequences.
This line was in a config file:
Set path to = C:\AGENCY;C:\Agency\DATA\; c:\agency\Forms;c:\agency\libs;c:\agency\menus;
The c:\agency is what is wrongly scoped here. The DEFAULT should be c:\agency and the PATH should be all the directories under it. With it wrongly scoped, it is not possible to put the project in a different directory without re-writing the whole set path. With it scoped properly, you would just have to set the default and it would run just fine. Add up a multitude of such errors, and it becomes very difficult to figure out why a program is misbehaving.
This I used to do, except that some installations have users that run applications by clicking the exe in Windows Explorer. To accommodate them, reduce your config.fpw to hold the barest essentials and compile it into the exe. If the path is user-configurable, exclude the path. Have a command=setup.prg. In setup.prg either set your path or call another program to set the path. Repeat this for all other settings the user may need to change. That process should work for most installations. -- Mike Yearwood
Contributors: Gregory Gum, Mike Yearwood, Pamela Thalacker
Category Principles And Guidelines
( Topic last updated: 2010.02.22 01:29:13 PM )