>>Well, in this particular case I have a textbox that creates another textbox
>>based on itself on init. I want an easy way for the child to reference the
>>parent's properties and vice versa without using macro expansion.
>>this.objref.Value looks a lot nicer than this.parent.&lcObjName..Value.
>
>I missed the beginning of this thread but for a child to reference a parent,
>the simpliest way will be This.Parent.Property.Value. As for the parent to
>reference the child, I remember that we used the EVALUATE function at
>several times instead of the macro but I don't remember excatly what was the
>syntax.

I think there's a little confusion of terms here. The use of the keyword "Parent" maps back to the container that a given object is in. The use of the word "parent" in the above quoted text is probably closer to the idea of creator, that is, the "parent" has code in its Init() that generates another object (probably a CreateObject() call). This person want to establish a relationship between the two objects, using properties of the two.

What would happen if you put a statement like:

This.oMyChildObject = .NULL.

in the Destroy() event of the "parent" object and

This.oMyParentObject = .NULL.

in the Destroy() event of the "child" object? Those should both fire before the Form is actually destroyed. Or even better, how about:

WITH Thisform.txtOriginal
.oMyChildObject.oMyParentObject = .NULL.
.oMyChildObject = .NULL.
ENDWITH

in the QueryUnload() or Release() methods? That would destroy those references before the real objects ever got destroyed.

By the way, why are you doing this particular textbox creation, anyway? (backpedaling even further...)