我正在编写一个试图解析Recipients 的函数。起初，我主要是在调试模式下进入代码并查看 VBE Locals 窗口中的变量。我正要得出结论，该Recipient.Resolve()方法是无用的，因为我的Recipient对象和它们各自的对象AddressEntry是在调用方法之后立即设置的Recipients.Add（NameSpace.CreateRecipient如果成功解决，否则<The operation failed.>在 VBE Locals 窗口中将属性设置为错误）。
1）从我的测试来看，Recipients.Add和NameSpace.CreateRecipient方法给出了相同的结果，但它们是否完全相同？
在这里，它说
未解析的条目是尚未具有条目标识符或 PR_ENTRYID (PidTagEntryId) 属性的条目。
问题是，当找到该属性时，该Resolved属性已设置为True，并且Recipient.EntryID+Recipient.AddressEntry.ID也已设置。但后来，我意识到当我Recipient在 Locals 中扩展我的对象时，它们才被解析，因为在这样做之前，Recipient.Name仍然是Name用于搜索的，而不是解析的Recipient.AddressEntry.Name。
2) 这种在 VBE Locals 窗口中扩展变量的正常行为Recipient似乎可以解决它？
查看通讯簿 > 工具 > 选项... > 寻址我也开始了解到，在我的情况下，解决过程目前是这样的：
- 首先，搜索通用地址列表 (GAL) 通讯簿（不一定要完全匹配，但
Name用作方法参数的每个部分都必须在Display Name预期结果中） - 如果未找到（例如，如果
LASTNAME FirstName (Subsidiary Company Name)在条目Display Name类似LASTNAME FirstName (Holding Company Name)或有多个结果时使用（例如同音词或匹配的联系人组）），则解析回退到联系人通讯簿（本地 Outlook 个人通讯簿或 PAB）中的搜索) - 搜索联系人，并且规则似乎相同（例如如果有像
FirstName LASTNAME+这样的重复项LASTNAME FirstName，则解析将失败）
我已经看到了这一切：
3) 我对 MAPI 还不是很流利，所以与我观察到的相比，我无法理解它所描述的过程：它是如何工作的以及如何涉及PR_ANR和PR_AB_SEARCH_PATH属性？
4) 我知道我不应该使用PR_AB_SEARCH_PATH它，因为它是保留给 MAPI 使用的，但它的值是什么样的？它是容器 ID 的排序数组吗？
5) 有没有办法以编程方式更改（在 VBA 或其他语言中）我们在上图中看到的地址簿解析顺序设置？
现在假设我在 GAL 中有 2 个类似的同音词（但在我的联系人中没有）：
LASTNAME FirstName (Holding Company Name) <firstname.lastname@company.com>LASTNAME FirstName (Holding Company Name) <firstname.lastname1@company.com>
6) 如何在不遍历所有条目的情况下获得第二个 Exchange 用户（有很多条目可以做到这一点）？我尝试了几件事，要么得到第一个，要么得到错误的结果）
7) 对于 EX 用户，我无法获得完整的专有名称，因为在我的情况下它太长了，被截断为 128 个字符：在 VBA（没有 CDO 或 RDO）中有没有办法获得完整的 DN？我已经尝试过PR_EMS_AB_OBJ_DIST_NAME了，但它给出的结果与该AddressEntry.Address属性相同