Opening a .msg file in OL via shellext vs importing

[Mark J. McGinty]

While experimenting with .msg files, created using
Redemption.SafeMail.SaveAs, and then opened by double-clicking in the file
system, it appeared to me that UserProperties are persisted in the .msg
file. But when I use Import, to get OOM MailItem object access to a saved
..msg, the UserProperties collection is empty.

I'm a little confused as to what is actually taking place, I see I need to
have an existing MailItem assigned to SafeMail.item before I can call
import. Does that over-write the existing MailItem, if I call Save?

If I get a MailItem reference to the email in Outlook from which the .msg
was created, and assign that to SafeMail.item, I can access the
UserProperties, they remain intact, but I was hoping to avoid the need to
locate the original email. (Plus I'm not really sure what is or is not
coming from the .msg this way.)

I'm also struggling with the concept of User-defined fields defined in this
item vs User-defined fields defined in Inbox (in this case.) When I open
the .msg in Outlook, my U-D fields show as being defined in the folder, but
not the item? What's wrong with this picture?


I was already saving as .msg for other reasons, primarily to upload to
another system. The upload process needs a few values stored in the item as
UserProperties What I was hoping was that each .msg file would be
completely self-contained, i.e., hoping I'd be able to read the
UserProperties directly from the .msg files.

I suppose it'd be easy enough to use some other storage, if it's impractical
to do what I had planned... any insight appreciated.


-Mark

 

[Dmitry Streblechenko]

See below

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

While experimenting with .msg files, created using
Redemption.SafeMail.SaveAs, and then opened by double-clicking in the file
system, it appeared to me that UserProperties are persisted in the .msg
file. But when I use Import, to get OOM MailItem object access to a saved
.msg, the UserProperties collection is empty.

Most likely Outlook does not see the changes made by Import() in Redemption
until
you dereference and reopen the message.

I'm a little confused as to what is actually taking place, I see I need to
have an existing MailItem assigned to SafeMail.item before I can call
import. Does that over-write the existing MailItem, if I call Save?

Yes, Import copies all properties from the MSG file and overwrites all the
existing properties.

If I get a MailItem reference to the email in Outlook from which the .msg
was created, and assign that to SafeMail.item, I can access the
UserProperties, they remain intact, but I was hoping to avoid the need to
locate the original email. (Plus I'm not really sure what is or is not
coming from the .msg this way.)

You should be able to use Safe*Item.Fields() to read any user properties,
they are nothing but named MAPI properties:
http://www.dimastr.com/redemption/utils.htm#xmapi

I'm also struggling with the concept of User-defined fields defined in
this item vs User-defined fields defined in Inbox (in this case.) When I
open the .msg in Outlook, my U-D fields show as being defined in the
folder, but not the item? What's wrong with this picture?

Properties that are defined on the folder level, have their definition
stored in a
hidden message in that folder.
User properties stored on a particular item are regular MAPI properties.
Their definitions
are also stored in yet another named MAPI property.

I was already saving as .msg for other reasons, primarily to upload to
another system. The upload process needs a few values stored in the item
as UserProperties What I was hoping was that each .msg file would be
completely self-contained, i.e., hoping I'd be able to read the
UserProperties directly from the .msg files.

If you all yu need is read some properties from an MSG file, you do not
have to bring it back to Outlook - open it directly using
RDOSession.GetMessageFromMsgFile and access custom properties
using RDOMail.Fields().

 

[Mark J. McGinty]

Awesome, that's exactly what I needed -- thanks again!

-Mark