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 回答