Type(), VarType()

TYPE() returns the data type of the variable or field passed to it. One of the most common errors in coding FoxPro has been to forget the quotes required around the parameter for the TYPE() function. VARTYPE(), introduced in VFP 6, doesn't require quotes, is significantly faster, and provides better reporting of whether the expression is null, but it has its own idiosyncrasies. Since neither function detects code page translation flags, nor can they distinguish the many numeric field types, sometimes AFIELDS() is far more useful.

Usage

cValue = TYPE( cExpression )
cValue = VARTYPE( eExpression [, lIgnoreNull ] )

Parameter	Value	Meaning
cExpression	Character	A string that can be evaluated to a legitimate variable or field name, or a valid expression.
eExpression	Expression	Any expression.
lIgnoreNull	.F. or omitted	Return "X" if eExpression is null.
lIgnoreNull	.T.	Return the underlying object, field or variable type if eExpression is null.
cValue	Single character	The type of the expression returned.

TYPE() and VARTYPE() return identical values except for three cases: VARTYPE() returns "X" if the expression is .NULL. and you haven't specified the optional lIgnoreNull parameter. VARTYPE() does not distinguish Memos from strings, returning "C" for both, where TYPE() returns "M" and "C", respectively. Finally, VARTYPE() does not recognize Screen-type variables.

Passing a variable of type "S" (see "SAVE SCREEN") to VARTYPE() results in error 19, "Data type mismatch." The TYPE() function properly returns "S".

Note that Character fields and memory variables and Character/Binary fields both return "C," not giving you a clue that the field is stored NOCPTRANS. This is because, despite the Table Designer's popup, Character/Binary is not really a field type but the combination of type and the NOCPTRANS property. Adding it to the Designer's popup but not adding it as a new TYPE() is an inconsistency worthy of the term bug. Same deal for Memo fields and Memo/Binary. Bogus.

Returning the TYPE() or VARTYPE() of integer, numeric, double and float fields all as "N" is a bug. While all are treated the same way when used as memory variables, the storage and precision of integers and doubles are significantly different than the other two. A work-around is to use AFIELDS() to determine which field type you're working with, and reserve the use of TYPE() for memory variables.

When you test for an object, you also must test to make sure the object is not null. Many developers use this construct: TYPE("Object") = "O" AND NOT ISNULL(Object). However, you can check the Name property to make sure it's a character type: TYPE("Object.Name") = "C". Because VARTYPE() explicitly passes the expression to test as a parameter, it fails if an expression cannot be evaluated, causing an error 12, "Variable not found"—you'll still want to use TYPE() to check if a variable exists. VARTYPE() is preferred, though, if you know the variable does exist (because your code just declared it or received it as a parameter) and just need to know what type it is. In our informal tests, VARTYPE() was five or six times faster than TYPE() in most situations. Curiously, both functions seem to slow down immensely when you start to test large strings (10,000 characters and up), so you'll want to avoid repetitive testing on multi-megabyte memo fields if you can avoid it.

Example

? TYPE("_VFP.Name")  && Returns "C"
oThing = CREATEOBJECT("Form")  && Create a form object
cName = "oThing"               && Store the variable name
? TYPE("oThing")  && Returns "O"
? TYPE(cName)     && Also returns "O"
? ISNULL(oThing)  && Returns .F.
? VARTYPE(oThing) && Returns "O"
? VARTYPE(cName)  && cName returns "C"
oThing.Release()  && Make it go away
? TYPE("oThing")  && Still "O"
? ISNULL(oThing)  && Now .T.
? VARTYPE(oThing) && Now "X"