>>Are you sure about this? Though ActiveX controls are COM objects, COM objects are not ActiveX controls unless they have a visual interface. While you can add a VFP created COM object to your available ActiveX controls, you can choose them from the list using their GUID, if you attempt to drop one on a form, you should get an error, because VFP servers don't support the COM interface that allows the controls to be dropped on a form. You can do this with VB though.
>
>>I think the solution to the form control binding problem lies in instanciating the control at run time. It must be done in the form load to make sure it happens before the controls themselves are instanciated. The server must be referenced by a form property instead of ADDOBJECTed to the form, because again, a VFP form is not a valid container for a VFP COM object
>
>You're right Erik, I goofed. I was thinking VCX... :(
>
>>But this discussion makes me uncomfortable. If this class is only being used in VFP why all the trouble to make it work as a COM server? What's the point? Are slower programs better? Why can't you take the same exact class you created a COM server from, and drop it on a form as a VFP object?
>
>What about the future? What if your user want IE as a front end?
>

When you write a IE front end, you can then compile your class as a COM server with no code changes. But that doesn't mean your VFP forms have to use the COM server version, just because it's there. Doing so causes all kinds of pain, and just slows everything down, because all communication has to go through the COM interface.

Erik Moore
Clientelligence