>>Actually, VFP has a number of Window handles associated with it. As Vlad mentioned the _VFP.hWnd refers to the frame and _SCREEN.hWnd refers to the desktop (the area the command window generally lives in). Similarly the .Top, .Left, etc. properties of these refer to these individual windows.
>>
>>One thing of note, however. As with 6.0, SDI forms are different from other VFP windows. With a non-SDI form the hWnd property refers to both the frame and client area. In an SDI form, it refers to the frame. The client area is a separate window.
>
>Yes. Using SPY++, I have noticed that VFP has "many (levels of) windows"; I needed a recursive VFP "child" window tree navigator in order to find the handle of a given child window in 6.0.

Have you looked at my code in SpyFoxFox? While it retrieves all the existing windows from the Windows Desktop down, it wouldn't take too much to modify to fit your needs.

>The main point, I guess, was that code that worked in VFP6 can break in VFP7. First case I'm aware of; sort of like _CUROBJ and FPW.

Using AddProperty() for the _SCREEN or _VFP might break existing code. In playing around with the beta, I noted that forms designed in 6.0 with a custom hwnd property didn't cause any problems when opened in 7.0. The only problem that I ran into was code that assigned the property (via _WhTohWnd() and _WFindTitl() in Foxtools) generated an error since the property in 7.0 is read-only. Fairly simple to workaroud with a compiler directive, however.

>But performing real-time 3D graphics on a VFP Form or in _SCREEN using a 3rd-party graphics engine isn't typical either :)

I'd say not.< g >