Newline value in Extended MAPI versus Outlook Object Model

[Jim]

Hello,

I am developing Extended MAPI wrapper code so I can read PR_BODY and
avoid the Outlook security warning that occurs with newer Outlook
versions when reading objMailItem.Body. (When I have everything
working, I will update my previous post on this subject.)

My application code (Outlook Add-In, VB6) parses the body text, and I
am seeing a difference in the body text when I read it via Extended
MAPI instead of via the Outlook Object Model.

When I read the body text of a message via objMailItem.Body (Outlook
Object Model), I get 0x0D/0x0A for newline, but when I read the same
message via Extended MAPI, I get 0x0A only (not 0x0D/0x0A).

This throws off my parsing logic, which makes some application
specific assumptions about body text length and the newline
characters.

It is simple enough to use Replace() to convert vbLf (0x0A) to
vbNewLine (0x0D/0x0A) after reading the body text via Extended MAPI,
so I can use my existing parsing logic unmodified, but I am concerned
that this may not be consistent across all MAPI environments. I can
add some safety by doing the conversion only if the body text includes
0x0A and does *not* include 0x0D/0x0A, but if that is not necessary, I
would like to avoid the processing overhead.

Are there hard and fast rules for how newlines are stored in MAPI now
and for all time?

Thanks.

Jim

 

[Dmitry Streblechenko \(MVP\)]

Are you using a POP3 account to download messages to Outlook? Most likely
your POP3 server returns 0xA only.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool