9

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

  • 在 Delphi 和/或 COM 方面有经验的人,你有什么办法可以使用有缺陷的 TLB 界面吗?一些错误是:编辑大型 TLB 期间 IDE 崩溃、方法 ID 丢失、TLB 损坏等。在这里,我们还没有找到任何好的解决方案。实际上,我们尝试升级新的 2007 版本。但是新的 IDE TLB 接口与我们之前发现的 bug 相同。

  • 您如何控制 TLB 版本?TLB 文件是二进制格式,解决冲突非常困难。我们尝试将接口描述导出到 IDL 并提交到 CVS,但我们没有找到任何使用 Delphi 从 IDL 生成 TLB 的好方法。另外,微软提供的 MIDL 工具没有正确解析我们从 delphi 导出的 IDL 文件。

4

5 回答 5

10

我认为你应该好好看看 Delphi 2009。

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

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

于 2008-08-20T09:16:37.427 回答
8

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

然而,既然 Delphi 2009 使用了 midl 语法的安全子集,并且在盒子中包含了该 midl 的编译器并集成到 IDE 中,这些问题应该已经成为过去。

于 2008-09-01T21:36:52.857 回答
5

我们还刚刚安装了 Delphi 2009,它似乎确实改进了对 Typelibraries 的支持。然而,我使用 COM 和类型库已经有一段时间了,这里是我多年来发现的一般问题。我同意它的错误,并且一直到 Delphi 2006(我们使用 2009 之前的版本)。

  • 在打开之前始终让每个文件都可写。这听起来很明显,但是在使用源代码控制时,有时我们会忘记这样做,并在打开文件后尝试删除只读标志 - Delphi 无法处理这个问题。在打开之前确保 tlb 是可写的。
  • 如果编辑一个独立的类型库,你必须打开一个项目。出于某种原因,如果您自己打开一个类型库,它将不会保存。创建一个空白项目,然后打开您的类型库。出于某种原因,这允许保存类型库。
  • 如果您的类型库被应用程序或 COM+ 使用,请确保在打开类型库之前关闭应用程序或禁用 COM+。任何打开的应用程序都会阻止保存类型库。

但是我认为您最好的解决方案可能是升级。您也可以获得 Unicode 支持。

于 2008-09-13T07:26:29.070 回答
3

使用 Delphi 2009 大大减轻了巨大 TLB 文件的痛苦,并且我们现有对象的转换很轻松,但我们的 com 对象不使用任何第三方库。

一旦库供应商发布支持的版本,我们将迁移我们的 gui 应用程序。

于 2008-09-18T21:38:07.683 回答
2

与此处的 TLB 接口相同的体验:我们只是停止使用它。

我们为我们框架的不同部分使用几个单独的 IDL 文件(手动构建),利用 #include 构造将它们包含到实际应用程序的 IDL 中,然后使用 MIDL 和 tlibimp 生成单个 tlb。如果应用程序没有自己的 IDL,则可以使用不同框架 TLB 文件的预编译版本。

每当框架进入新版本时,都会运行脚本以在 IDL 文件中的所有必要接口上重新生成 GUIDS。

多年来,这一直为我们提供了良好的服务,对于我们来说,要迁移新的 Delphi 2009 IDL/TLB 工具集不仅必须集成到 IDE 中,而且还必须在自动化构建等方面具有通用性。迫不及待地想通过一些实验弄脏我的手!

于 2008-09-18T20:54:33.967 回答