CodeStore.net comments on "Why Might Notes Consider a MIME Field To Be Rich Text?"

Reply from Jake Howlett

Jake Howlett — Thu, 05 Apr 2012 13:49:17 -0500

Yes, that should work.

Reply from Pierre

Pierre — Thu, 05 Apr 2012 11:54:28 -0500

Do you mean the following will always work when first I call: session.setConvertMIME(false);

Item item = document.getFirstItem("Body");

and whatever I want with the item,

then call session.setConvertMIME(true);

Reply from Jake Howlett

Jake Howlett — Wed, 01 Feb 2012 02:50:01 -0600

Interesting. I'd noticed a "null item" issue in some other code I'd written even though I'd used hasItem() before it, then had to add a (null!=item) clause. Put it down to just Notes being Notes. Thanks for explaining the probable cause though!

Reply from Richard Schwartz

Richard Schwartz — Tue, 31 Jan 2012 13:03:09 -0600

Hi Jake. You should check (item != null) before you call getType().

Even if you've got a hasItem call that you're not showing us, there is still an edge case where hasItem returns true but getFirstItem returns null. Your final code has actually worked around this edge case, but it's worth pointing out.

The problem occurs when the Body item in the document is a MIME Part but there is no actual content in it. If you look at it, you will just see MIME headers and separators. If this is the case, and convertMIME = true is in effect, the result is that hasItem sees the item, but getFirstItem forces the conversion to rich text and an optimization kicks in that deletes the item from the in-memory note!

Your fix does get around this problem by forcing convertMIME=false, but IMHO it's still best practice to check for null.

Reply from Dragon Cotterill

Dragon Cotterill — Tue, 31 Jan 2012 09:28:54 -0600

Yes. I'm dealing with this sort of stuff day in, day out. The BES has to handle conversions all the time. More to the point, we have to handle the memory inside the 2gig limit imposed by the memory management of Domino (all hail 64 bit). So there are times when we have to do a juggling act. It's not nice. And there are times when it can all go horribly wrong.

MIME vs RichText is one of my biggest headaches. Throw Notes Native Encryption into the mix and you can start to see why it gets to be a pain in the...

Reply from Ben Langhinrichs

Ben Langhinrichs — Tue, 31 Jan 2012 09:13:04 -0600

It is easiest to understand when you know what Notes is doing under the covers. MIME is converted to rich text when the note is "opened", or loaded into memory. Sometimes the document object is instantiated without having to open the note, since the Java class is a wrapper around the actual backend, but as soon as you want to read any value or get any item, the backend has to load that note. If the ConvertMime is false, it will load the note without the conversion. If it is true, it will convert.

The part that makes it less than obvious is the separate stages of a) getting the document and b) opening it. While it might seem silly, it saves enormous amounts of processing and memory in some situations.

As with Dragon, welcome to my world.

Reply from Jake Howlett

Jake Howlett — Tue, 31 Jan 2012 08:04:12 -0600

Ah. I think your hint might have helped my discover the cause. I was turning off ConvertMIME in the wrong place.

I'll update the above post with the solution in a mo.

Damn you Notes!

Reply from Jake Howlett

Jake Howlett — Tue, 31 Jan 2012 07:48:12 -0600

Hey, Dragon. Long time!

Yeah, what's with convertmime? Do you need to toggle it off/on when reading fields as well as when setting them?

Should the first code block above use it?

Reply from Dragon Cotterill

Dragon Cotterill — Tue, 31 Jan 2012 07:42:12 -0600

Meh. Welcome to my world.

notesSession.ConvertMIME

Reply from Satourne

Satourne — Tue, 31 Jan 2012 07:07:18 -0600

Hi,

For Lotusscript, i think it's .Type like itemType% = notesItem.Type

it's not .GetType() (JAVA)