Delphi和COM:TLB和维护问题

在我工作的公司中,我们使用C#开发所有GUI,但应用程序内核主要是在Delphi 5中开发的(由于历史原因),在COM +中使用了很多组件.与这个非常具体的应用相关,我有两个问题:

Delphi和/或COM中经验丰富的人,您是否有任何工作场所可以使用错误的TLB接口？一些错误是:IDE在大型TLB的编辑过程中崩溃,丢失方法ID,TLB损坏等.在这里,我们还没有找到任何好的解决方案.实际上我们尝试升级做新的2007版本.但是新的IDE TLB接口具有我们之前发现的相同错误.

你如何控制TLB版本？TLB文件采用二进制格式,冲突解决方案很难做到.我们尝试将接口描述导出到IDL并提交到CVS,但我们没有找到任何使用Delphi从IDL生成TLB的好方法.另外,Microsoft提供的MIDL工具没有正确解析我们从delphi导出的IDL文件.

Roddy.. 10

我想你应该好好看看Delphi 2009.

Delphi 2009对COM支持进行了更改,包括基于文本的二进制TLB文件替换.

您可以在Chris Bensen的博客上阅读更多内容.

我想你应该好好看看Delphi 2009.

Delphi 2009对COM支持进行了更改,包括基于文本的二进制TLB文件替换.

您可以在Chris Bensen的博客上阅读更多内容.

在遥远的过去(在我开始为CodeGear工作之前),我放弃了IDE提出的奇怪的Delphi化IDL语言,并编写了我自己的IDL并使用MS midl编译它.这很有用; 唯一的问题,IIRC,确保dispids(id属性)在属性getter和setter的自动化接口(dispinterfaces)上是正确的 - 有一些tlibimp预期的不变量,但是midl不能保证.

但是,既然Delphi 2009使用了一个安全的midl语法子集,并且在盒子中包含了这个midl的编译器并集成到IDE中,那么这些问题应该已成为过去.

我们刚刚安装了Delphi 2009,它似乎确实改进了对Typelibraries的支持.然而,我已经与COM和类型库合作了很长一段时间,这是我多年来发现的一般陷阱.我同意它非常漂亮,并且一直到Delphi 2006(我们使用2009之前的版本).

在打开之前始终将每个文件都可写.这可能听起来很明显,但是当使用源代码控制时,我们有时会忘记这样做并尝试在打开文件后删除readonly标志 - Delphi无法解决这个问题.打开前确保tlb是可写的.

如果要编辑独立的类型库,则必须打开一个项目.出于某种原因,如果您自己打开一个类型库,它将无法保存.创建一个空白项目,然后打开您的类型库.由于某种原因,这允许保存类型库.

如果您的类型库由应用程序使用,或者COM +确保在打开类型库之前关闭应用程序或禁用COM +.任何打开的应用程序都将阻止保存类型库.

不过,我认为您最好的解决方案可能是升级.您也获得了Unicode支持.