>Hi Rick,
>
>Looks like you and I have had very different experiences with ActiveX and VFP. I've always been surprised at how easy it was to write an ActiveX control and use it in VFP. I use ActiveX controls written in C++ in my apps and have never experienced any problems with them, and so far they have all been visual controls.

Well, I'm talking about stock and common 3rd party controls. I have several apps that run mainly ActiveX controls for the UI and every single one of them has serious quirks including the Web Browser Control, Tree and Listviews, Statusbar, Activebar Menus, Listbar and a few others. There are timing issues, drawing and resizing issues and for a number of third party controls functionality issues that just won't work right in VFP.

I can and have worked around it, but it's a nightmare and very time consuming.

>
>I'm not sure why you say that a VFP form is not a standard windows form? It appears from what I can see to be just that. The controls drawn on it are not standard windows controls, but the form itself seems to be a standard Window that has been subclassed. When I add an ActiveX control to the form it also gets a standard windows handle and is what appears to be a standard windows object.

Fox controls are not windowed controls - they are owner drawn controls, which means you can't easily override their behavior. The ActiveX container in VFP especially is a problem for this as it's difficult to get handles to the container and contained controls (you basically have to walk the window handles yourself which is available only with VFP 9 recently).