Late Binding COM objects with C++Builder

问题:

We're interfacing to some 3rd party COM objects from a C++Builder 2010 application.

Currently we import the type library and generate component wrappers, and then are able to make method calls and access properties in a fairly natural way.

object->myProperty = 42;
object->doSomething(666);

However, we've been bitten by changes to the COM object's interface (which is still being extended and developed) causing our own app to fail because some method GUIDs seem to get invalidated - even if the only change to the interface has been the addition of a new method).

Late Binding has been suggested as a way of addressing this. I think this requires our code to be changed rather like this:

object.OlePropertySet("myProperty", 42);
object.OlePrcedure("doSomething", 666);

Obviously this is painful to read and write, so we'd have to write wrapper classes instead.

Is there any way of getting late binding wrappers generated automatically when we import the type library? And, if so, are they smart enough to only do the textual binding once when the object is created, rather than on every single method call?

回答1:

When you import a TypeLibrary for a COM object that supports late-binding (when it implements the IDispatch interface), the importer can generate separate wrapper classes (not components) for both static-binding and late-binding.

Adding a new method to an existing interface should not invalidate your code. Methods do not have GUIDs. However, for an IDispatch-based interface, its methods do have DISPID values associated with them, and those DISPID values can be changed from one release to another. Though any respectable COM developer should never do that once an interface definition has been locked in.

回答2:

After deep investigation of the code and headers generated by the TLIBIMP, this turns out to be fairly easy.

If your Type Library has a class Foo, then after importing the type library, you would typically use the auto-generated smart pointer classes IFooPtr.

{
  IFooPtr f;
  ...
  f->myMethod(1,2);
}

You should note that at this point that the bindings are static - that is, they depend not just on the GUIDs of the objects and the DISPIDs of the methods, but on the exact layout of the VTable in the DLL. Any changes that affect the vtable - for instance, adding an additional method to a base class of Foo will cause the method call to fail.

To use dynamic bindings, you can use the IFooDisp classes instead of IFooPtr. Again, these are smart wrappers, handling object lifetimes automatically. Note that with these classes you should use the . operator to access methods, not the indirection -> operator. Using the indirection operator will call the method, but via a static binding.

{
  IFooDisp f;
  ...
  f.myMethod(1,2);
}

By using these IDispatch-based wrappers, methods will be dispatched by their DISPIDs, even if the objects vtable layout is changed. I think these classes also give a way to dispatch by function name rather than DISPID, but haven't confirmed the details of that.