>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?

If the COM is being used by 2 (or more) different projects and you have to do a modification in the COM, you only have one file to distribute instead of rebuilding 2 (or more) projects and redistributing them.

But if these points doesn't apply and you want the fastest thing, I agree that using it as a VCX make sense.