>Hi Walter,
>
>>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.

OK, then why are there two calls to the same function when only one is necessary? What's going on has nothing to do with reference counts AFAIC and may be a problem with the compiler rather than VFP.

>>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.

Sure, but how many times does one assign a property with an object reference. You can produce the error by writing contrived code, but that's all. The real problem is why does VFP call the assign method twice (the latter with NULL as a parameter)? This, Walter, is fact. Any object, whether it exists or not, does this.

>>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.
>
You've no idea what you're saying here. In the first example, since NULL will never evaluate to true (it evaluates to NULL) it always falls through to the ELSE statement. The same thing applies to the second. If you change either one by adding the NOT operator, you'll see no difference in the results.