使用 C++Builder 后期绑定 COM 对象
我们正在与来自 C++Builder 2010 应用程序的一些第 3 方 COM 对象进行交互.
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);
但是，COM 对象的接口(仍在扩展和开发中)的更改导致我们自己的应用程序失败，因为某些方法 GUID 似乎变得无效 - 即使对接口的唯一更改已经增加了一种新方法).
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?
推荐答案
当你为支持后期绑定的 COM 对象导入 TypeLibrary 时(当它实现 IDispatch 接口时)，导入器可以为静态绑定和后期绑定生成单独的包装类(不是组件).
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.
向现有接口添加新方法不应使您的代码无效.方法没有 GUID.但是，对于基于 IDispatch 的接口，其方法确实具有与之关联的 DISPID 值，并且这些 DISPID 值可以从一个版本中更改给另一个.尽管一旦接口定义被锁定，任何受人尊敬的 COM 开发人员都不应该这样做.
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.
相关文章