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. If I "some_external_object.addproperty( 'whatever' )". I would not expect 'whatever' to treat the object that created it as it's parent. I expect 'some_external_object' to be it's parent, because that's who it's created INSIDE.
When I looked at 'Displaying a Child Form Inside a Top-Level Form' in the help file, it seemed fairly obvious that who creates a form is independant of who it's wparent() is.

After you said what your first thought of wparent() would be, I can understand your reasoning. But just because an old command is ambiguous is not a reason to not use it. When I first
saw it, I assumed that 'set deleted on' would DISPLAY deleted records, but it's just the reverse; it sets the deleted FILTER on. To this day, I still have to look at the help file when things aren't doing what I thought they should in regards to deleted records. I would not object to having MS create another word that is less ambiguous, but I wouldn't want them to remove the function all together (which would be the same as never using it because it's old).

I agree that there are better ways to do things now, but they generally involve more overhead in some way. Usually the extra overhead is useful, but now and then a situation comes along where the extra overhead is overkill (like the situation I'm dealing with now). My app has only 1 active form in it. It calls a 2nd form for a short period, but then returns to the 1st and the 2nd form is never seen again. I can't see creating a tracking array just to handle 1 form. Being able to bring up an "old" way of doing things that saves on overhead is good in my opinion.
As to wparent(). I can't see creating a tracking array and keeping it in the background just to be able to do what wparent() does. Expecially since the only reason I need it is when something unusual has happened (IOW, it may never get used in real time). If there are other things to track at the same time, then I agree. But don't do it just because the wparent() function is an old function.

This whole argument goes out the window if the 'old' call is using some resource external to VFP. The old foxtools library still comes in handy now and then, but it's not being updated with VFP, so I would definitely try to steer away from using it. But that's not the same as the w***() functions that are part of VFP.exe.






>>Why wouldn't w***() be good OOP? It seems to me that some of them are precisely what OOP is all about. But again, maybe I'm missing something.
>>Tell me if I'm doing something that's not good OOP here:
>>my TL form is minimized (windowstate=1) to start and runs other forms completely in the background on user's computer, but if something happens that needs the user's attention I need to un-minimize the TL form (set windowstate=0). Using wparent() in this situation keeps ALL the code to un-minimize the TL form inside the active form.
>
>I think this (our current topic) is a very appropriate example, of why W***() functions are generally "out" for modern oop programming.
>
>1) First, these Fox windows functions were created long before vfp & OOP & TLs, so the results from using them can be questionable at times. Most contemporary vfpers, AFAIK, stay clear of these oldy Windows functions whenever possible - not so much intentionally, but because we have better ways of doing things.
>
>2) Second, these are not oop calls, they were created for non-oop-use long before oop hit vfp. These functions tend to go against good encapsulation and tight, internal commnunications between objects.
>
>3) Third, and this is perhaps much more tangible and a very good example of the pitfalls of oldy non-oop W***() functions: Why does WPARENT give the TL and not the launching Child as a result? Imagine first seeing WPARENT in code. What would your first intepretation of it be? Mine would be to suspect the physical-launch parent, which in this case wold be Child1. My basic reaction, would be that I'd need to test it to find out, exactly like we did. Of course we just found out the results were exactly what you wanted, but it's certainly not clear from the function, or even WPARENT's vfp Help section. You have to test to be sure what it does, like we just did. That's not a good thing, to have such ambiguity, especially now that you don't often see many W***() functions in state-of-the-art vfp apps (I don't see them often in use anymore, anyway).
>
>Good code practice indicates we should not be using "old & ambiguous" calls if we can avoid it. The code should be developed so that there is no uncertainty in what the functions do, what the results will be. In addition, though tracking form-launching through collections, properties, arrays, etc, is the more standard approach, it's also generally much more flexible for additional uses and reasons.
>
>Other UTers ar welcome to step in and list additional reasons, please feel free to do so: whether you are pro or con to W***() functions, and if so, why. The above are just some of the reasonings I use, just off the top of my head, for discarding the W***() fuctions as being outdated, and only will use one out of utter desperation.
>
>>BTW what is "WAG"?
>
>That's a "Wild A** Guess" (which is exactly what mine turned out to be! :-)