>>If you Assign a reference to an object into a property_Assign that does not make the assign,
VFP creates the references to the property before entering in the assign,
and when the object comes destroyed it recalls the property in order to assign a NULL value to it.


Fabio,
That is why I asked if I were missing something. I thought you were saying that the member reference was being assigned. Sorry I miss understood you.

Consider this code if the assignment IS made in the reference members assign method.

X.AllCallMe = m.Y1
X.AllCallMe = m.Y2
X.AllCallMe = m.Y3 

It appear that the internal VFP code is calling AllCallMe_assign to set the member reference to null before the second assignment is made. This behavior seems to be logical with one exception if the assignment isn't made. (Which is what you are saying.) I mean y1 isn't being destroyed but the reference to the object is being resigned to another object. It looks like VFP is trying to do the right thing, it just gets a little confused if the assignment isn't made.

The interesting thing I find here is that there is in implicit call to a reference members _assign method when the object it is referencing is being destroyed. If someone were make other member assignments in the object member _assign method, this could be a bad thing that people should look out for. (Actually I'd personally call that bad design if someone were to do that)

No one ever said that working with objects, even in VFP, was easy. Some people believe you should use assign method with objects, although I don't agree with this, I do respect their opinion. I believe assign method with objects is perfectly OK However there are some bug to look out for. That all goes back to knowing the behavior of the tool you're working with. This is some interesting stuff. Thanks Fabio