Mon 20 Jan 2020
Branching out: REST, gRPC, and other gory details you can (mostly) ignore
Thu 16 Jan 2020
Branching out: A few terms
Wed 15 Jan 2020
The tree you are busy hugging has new branches
Esoteric C API quirk bit me today
Fri 27 May 2005, 03:39 PMTweet
by Ben Langhinrichs
I definitely thought I was going crazy today, as a small bug with the CoexEdit client component didn't seem to make sense. I had a bit of code that said:
num_entries = NSFItemGetTextListEntries(hNote, COEXEDIT_FIELDNAMES);
if (num_entries == 0)
num_entries = 1;
default_field = TRUE;
strcpy (fieldname, "Body");
text_len = 4;
This code is supposed to check how many fields are being used by CoexEdit, and if none are specified, to default to "Body". The problem was, the field did contain a fieldname, but num_entries was coming back as 0, but only in one of the many places it was called, which was when the document was replicated from the server to a local database.
I guess I have been doing too much LotusScript, because it took me a lot of looking to find out what was wrong. If the field is a text field, not a text list field, this function will return zero, but since documents in Notes are almost always opened with the special flag that makes all field values lists, it worked in the HTTP process, the SERVER process, and everywhere else in the NOTES process. It was only the replicator that doesn't open documents that way that came back to bite me.
So, for what it is worth, if you are doing C API development and need to check the value of a field that you think of as a text list, be sure to check, especially if you don't know how the document was opened.
As an aside, the client component is optional in CoexEdit, so while this will go out as part of a patch to the currenrt evaluators, it is not going to effect most evaluators very much.
Copyright © 2005 Genii Software Ltd.
What has been said: