I disagree that WPARENT() is different than other OOP Parent references.
I think you missed my example:

Child_Form_1.method()
  do form Child_Form_2
  if type( 'Child_Form_2' ) = 'O'
    Child_Form_2.AddObject('myContainer','Container')
    .....
  endif

In this example, you would expect myContainer.parent to be Child_Form_2 not Child_Form_1, even though Child_Form_1 was the one that created it.
And it is the same way with wParent(). Child_Form_2 will be created inside whatever TL form is active at the moment, so that TL form is it's parent, even though Child_Form_1 created it.

As near as I can see, the only difference between the 2 creations is: when I create Child_Form_2 I don't have to name the 'parent' it gets created in (TL form), but for addobject() I do have to name the 'parent' (Child_Form_2). But that difference occurs during creation. After creation both wParent() and .Parent accomplish the same thing ie: the name of the container it's inside.

Whenever I use any variation of .Parent I'm always looking for the container that it is inside, not what object created it.

But I think you're demonstrating my original point. This is not ambiguous to me, but 'set deleted on' is ambiguous to me and probably not to you. That is not a reason to quit using any command. And definitely not a reason to add overhead to an app in order to avoid the anbiguity.




>>I see your position and don't disagree with it, but I don't agree either. I think of it as a personal choice, but I'm open to other ideas.
>>
>>I agree with most of what you say, but I don't think it applies to EVERY w***() function.
>>
>>Probably 1/2 of all the VFP commands, functions, etc were created long before VFP & OOP & TLs. We don't quit using them because they're old. We quit using them because something better comes along.
>>
>>When I first saw wparent(), it didn't occur to me that it would refer to the physical-launch parent.
>
>Okay, I agree on the general Fox commands being largely of old origin. I think we can all agree on many data commands, especially, being of old origin - but let's refine the debate a little better. First, I'm talkng W***() functions only here. And within *that* subset, let's talk more specifically only about WPARENT, this one function.
>
>You can certainly see why I thought a "parent" would be the launching form, and probably most other developers would as well, if they've been using oop any length of time, and forgotten usage of, or not heard of WPARENT. For this one particular function, WPARENT, it flies directly contrary to the OOP use of "Parent" (hence my first interpretation). After all, what is:
>
>This.Parent? This.Parent.Parent?
>
>Parent is the *next* heirarchical object up the object ladder. WPARENT is NOT the next heirarcichal object up the ladder, except in the trivial 1-child situation. In other cases, it has virtually the direct opposite meaning of an OOP "Parent." I think it's a misleading term, therefore should be avoided above all other W***() terms for this reason, more than say WONTOP() or any other W***() function, all of which may be old, but at least are not directly misleading as WPARENT is. See my point, when put in this light?