Question

I am involved in using the C API to interact with Lotus Notes and Lotus Domino. I’m running into issues when reading existing Notes out of an NSF. Specifically, reading TYPE_OBJECT fields and even more specifically, $FILE fields (though I’m sure all TYPE_OBJECT fields would fail if I had any others).

I’m using NSFItemInfo to get the summary data on the $FILE field (so I don’t need the saved file, I need information about it such as its size, name, etc…).

If I create the Note in memory, Commit it, then read the $FILE field, everything works. If I change my unit test to read an existing Note (instead of creating it in memory), Lotus PANICS with an Invalid Handle Lookup message.

So I’m left feeling like there is something different about loading those fields when I create a Note from scratch Vs opening one already created. Even reading in an already created Note that my own code created gives me the same error, so I think I’m creating the Notes correctly.

I’ve explored the NSFNoteOpenExt’s flags options and have attempted to open the Note with every possible flag described in OPEN_xxx and I always get the panics except when I open the Note with OPEN_ABSTRACT or OPEN_NOOBJECTS. The reason those don’t error though, is because they open the Note without the $FILE fields at all, so when I see if the field exists I get a false and the code to read in TYPE_OBJECT fields is never executed.

Any ideas what I’m missing?

I’d provide code, but I’m actually using .NET interop to accomplish all this, and the code is spread across multiple files, etc…. If you have any questions please ask and I’ll provide as much detail as I can.

• Craig

Answer 1

I figured out the issue. It came from the fact that when using interop in C#, you can’t call C macros. OSLockBlock is defined as a macro to another macro to a function. Essentially, it locks the BlockId.Pool pointer, then increments the pointer by BlockId.BlockHandle. I was mis-interpreting that macro logic to be first increment BlockId.Pool by BlockId.BlockHandle, then lock.

Essentially:

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

It’s interesting that the latter would work when creating a new note with new attachments. I finally figured that out as well, BlockId.BlockHandle was always zero when doing that. So that’s why that always worked.