Hi George,

>First, you're right, there is a bug here. My apologies, if you've taken what I've said as anything other than a difference of opinion.

>Second, what's happening is a call stack problem and will happen anytime a property with an _assign event is assigned an object reference three times. IOW, it doesn't have to be a reference to an existing object. The same thing will happen if you use CREATEOBJECT() or NEWOBJECT() to create, for example, a label.

It is not a call stack problem. It is a refcount problem.

>Is it serious? I don't know. How often would one repeatedly assign a object to a property? I've never done it.

It is a bug, potientially providing a C5. Can it be circumvented ? Yes, but this does not mean it is not serious. People can spend days to try to determine that a specific problem was caused by a bug. Since this BUG is destructive (Rather than a visual glitch or a slighty wrong output) I would call it one that really needs to be fixed.

>Finally, I do understand null and its implementation in VFP. Furthermore, I do understand and agree with the logic that implemented. In short, null is unknown and therefore cannot be evaluated. If it can't be evaluated it cannot be equal to anything else, including itself. By returning NULL in a statement like ? X = NULL, VFP indicates this.

Well, interestingly in various cases an expression resulting in a .NULL. Value is evaluated to false:

IF .NULL.
ELSE
ENDIF

IIF(.NULL.,.T.,.F.)

Etc.

Walter,