阅读已保存笔记的FILEOBJECT

Question

我参与使用C API与Lotus Notes和Lotus Domino交互。从NSF读取现有Notes时，我遇到了问题。具体来说，读取TYPE_OBJECT字段，更具体地说，读取$ FILE字段（虽然我确定如果我还有其他字段，所有TYPE_OBJECT字段都会失败）。

我正在使用NSFItemInfo来获取$ FILE字段的摘要数据（所以我不需要保存的文件，我需要有关它的信息，例如它的大小，名称等等。）

如果我在内存中创建Note，请提交，然后阅读$ FILE字段，一切正常。如果我将单元测试更改为读取现有注释（而不是在内存中创建它），则Lotus PANICS会显示无效句柄查找消息。

所以当我从头开始创建一个注释已经创建了一个注释时，我感到有一些关于加载这些字段的不同之处。即使在已经创建的Note中读取我自己创建的代码也会给出同样的错误，所以我认为我正在正确创建Notes。

我已经探索了NSFNoteOpenExt的标志选项，并试图用OPEN_xxx中描述的每个可能的标志打开Note，除非我用OPEN_ABSTRACT或OPEN_NOOBJECTS打开Note，否则我总是会感到恐慌。那些没有错误的原因是因为它们打开了没有$ FILE字段的Note，所以当我看到该字段是否存在时，我得到一个假，并且从不执​​行在TYPE_OBJECT字段中读取的代码。

我缺少什么想法？

我提供代码，但我实际上是使用.NET互操作来完成所有这些，代码分布在多个文件等等....如果您有任何问题请询问我将提供尽我所能。

• 克雷格

Answer 1

我想出了这个问题。它来自这样一个事实：当在C＃中使用interop时，你无法调用C宏。 OSLockBlock被定义为函数的另一个宏的宏。实质上，它锁定BlockId.Pool指针，然后将指针递增BlockId.BlockHandle。我错误地将宏逻辑解释为BlockId.Pool的第一个增量BlockId.BlockHandle，然后锁定。

本质：

Lock(BlockId.Pool)+BlockId.BlockHandle Vs Lock(BlockId.Pool+BlockId.BlockHandle)

有趣的是，后者在创建带有新附件的新笔记时会起作用。我终于想到了这一点，BlockId.BlockHandle在这样做时总是为零。这就是为什么一直有效。