SGriffin's MAPI Internals

1. None of the  MailItem.Attachment* and MailItem.BeforeAttachment* events point ot a file path when an attachment is being added.

2. Selecton collection still feels slower in OOM, even if it was significantly improved and no longer runs out of ROC channels trying to open all selected messages when ones touches any Selection property.

3. Namespace.PickFolder is no match for IExchExtCallback::ChooseFolder()

4. MailItem only exposes BeforeCheckNames, while ECE has IExchExtMessageEvents::OnCheckNames / OnCheckNamesComplete

5. ECE allows to abort submit and leave the message open, abort submit and close the editor, or let the message go through. OOM only allows 2 out of 3.

Stephen Griffin is asking this question over on his blog . If you're using Exchange Client Extensions

My code depends on ECE's functionality of OnSubmit returning S_FALSE ( to let Outlook submit item ), S_OK ( Submit is processed by the client- do not touch ), E_FAIL - the Inspector comes back up...

This is critical for the clients because the processed-by-me message should not go to Exchange.  If I were to use COM AddIn, it gives me only 2 options ( S_OK - passes to Exchange ) or E_FAIL - inspector comes back up.

I also Depend on OnSubmit & OnSubmitComplete.

When I get OnSubmitComplete ( and I returned S_OK from ECE's OnSubmit to prevent Outlook from doing anything with the message ), I am free to delete the message ( or do whatever else I want ).  With MailItem.Send event ( OOM ), this is not the case - the message is locked for the duration of Send event.

In OOM, once I touch an item - Submit status is cancelled ( with the exception of getting "Submitted" property ).  ECE allows me to examine an IMessage ( e.g., in OnSelectionChange ) without cancelling Submit.  This is handy in cached mode.  For parity, I'd want a way to get IMessage from OOM without cancelling Submit status.

I think that it is safe to say that there are really good reasons to expose the same event notifications in OOM as existed in ECE.  I'm searching code that is important to our product that I've "inherited" and so I don't know it's ins and outs real well but I know we use OnRead, OnReadComplete, OnSubmit, OnSubmitComplete, OnWrite, OnWriteComplete, and several others.  The OnRead notification is crucial - being able to fix up a message before the user sees it is why we have the ECE application.

There does not seem to be the equivalent to the Exchange Client Custom Action in an Outlook Add-In. Supporting Custom Actions for Outlook Rules is the only place in our application where it is not implemented as an Outlook Add-In.

ECES has remained the same in recent versions whilst the object model is continuously changing and thus it is difficult to program for all versions of Outlook from 2000 upwards using the latest object model technologies. Compatibility with previous versions of Outlook is a pain for all new object model technologies, especially those that have to do with .NET (signed assemblies, Office PIAS, etc), that is a difficult story to handle reliably for all versions of Outlook. Even the recent Office Addin runtime v3.0 is only for version 2007 of Office and you need to maintain multiple versions of Visual Studio to support even only Office 2003 and 2007 together. ECES is the same everywhere. You learn one thing, implement it and it works. No redistributables and different Visual Studio tools versions and whatnot and no differents between Outlook versions.

Exchange Client Extensions are used in Outlook to extend the functionality of Outlook.  A developer