All data in Visual FoxPro have a particular data type, which defines the values permitted for the data and the range and size of those values. After you identify and specify the data type you are using, Visual FoxPro can efficiently store and manipulate the data.
When you create a table, you can specify the type of data to be stored in each field of the table. You can specify more data types for fields in a table than for variables and arrays. Variables and arrays can store only a subset of the available Visual FoxPro data types; however. The value you store in a variable or array element determines the type of data in the variable or array element. For more information,
Tip You can use the TYPE( ) function to determine the type of data stored in a variable, array element, or field.
The following table lists the data types in Visual FoxPro.
Visual FoxPro Data Types
| Data type | Description | Size | Range |
|---|---|---|---|
| Character | Alphanumeric text
For example, a customer address
| 1 byte per character to 254 | Any characters |
| Currency | Monetary amounts
For example, the price of an item
| 8 bytes | - $922337203685477.5807 to $922337203685477.5807 |
| Date | Chronological data consisting of month, day, and year
For example, an order date
| 8 bytes | When using strict date formats, {^0001-01-01}, January 1st, 1 A.D to {^9999-12-31}, December 31st, 9999 A.D. |
| DateTime | Chronological data consisting of month, day, year, hours, minutes, and seconds
For example, date and time of arrival
| 8 bytes | When using strict date formats, {^0001-01-01}, January 1st, 1 A.D to {^9999-12-31}, December 31st, 9999 A.D., plus 00:00:00 a.m. to 11:59:59 p.m. |
| Logical | Boolean value of True or False
For example, whether or not an order has been filled
| 1 byte | True (.T.) or False (.F.) |
| Numeric | Integers or decimal numbers
For example, the quantity of items ordered
| 8 bytes in memory; 1 to 20 bytes in table | - .9999999999E+19 to .9999999999E+20 |
| Variant | A variant can contain any of the Visual FoxPro data types and the null value. Once a value is stored to a variant, the variant assumes the data type of the data it contains.
Variants are designated with an eprefix in language syntax.
| See data types above. | See data types above. |
In addition, Visual FoxPro provides data types that apply only to fields in tables.
Variable Scope Declaration in Visual FoxPro
In Visual FoxPro, some confusion results from the fact that PUBLIC , PRIVATE , and LOCAL refer to variablescope, whereas PROTECTED and HIDDEN refer to property and method visibility, and PROTECTED will always be part of a FUNCTION or PROCEDURE declaration in a class definition; no confusion there. But PUBLIC can refer to either a variable or to a property or method of a class.
PUBLIC , PRIVATE , and LOCAL are declarations that precede variables and determine their scope. If a variable is declared in a program, by default it's visible in that routine and in any routine below it. For example, if MAIN contains a line like Name =[Les] and uses DO FORM CUSTOMERS to show a form, within the form you can type THISFORM.Caption = [Les] in the form's LOAD event and the form's caption will appear as "Les". If you move the line Name=[Les] to the CUSTOMERS form and change the Load code to read
Name=[Les] THISFORM.Caption = Name
the form's caption will change, but as soon as the form closes , the variable Name disappears. Technically, it is said to go out of scope .
LOCAL means that a variable exists only within the procedure in which it's named, whereas PRIVATEmeans that it exists in the procedure in which it's created as well as in any procedure called by that procedure.
For example, variables can be scoped before a value is assigned using a PUBLIC , PRIVATE , or LOCALdeclaration:
PUBLIC Address && will be available after exiting this procedure Address = FileToStr ( ClientAddressTextFile ) LOCAL I FOR I = 1 TO 2 && does not conflict with any global instance of I ? "Hi" ENDFOR
Within a program, we declare variables to store values. The declaration of and use of variables in Visual Basic looks confusing to FoxPro developers because it requires an extra step that's optional in FoxPro. And the reason for it is that in Visual Basic, all variables are actually objects.
In FoxPro, you declare a variable by assigning it a value:
X = 3
Similarly, you declare a class property by assigning it a value:
DEFINE CLASS Person AS Custom FirstName = [] LastName = [] ENDDEFINE
FoxPro generally declares all variables as variants, which means you can assign any value to them. In fact, you can change their data type in the middle of the program ”usually inadvertently and with confusing results. It's not a good idea, but it's possible. However, you can declare types using thePUBLIC , PRIVATE , and LOCAL declarations:
LOCAL LastName AS String PUBLIC I AS Integer
You can also declare objects based on classes in your class libraries, or from the FoxPro base classes:
LOCAL oDoc as Word.Document oDoc = CREATEOBJECT ( "Word.Document")
However, all variables declared with the LOCAL , PUBLIC , or PRIVATE declarations have an initial value of.F. , and can be changed to any other data type any time you want. So why bother?
Type declarations in FoxPro are used to permit specification of parameters for creating Dynamic Link Libraries (DLLs), which require a type library (TLB) entry that specifies parameter data types in a universally accepted format. Because FoxPro didn't have anything but variants, type declarations were added to the language to permit building Web services, which must specify their parameters and output types. But internally, they're pretty much ignored except for supporting IntelliSense.
Similarly, classes can have PRIVATE and PUBLIC properties and methods. IntelliSense reveals the public ones, whereas private ones are not visible.
Essentially, PUBLIC variables are accessible any time after being declared, as if they had been initialized in the MAIN program. PRIVATE variables are declared in the procedure in which they are created and in procedures called by the creating procedure. LOCAL variables are available only within the creating procedure, so they're perfect for loop counters. In general, the idea is to avoid inadvertently overwriting a variable. That's the story on variable declarations in FoxPro. Pretty simple, isn't it?