>>Umm, Mike, in what way can you have ActiveX controls not be a COM object? Or is the difference only that what you call ActiveX has a UI grafted on it and the straight COM version just be accessed programmatically without its own UI elements?
>
>Yeah, thats what I mean. In Mike terms, the ActiveX uses an OLEContainer on a form to use the object and the COM uses CreateObject(). If you want to put code in the events of the object, is it possible to use CreateObject, or are you limited to the OLEContainer? Either way, I don't think it will take care of a C5 :-(

Well, since you can use ADDOBJECT()/NEWOBJECT() to add controls or COM things, and you can subclass COM objects, it should not matter, and your COM object surfaces events that can't be hooked directly by VFP's UI, VFPCOM is there to bind VFP code to events...you can CREATEOBJ() an ActiveX Control like say the MSCOMM32 library, or use either the WebBrowser control or InternetExplorer.Application (or a member of the Windows Collection of Shell.Application, which are nothing more than InternetExplorer.Application instances running in the current user context on your machine) they don't seem to make a difference.

All ActiveX Controls are In-Process COM Servers. Not all In-Process COM Servers are ActiveX controls.

You can have a COM object surface events and not respond to them, or you can hook them and respond to them.