>>When I say 'interface', I don't mean the UI implementation, I mean the programmatic references to it - CLSID, ProgID, properties, methods, and their parameters. If you change any interface element, the CLSID changes, so you don't connect to it the same way. If the CLSID doesn't change and some other aspect does change, and you've used early binding, which resolves method and properyty interfaces at compile time and builds a reference table, rather than politely asking through the IDispatch how to resolve things (slower, but results in greater compatibility and portability), things break if the new control's not quite exactly identical to how it was at compilation.
>
>I guess I meant that as well using the word interface. As far as early and late binding is concerned, I am just dropping a control on a form or adding it in code. I have no idea what binding I'm using and unless I have no choice, I'd rather not think about it. In my opinion this should be transparent, i.e. the most logical option should be automatic. Anyway, what I'm just trying to say is that I have only a faint notion about the differences between early and late binding and now idea how to 'politely ask through IDispatch'. Maybe you can clarify this a bit? I will have another at hte help files as well.
>

This is a poor but nearly accurate description of what really goes on in binding an ActiveX control to your app. ActiveX controls are nothing more than specialized COM interfaces with extra behaviors to link into and extend the Windows event loop for an application. The following generically applies to how COM references are resolved, ActiveX or not:

If you add it in code (ie you use ADD OBJECT or NEW OBJECT and are adding the ActiveX directly by ProgID) then you resolve the reference to the OLE Object at runtime (late binding), and VFP should neatly and niftily go out and ask about how to resolve the object reference at runtime, through a standard, always available interface called IDispatch(). It inquires about the properties and methods through this mechanism, which is a little slower, especially at instantiation time, but in exchange for this performance, you can survive changes to the interface that create a superset behavior, so that the 'old' names still reference the 'same' things. This common IDispatch interface builds up the details of what can be referenced (and survives changes) by linking up a name and how to get to it programmatically in an indirected fashion.

Early binding says "OK, I know I'll kick myself later, but lets pay the piper and resolve the COM interface here when I compile the application." It builds a reference table that points to things in the interface based on the details in they type library at compile time. It does not check this against IDispatch at runtime, it resolved the reference and just says "go here" through the prebuilt interface table. It saves several moderately "expensive" operations in accessing things via COM (and the more complex the COM interface, the more expensive this resolution is) by doing them ahead of time.

Of course, if anything changes, you point at the wrong thing, and all sorts of not nice things, ranging from a quiet burp that pops an error message to a large, loud and noxious fart that clears the dining room table...

But it is quick when it works.

A second issue with recreating a control or COM object is that modifying a control, even without an apparent interface change, may result in versioning protection, where the ProgID (the 'friendly' name of a control) may remain the same, but the CLSID (the special hex string that is a really unique ID for something in Windows, a GUID or UUID that brands it) is very likely to change. Even if the friendly name ProgID stays the same, if the CLSID changes, and your old form reference uses late binding, but relies on the CLSID to find the thing in the system registry, it won't be there, and attempting to instance the control plotzes because it can't find it.

A third problem, sometimes there's ProgID versioning - there's a non-version-specific ProgID, and then each different version of the control has it's own version of the friendly name, with a common, shared version-independent friendly name (a VersionIndependentProgID). An example is the JavaScript ProgId on my machine is VersionIndependent which points to the CLSID most recently registered thing (ProgID) that lets itself be called "JavaScript", there are three version-dependent Javascript ProgIDs - Javascript1.1, JavaScript1.2, and JavaScript1.3, each of which points to a CLSID of its own - which was last registered is the one that currently "owns" the VersionIndependentProgID. I refer to this behavior often as "last man standing wins"

I've never been quite sure about how VFP resolves controls added visually, since it changes from version to version, and some system directives control whether or not VFP will even allow early binding behavior to take place. Since I hurt myself fairly often, I try to programmatically add the control at runtime if I can. Doug Hennig's SFActiveX class, which I started using as a part of SDT, is a major aid in this...