Outlook COM object model not suitable for use in professional software?

[Jeff]

I admit that it's taken me a while to realize this, but it seems that
the Outlook COM object model is simply not well suited for developing
professional software against.

Take, for example, the ItemAdd event. It's documentation states that:

"This event does not run when a large number of items are added to the
folder at once." - MSDN
(http://msdn.microsoft.com/library/d...n-us/vbaol11/html/olevtItemAdd_HV05254252.asp)

How can I write software that depends on the ItemAdd event and sell it
to my customers? I'd have to add the disclaimer to my software that
states that it might not work all the time. That's unacceptable.

Another example would be how MAPIFolder.FullFolderPath fails sometimes:
(http://groups.google.com/group/micr...3e?lnk=gst&q=budajeff&rnum=5#c9e0ccb1404d223e)

What API do I have to use to have a consistent, deterministic
interaction w/ Outlook?

Jeff

 

[Dmitry Streblechenko]

Well, if a screwdriver doesn't work too well for nails, you simply use a
hammer, right? No reason to blame a screwdriver
MAPI events were never designed for any kind of synchronization, they were
always meant to be used for the UI purposes only.
Under Exchange, you can use the ICS (Incremental Change Synchronization) API
(Extended MAPI, C++ or Delphi only).
Otherwise you need to come up with some other kind of synchronization
mechanism.

If you need to have full control, use the same API used by Outlook itself:
Extended MAPI.

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

 

[Jeff]

Thanks Dmitry.

In my one example of this event, MS should just remove the event if
they can't reliably trigger it, and worse, don't even bother to
document what a "large number of items" even is. I thought programming
was quantitative, not qualitative.

I still blame the screwdriver in this case, and I would warn anyone
thinking about writing reliable software based on the Outlook COM
object model that you should save yourself a lot of grief and just use
Extended MAPI. After you look at Extended MAPI and see how complicated
it is, subcontract that part of your project out to Dmitry and have him
do it for you. ;-)

If you choose to ignore my warning, count on spending a lot of time
explaining away the bugs in your product that are a direct result
Outlook COM inadequacies to your customers.

Good luck,
Jeff

 

[Jeff]

One final thought, the fact that you need Dmitry's Redemption library
to do any useful work w/ Outlook COM proves my original point.

 

[Dmitry Streblechenko]

Jeff, I think you are missing my point - MAPI events were *designed* to be
dropped under heavy loads: Exchange uses UDP to brodcast the events, they
did not use anything more reliable on purpose: it is way too expensive on a
network with 1000s of machines. The events are used by Outlook for the UI
purposes only; it never relies on them for anything that can potentially
cause the data corruption.

It does not matter whether you use OOM or Extended MAPI to process the
events - the OOM limitations stem from the MAPI limitations. The only thing
that OOM misses are the (fnevTableModified, TABLE_CHANGED) and
(fnevTableModified, TABLE_RELOAD events (of course Redemption exposes them
through the RDOItems.CollectionModified event). These events are fired if
too many modifications (>16) are raised at the same time.

You can still use events for synchronization, as long as they are used as
simply a hint that something happened, not as the only trigger used to
perform the synchronization.

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

 

[Jeff]

Thanks for the clarification Dmitry. I did miss the point.

Jeff