>Alright, now your caution makes sense. I hope you're wrong. I hope that the 2nd child launched from inside the 1st child still shows the TL as wparent(). I'll be testing it soon, I'll let you know.

Hi Bill - Saw your 2nd post, just after I had also found the same result. I even created some additional concurrent-running TLs to try to confuse it, but WPARENT still works fine every time for me. So on this issue, which I understand is your main concern just now - getting things to work right - you're doing fine, Bill. So, just what is the problem,if it works? It's mostly theoretical in response, but see point #3 for a more specific reasoning. Basically, my specific answer is that you are "lucky" that the result is what you want.

>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! :-)