VFP Tutorial - Variables

FoxPro is very flexible in its use of variables. It does not insist that a variable be declared before it is used and it does not place any restrictions on the data type stored in a variable. You can create a variable by simply assigning a value to it and you can replace that value with any other data type at any time. This snippet of code would be totally legal:

It would create a variable named "Customer" with Private scope, store a string into it, replace that string with an instance of Excel and then replace that with the Boolean value true. It is however good practice to declare a variable at the head of a program and maintenance becomes very difficult if you change the data type like this.

Scope of variables

Visual FoxPro has three levels of scope for variables. These are declared by the Local, Private or Public keywords. Variables can be declared anywhere in code before the point where they are first used but the best place to declare them all is at the start of the program or module.

Public variables

A public variable is available to all code in the program. Any statement anywhere is able to modify its value so a bug involving a public variable can be very difficult to track down. Having said that, a few carefully chosen public variables can simplify a program design. If you declare the user's ID as public:

then you can create the value at login and be able to use that value everywhere else in the program. That's a useful facility as long as the value of the variable is only ever set in one place.

Public variables can cause problems with debugging because they persist in the development environment after the program has finished executing. It is not unknown for a program to run successfully on the developer's PC and to fail on a user's PC because it relied on the continuing existence of a public variable left over in the development environment from previous run of the program.

Private variables

Private variables are something of a hangover from early versions of FoxPro where they were the only alternative to a public variable. A private variable is available in the program where it is declared and in all programs which are called from that program. The scope of the variable is limited to some extent so it is slightly safer than a public variable. This was the only alternative available in versions 1 and 2 of FoxPro but is rarely used in Visual FoxPro. The main use is when you want to display a value from memory in a report, the private variable will persist from the code that calls the report into the fields of the report.

If the customer's name is declared as:

then all the routines called from this program would have access to that variable. Some developers would take advantage of this availability to avoid having to pass the value across as a parameter.

If a variable is not declared before it is used then it is created with a default private scope.

Local variables

Local variables were introduced with the launch of Visual FoxPro 3. As their name suggests, a local variable is only available in the program in which it is declared. If you declare a variable such as:

then you know that nothing outside of that program can read or change the value of lnCount. Debugging becomes much easier and for this reason, most variables used within a program will be declared as local.

Variable names

Variable names can consist of any combination of letters, numbers and underscores and are not case-sensitive. The name must start with a letter or underscore.

Names can be up to 128 characters long in Visual FoxPro. Be careful when working with version 2.6 or anything earlier because long names were allowed but only the first ten characters of the name were significant. If you had variables named lnTimeForPainting and lnTimeForPreparation then FoxPro would treat them both as the same variable with the ten-letter name lnTimeForP. The program will run without error and give answers that are nearly, but not quite, correct.

Duplicate names

You have to be very careful when writing FoxPro programs. You might declare a local variable named lnPrice but if you make a typing mistake later on and store a value into a variable named lnPrce then FoxPro will leave your original lnPrice unchanged and will create a new private variable named lnPrce to hold the value. One again, the program will run without error and will give results that are nearly right.

Naming convention

Microsoft have supported a simple naming convention for FoxPro variables. Each name has a two-character prefix. The first letter of the prefix describes the scope of the variable, the second letter describes the variable type:

Note that these conventions are purely for the convenience of the programmer. FoxPro does not analyse the prefix. The program will compile and run successfully even if you give a misleading name such as ldBirthday to a public variable holding the user's logon name.

Variables with an m. prefix

It is permissible to have a variable with the same name as a field in the current table. If this conflict occurs then FoxPro will always take the value from the field. Use the m. prefix if you need to refer to the memory variable.

This prefix was very common in FoxPro 2.6 and earlier because the Scatter and Gather commands were used to copy values between fields and variables of the same name. These versions of FoxPro lacked buffered data entry so the technique was to scatter the values from fields to variables, allow the user to alter the value of the variables and then gather values from variables to fields if the record could be locked.

Introduction | Environment | Project | Tables | Forms | Navigation | Executable