update reading pane content

Add-in Express™ Support Service
That's what is more important than anything else

update reading pane content
 
Mimi Yang




Posts: 120
Joined: 2010-02-01
The add in I have will update the email's content, basically change MailItem.HTMLBody, using style tag to highlight some text.

As emails content changed, when user reply/forward/reply all the email, the change(highlight) will be kept in the new email.

in Outlook 2007, I can remove the changes in the new inspector event (if it is composing an email), the reply email generated by outlook does not see the highlights, which is good. However, if Outlook 2010, the new reply email still see the highlights. -- Which I need to fix.

I tried MailItem.Reply event in 2010, first, Add-in seems not be able to catch the event everytime, and even restore the email content (remove the style in the HTMLBody) and save it, the new reply email still sees the highlight.

Any solution for this?

I am also thinking to only update the reading pane content without change the MailItem.HTMLBody, is there a way to do it?

Thanks a lot.
Posted 01 Apr, 2011 20:23:10 Top
Mimi Yang




Posts: 120
Joined: 2010-02-01
This is emergent, I need to find a solutino this weekend. Thanks again.
Posted 01 Apr, 2011 20:24:54 Top
Eugene Astafiev


Add-in Express team


Posts: 8540
Joined: 2007-07-25
Hi Mimi,

There is no way to update the reading pane without changing properties of the underlying MailItem object in Outlook (the Outlook Object Model doesn't provide any property or method for a such task). Please take a look at the How to process Open, Read, Reply, ReplyAll and Send events for a mail, task, appointment in Outlook sample add-in project which is available in the HOWTO page of our web site. Is the Reply method called everytime?

BTW What version and build number of Add-in Express do you use?
.NET, Extended MAPI, Windows Phone & RT
Posted 04 Apr, 2011 07:32:08 Top
Mimi Yang




Posts: 120
Joined: 2010-02-01
I got most part work. And find a walk around solution.

One more question:
Case 1:
1) select email1 (not open it)
2) change email1 htmlbody, do not call MailItem.Save
3) select email2
4) reselect email1, when reading its htmlbody, the changes are there
5) open email1 in a new inspector, close the inspector, no warning that email content has been changed.

Is the MailItem.Save called somewhere internally?

vs Case 2:
1) double click email1, which will open it in a new inspector
2) in the internal selectionchanged event handler, change email's htmlBody.
3) select email2
4) close email1's insepctor, there will a warning that email1's content changed.

Could you explain a little bit to me the difference?
Posted 04 Apr, 2011 12:33:18 Top
Paul Stickney




Posts: 38
Joined: 2010-02-08
Mimi Yang,

This may answer some questions but not all and leave more questions :-) Please note that I only deal with Outlook 2007 and 2010 (mostly 2010).

The OOM caches MAPI objects, particularly Item objects -- that is, when you get an Item object (MailItem), there is only one COM object for the underlying MAPI entry (MAPI is table-based). This is very important for several reasons:

1) This means that changing a MailItem open in an Inspector will also change the values currently displayed in the Inspector (it is the same item!) which is expected behavior. There is no "save" and yet the item data is correctly propagated. (The "list view" does not monitor OOM item change events, rather, it monitors MAPI table change events -- this explains why changes in the inspector are not immediately reflected but delayed until after a Save which updates MAPI which updates the "list view".)

2) If anyone who has this MAPI Item saves it then the item is saved -- the Save is shared. Because the item is cached it might be opened "later" and then save over the handle which was open "early" (this is the case when editing an item in the "list view" while the inspector is open, for example). (See below for some save triggers).

3) If the Item is not judiciously (and correctly) `ReleaseComObject`'ed then it will stay alive because the .NET COM bridge only guarantees RCW (COM wrapper) cleanup when their finalizers is run which is non-deterministic. Because of this it is very important to release MAPI objects -- especially items -- obtained directly from COM (but not release RCW objects obtained from ADX objects). If the item is never closed the values cached in it will never be re-read from the MAPI store. (But the "list view" is special because it directly deals with the MAPI table notifications -- it reads properties directly from MAPI but saves through the corresponding OOM Item!)

Now, here are the cases I know of when an item is saved in Outlook:

1) The item is modified in the Inspector and Saved (manually or when the Inspector is closed, if closing the Inspector manually I believe this can be specified...?). The inspector won't automatically save the Item until it is Saved by the user (or auto-save).

2) The item is modified in the "list view". In this case the Save occurs when the item is "unselected" /or/ immediately when a user action such as "categorize" is performed -- in the immediate action case the OOM Item is opened, modified, and saved in one step (no selection of another item is required)! A save does not occur when the view focus is lost, e.g. editing the item in the "list view" and then selecting an open inspector without first selecting another item does not cause the item to be Saved (unless an immediate action was performed).

3) Other user-actions or background tasks such as SharePoint synchronization which modified the item.

In the above example "selecting email2" may be enough to trigger this event. One way to find out would be with MFCMAPI or OutlookSpy and observe the modifications / last-modification-time. In the case posted I suspect the problem is not correctly releasing the item. In my experience this is the normal cause for the "Item have been modified" errors. (However, this error is also easy to reproduce with the SharePoint synchronization service and how it handles conflict items -- I believe this is because the synchronization service happens below the OOM Item level.)

Happy coding,
Paul
Posted 04 Apr, 2011 23:33:45 Top
Eugene Astafiev


Add-in Express team


Posts: 8540
Joined: 2007-07-25
Hi Mimi,

It looks like in the second case a reference to mail item is held in your add-in project. Anyway, please make sure that you release underlying COM objects properly. You can read more about it in the When to release COM objects in Office add-ins developed in .NET article on our technical blog.

Thank you for sharing your knowledge, Paul.
.NET, Extended MAPI, Windows Phone & RT
Posted 05 Apr, 2011 05:28:49 Top
Mimi Yang




Posts: 120
Joined: 2010-02-01
Thanks Paul, that's really help.
Posted 08 Apr, 2011 23:42:02 Top