>>? TYPE('lvar') && "N"If no other type is assigned previously, TYPE() will report "L". VARTYPE() always will report "X".
>
>George,
>
>Type reports L on an unitialized null var because all vars default to L unless they are assigned some other data type.
>
>LOCAL var
>?TYPE("var") && reports L
>
>VarType() is fine except for one situation, when you are checking the type of a property of an object. In that case VarType will error out if the object does not exist while Type will report U for undefined.

Yeah, I know. If I could impose, I wrote the following while thinking about this whole subject.

JimB,

Perhaps you could help me out here. I think that I may be too much of a "bithead" when it comes to the concept of .NULL., and I'm hoping that perhaps you might clarify something for me. What I don't understand is why ? (.NULL. = .NULL.) returns .NULL. rather than true or false.

I mention the "bithead" thing for this reason. Whenever we assign a variable a value (for example, lvar = .NULL.) we're reserving memory to hold that value. The system holds it in memory as a series of bytes, but also knows the data type. That's why, if we do: lcname = "JimB" , doing ? lcname returns "JimB" and not 1114466634.

Part of my problem is that I'm applying Boolean algebra to this and, well, "it does not compute." On the one hand, I understand why assigning a variable a value, then assigning it .NULL. causes TYPE() (and VARTYPE() with the optional lNullDataType parameter set to .T.) to return the original assignment type (the type remains in the variable name table). For the life of me, however, I don't understand the logic behind returning .NULL. when the same .NULL. value is compared with itself. Sure the pointer to where the variable is stored is probably 0, or IOW, doesn't point valid address. Regardless, of what's actually stored there, it's the same thing.

Am I being dense here, Jim, and, if so, got any of your wisdom for me?