4

我有一个用 Delphi 编写的联系人管理应用程序，它具有我 10 年前开发的“与 Outlook 同步”功能。现在，我要回去添加一些功能并修复一些错误。此同步功能使用 Outlook 对象模型开始，但它有一个称为“使用 MAPI 增强功能”的可选模式，它使用纯 MAPI 来加快查找更改的速度，并允许使用 RTF 而不是同步笔记只是纯文本。

我想知道支持两个并行执行路径是否是个好主意。

如果我使用所有 MAPI，我相信我会避免一些安全提示，并且我会避免防病毒具有阻止我的应用程序连接到 Outlook 的“脚本阻止”功能的情况。但我认为不利的一面是，我的 32 位应用程序无法使用 MAPI 连接到 64 位 Outlook 2010。我想知道 MAPI 的未来。

如果我坚持使用 Outlook 对象模型，我的 32 位应用程序是否能够连接到 Outlook 对象模型（因为它是进程外 COM）？如果是这样，这是保留我的 Outlook 对象模型执行路径的一个令人信服的理由。但如果不是，并且如果我的应用程序需要针对 x64 进行编译，那么为什么不直接使用纯 MAPI？

4

2 回答 2

12

这是正确的，您需要根据 Outlook 位数以 32 位或 64 位编译代码。

至于 MAPI 的未来，它仍然存在并得到 MS 的积极支持。Outlook 2010 仍然是纯 MAPI。

于 2010-05-04T06:23:01.740 回答
0

我通过测试确认： 1. 32位应用程序可以通过COM自动化连接到Outlook 2010 x64。2. 32 位应用程序无法通过纯 MAPI 连接到 Outlook 2010 x64。

所以，看来我最好保留我的 Outlook COM 自动化代码以支持 Outlook 2010 x64，而我的 MAPI 代码只能在 x86 Outlook 上使用。

但我注意到，在 Outlook 2007 中，添加了“PropertyAccessor”对象，它允许您在不借助 MAPI 的情况下读取 MAPI 属性。这可能会给我读/写 RTF Notes 的好处......如果我不能使用 MAPI，这是主要的缺失功能。

于 2010-05-04T17:56:16.643 回答