In part one of the Outlook NewMail unleashed series we took a closer look at the challenge of effectively handling a new e-mail in Outlook. We’ve seen that the obvious choice of NewMail, NewMailEx and Items.ItemAdd is simply not the answer. In this post we’ll investigate possible work-arounds and alternatives to NewMail, NewMailEx and Items.ItemAdd.
The first option in our line-up is to use Extended MAPI. As terrifying as extended MAPI might sound, you have no need to worry. Add-in Express provides a free .Net component to make it easier to access the extended MAPI features and subscribe to MAPI notifications, including when a new e-mail arrives. It also does not have the same limitations as the standard Outlook NewMailEx and NewMail events.
However, extended MAPI does have its limitations. In some cases the notification took a long time to be raised and in some cases it was not raised at all. The MAPI Store Accessor works in Outlook 2000 to Outlook 2010, unfortunately it does not support the 64-bit version of Outlook and Add-in Express is also not planning on introducing a 64-bit version.
So, in certain scenarios, extended MAPI might work for you. Third-party component such as Redemption are available to make accessing Extended MAPI a little easier. However, the limitations of delayed messages or messages not delivered will still remain. Of course, if you want more control and something more reliable why not consider creating your own solution?
Writing your own
Another and probably the most reliable option are to write your own timer based solution that will periodically scan your Outlook folders and check for new items. The scanning algorithm can be started from the SyncEnd event, which according to MSDN: “Occurs immediately after Microsoft Outlook finishes synchronizing a user’s folders using the specified Send\Receive group.”
However, this event does not occur when Outlook is starting up and there may be instances where an e-mail land in the inbox after the synchronization has finished. In order to work around this, you could have a time-based method that scans your Outlook folders on a pre-set interval. This method can use the Restrict method of the Outlook Items object to filter e-mails that have been received after the last e-mail that was processed ReceivedDate/Time. Be careful though, it is imperative that your servers’ time is correct, a problem Renat and I can tell you is something than can bite you. : )
Also, if your users will be using different timezones, you might want to consider using a DASL query with the restrict method; DASL always performs date/time comparisons in UTC. The book by Randy Byrne and Ryan Gregg, Programming Applications for Microsoft Office Outlook 2007 has an entire chapter dedicated to searching Outlook data, with or without using DASL, and I highly recommend it. You can read a sample chapter on MSDN.
Ideally, you would want to save the EntryId, ReceivedTime and information such as Subject and the Sender’s email address to an external data source, which could be anything from a flat text file, xml file or database. You might be asking yourself why I need to store all that information. Wouldn’t the EntryId suffice? Well, unfortunately no. There might be a situation where the EntryId of the e-mail might change which could cause you to process the same e-mail more than once. For example, if the new e-mail is moved to another folder by an Outlook rule or the user. It can also happen that the NewMailEx event’s EntryId parameter is a certain value, but changes if the email is moved to another folder.
The solution to the NewMail problem is certainly not an easy one, but if there is one team that can help you solve it, it is without a doubt the guys from Add-in Express. In the next few weeks we’ll dig into some code and walk through the two solutions mentioned above.
Thank you for reading. Until next time, keep coding!