Sanjay,

This is basically the same as .NULL. works with all assignments, the memvar does not change type.

n1 = 5
n1 = .null.
? type( "n1" ) && will still yield N

.NULL. has special meaning in the way it's handled in expressions and how it propogates, I've just always found it meaningful to use it to initialize and remove object pointers, like nil in Pascal or NULL in PL/1 and C++. Whether it points to memory location 0000:0000 or anywhere else I don't really care, because we have to use IsNull() to test for it.

My IsObject() udf is exactly like your dual test, seeing if it's an object type first and then making sure it's ! isnull()

>
>Perhaps I am on the wrong track, if you could set me right. When I check for the existence of an object, I normally do something like this;
>
>IF TYPE("oMyObject") = = "O" AND !ISNULL(oMyObject)
> *-- Object exists
>ELSE
> *-- Object does not exist
>ENDIF
>
>This to me means that there will be a condition where oMyObject's type is in fact 'O' , but it is a NULL. And, if we try and access 'oMyObject', VFP will return an error. I assume that there is a distinction between the object type and what's there at the end of the pointer (in C++ parlance it would be something similar to
>*oMyObject, which in the latter case will be NULL). This leads me to believe that the var type is definitely 'O', however, at the end of the reference pointer the memory has been set to NULL (or CHR(0) maybe).
>
>Please comment.