> Now if you use CLASS properties and methods, which
>is the right thing to do, you have to This.Parent.Parent.Parent.Parent.Parent
>to get to them, since you can't use ThisForm because your coding in class.
>And since fox can't pcode this syntax, class programming with containers can quickly bloat the exe

Another variant of this could be a Parent[1], Parent[2] or Parent, Parent2, Parent3 notation, i.e. the object should have referrence to all its ancestors as soon as it initiates, not having to go through the whole family tree to get to the top. Of course, this means having a .ParentCount property.

>>>2) I like the structure class workaround, but for true API interfaces, I
>need callback capability and addressof like VB or C. Even the clunky way we have to just get Hwnd, why not make it a property of the form? There was another suggestion of providing controls that are true windows subclasses, with the Hwnd and everything available. These controls could exist in addition to the standard bitmapped controls for backward compatibility. To help phase out the bitmapping of forms without breaking backward compatibility.
>What do you think?

So actually each visual object would have a virtual window with a real handle, or have a property to make this window real? In that case, they'd be a better player in the Win world, and the ability to be ported to Linux once wouldn't be entirely lost ...