0

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
Corith Malin
  • 1,505
  • 10
  • 18

1 Answers1

0

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.

Corith Malin
  • 1,505
  • 10
  • 18
  • 1
    Typically, I think it's a bit more common to isolate the C API code into a C DLL, and call that from your C#. That way macros are dealt with by the C compiler. – Richard Schwartz Aug 24 '12 at 20:29
  • I can see the benefit to that if I was also supporting the C API or if there were a lot of macros being used (fortunately there isn't). For this though, the C API is from a third party and for the most part I'm just making calls which give me handles back and forth. Any references on implementing your comment though? I would still like to see an example so perhaps I can better ensure that I do or do not want to go down that path. – Corith Malin Aug 31 '12 at 14:28
  • Unfortunately, no. The only cases where I've done this with the Notes C API are in code that I cannot post, and is a little too large to extract a useful subset. – Richard Schwartz Aug 31 '12 at 16:38
  • nsfanalyzer (source code on openntf) is one example. i used a separate c dll for function/cb function wrappers; linked in to a cpp clr winforms app. – Tim Oct 31 '12 at 20:46