Michael,
As per CC I'm afraid I don't know the answer.
From VB journal's it's interesting to see that they claim windowless controls are faster and they again suggest it for building 'leaner, faster ActiveX controls' (Plamen showed us being windowless should be the reason to be slow and I believe him, journals are wrong. He also showed us for an object being a 'real' object it should have a window:)
It's purely VFP that's responsible from ill behaved behaviours of ActiveX controls. Activex controls especially if VB build are perfect. Applications like Visual FoxPro, sorry Visual For Paint are misguided being OO and it's the main reason. A windowless control wouldn't need to call API for its properties while others should do, and an extra API calling should make the real objects faster :) We VFPers should be crazy trying to select lightest control for things like storage. Ppl should be crazy designing windowless controls for internet :) VFP team is crazy adding a paint event for activex simple frame controls vice versa.
We should all be using VB and throw VFP,C++,C#,J etc to trash.
Cetin

>I don't know how native controls are drawn ( or treated ) in VB , but what you've said does not necessarily means the slowness. Conversely direct drawing by container could be faster than dealing with the object method DrawItself.
>And from language point of view container elements are objects , which can be subclassed.
>ActiveX ( OCX96) are described as windowless controls with primary use - visual components not requiring an HWND or direct activation . And may be because container is unable to draw them directly plus something else will explain the slowness.
>
>
>
>
>>Try this:
>>On one VFP form put one ActiveX control (TreeView control for instance) and how many of the standart VFP controls, how you like (Grid, TextBox, ComboBox, etc.). Start this form and start Spy++ (Start/Programs/Microsoft Visual Studio 6.0/Tools/Spy++). This tool is primarily designed for working with VC++, but in this case is useful. When you find VFP windows in the Spy++ tree, you'll see, that only really window on this form is TreeView control!!!!
>>That is the reason I call VFP "Visual (For) Paint" - all VFP controls are just drawed!!! They are not really objects!!! That is the reason for slow work of VFP at all and for problems with ActiveX controls (for instance you cannot put (at run-time) VFP control over TreeView!!!).
>>
>>And Microsoft call VFP "Object-oriented application"...
>>(Sorry for strong words).