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).