Reputation: 9297
Okay, this is a bit of a tricky one...
I am programming an add-in for MS Outlook 2007, using VS 2010 and VSTO, and VB.NET. My goal is to prompt the user to print off emails that they receive from certain email addresses. (This would be done with a simple MsgBox.)
Specifically, I would like the prompt the user when they are done reading the email. My concept is that it should work similarly to the "Read Receipt" functionality in Outlook. (You know, those annoying things..."The sender has requested a receipt that you have read this email blah blah")
So, the user reads the email, and then when they go to close the Inspector (or change focus to a different item if they are in Explorer view) the MsgBox pops up. I have noticed that the timing on this matches when the email becomes "read".
I have been chasing this across Google and MSDN and tutorial websites for a few days, here's what I've found:
Round 1: The Mailitem object has an UnRead property, and it also has a PropertyChange event. I can use AddHandler for PropertyChange on every Mailitem in the Inbox, tying them into a single Subroutine that checks the argument of the PropertyChange event to make sure it's UnRead. Seems fairly workable, except that PropertyChange doesn't pass the calling object's identity, so I have no way of knowing what email in the Inbox just lost "unread" status.
In fact, none of the Mailitem events seem to pass their identity, probably because someone (MS I guess) assumes that you have a direct pointer to the Mailitem object in the first place. So this route doesn't seem to work.
Round 2: I can grab all of the Mailitems in the Inbox into a collection, then restrict them to just the Unread ones.
Dim inbox As Outlook.MAPIFolder = Nothing
Dim WithEvents unreadItems As Outlook.Items
inbox = Me.Session.GetDefaultFolder(Outlook.OlDefaultFolders.olFolderInbox)
unreadItems = inbox.Items.Restrict("[Unread]=true")
Since unreadItems was Dimmed WithEvents, I could write a Sub to Handle unreadItems.ItemRemove, which would work fine. But the ItemRemove event has no object argument! Doh!
Round 3: Let's say I do the opposite: I get the inbox contents and restrict to [Unread]=false, then use the .ItemAdd event. This would work to a degree, except that it would theoretically call whenever an "[Unread]=false" item was dumped into the Inbox by the user from any folder, not just a change from the Unread to Read group within the Inbox. So, unless I'm misunderstanding something here, also not an option.
Round 4: Now, something I also thought of was simply Dimming the Inbox items collection WithEvents and going off the .ItemChange event, but this event doesn't really specify what changed about the object, so no dice.
In closing, I'm pretty darn stumped with this. I am very close to backing down from my goal. A lame alternative is to alert the user when they receive an email from one of the designated addresses (because I believe the Application.NewMail event won't give me any hassle). But then, I will have to simply alert the user--I won't prompt them to print an email they haven't even read yet.
This alternative is undesirable and I figured that I would present my problem for inspection and suggestion.
-Matt
P.S. I'm coming from making iPad apps with Objective-C, where I'm building most of the object hierarchy myself...it's weird to have to deal with COM objects that have such limitations.
Upvotes: 0
Views: 2288
Reputation: 4954
I'm not quite sure how you want your UI to behave, because it's not quite clear when the user is done reading their email. One way to look at it is that they are done when they have looked at it, meaning that the inspector window has shown the mail and the user is switching to another one. To catch that, you would probably be best off watching events from the inspector, not the mail items. The other way to look at it is that a mail is read whenever it is marked as Read. Be aware that the user may actually turn off the option to mark items as read automatically! This can be done in Tools->Options->Other->Reading pane, like this:
Also, the user may select items and mark them as read manually, so you need to think about what you want do in that case.
If you want to watch for the change in "read" property of the MailItem, you are very close in round 1. The thing you need to add is that you shouldn't tie all of your handlers to a single subroutine in a single object instance. Instead, you can create your own class, something like this (C# code):
class ItemWatcher
{
// The Outlook mailitem to watch for
private Microsoft.Office.Interop.Outlook.MailItem itemBeingWatched = null;
public ItemWatcher(Microsoft.Office.Interop.Outlook.MailItem item, Form1 parentForm)
{
itemBeingWatched = item;
itemBeingWatched.PropertyChange += new Microsoft.Office.Interop.Outlook.ItemEvents_10_PropertyChangeEventHandler(itemBeingWatched_PropertyChange);
}
void itemBeingWatched_PropertyChange(string Name)
{
// Respond to property <Name> in the object itemBeingWatched having changed
}
}
Then you need to create a collection of your ItemWatcher classes and set them to watch your emails.
Note that you will also need to watch for items you need to add/remove from your collection of watched items, when a new mail arrives or an old mail is deleted/moved.
Upvotes: 3