Mark items as read when deleted/moved to trash

Question

In Outlook 2010, using the code below, anything I delete or move into the trash folder is automatically marked as read.

Option Explicit
Dim WithEvents DeletedItems As Outlook.Items
    
Private Sub Application_Startup()
    Set DeletedItems = Session.GetDefaultFolder(olFolderDeletedItems).Items
End Sub
    
Private Sub DeletedItems_ItemAdd(ByVal Item As Object)
    If Item.UnRead = True Then
        Item.UnRead = False
        Item.Save
    End If
End Sub

It does not work at all in Outlook 2013.

Here is the code I am using to check how Outlook is seeing the read/unread status of the deleted emails. I lifted the Pause function from here.

Private Sub DeletedItems_ItemAdd(ByVal Item As Object)
    RememberItem Item 'Remember which email this is
    Debug.Print "At start: " & Item.UnRead 'Should be True
    If Item.UnRead = True Then
        Item.UnRead = False
        Item.Save
    End If
    Debug.Print "After mark read: " & Item.UnRead 'Should be False
    Pause 10 'In separate module. Code from https://stackoverflow.com/a/30196332/2623367
    Debug.Print "After pause: " & Item.UnRead 'Should be False unless item has become Unread
End Sub
    
Private Function RememberItem(Optional ByVal Item As Object) As Object
    'Allows check-up on the deleted item after event-handler is done with it.
    Static oDeleted As Object
    If Not Item Is Nothing Then Set oDeleted = Item
    Set RememberItem = oDeleted
End Function
    
Private Sub CheckStatus()
    Dim CheckItem As Object
    Set CheckItem = RememberItem
    Debug.Print "Follow-up check: " & CheckItem.UnRead 'Should be False
End Sub

The output I get:

At start: True (item is unread - this is correct)
After mark read: False (item is read - this may or may not be correct)
After pause: False (item is read - this is incorrect)
Follow-up check: False (item is read - this is incorrect)

UPDATE:

The answer marked as working did resolve my issue, though I occasionally still saw some odd behaviors.

A little more digging around revealed that the root cause was a sync issue between Outlook and the email server. Outlook would delete things, but the syncing would go screwy, and it looks like Outlook was pulling updates from the server before sending its own updates back. The discrepancies seem to have caused Outlook to lose track of what state deleted emails should be in.

My workplace uses Google Apps as their email provider, and I had set everything up in Outlook with the correct IMAP settings, but Google and Outlook don't play nice. Was able to eliminate all unpredictable behavior by using the selected answer and Google's Outlook syncing tool for Google Apps.

Also confirmed my original code behaves as it should when used in conjunction with the Google Apps sync tool.

I should have realized a lot sooner that the issue could be Google and Outlook being buggy together, but it didn't even occur to me, which is why I failed to mention the Google component of this equation earlier.

Are there any error messages? What happens when an item is put into the deleted items folder? Does the code run? — OpiesDad, Apr 26 '16 at 20:10
I tested this code in Outlook 2013 and it was working for me. — OpiesDad, Apr 26 '16 at 20:15
Are you remembering to turn on macros when you open Outlook? — OpiesDad, Apr 26 '16 at 20:16
@OpiesDad: No error messages, just nothing happens. Maybe some setting somewhere that I'm just not seeing or thinking would be an issue... I am definitely turning on macros when starting Outlook, though. — Ben S., Apr 27 '16 at 14:09
What happens if you manually run Application_Startup? Does it work then? If you put a break-point in Deleted_Items_ItemAdd, does it get to the break point? — OpiesDad, Apr 27 '16 at 15:15
@OpiesDad, I did, and I also put `Debug.Print Item.UnRead` before and after the If statement in DeletedItems_ItemAdd and a breakpoint before that first Debug. Sometimes it was marked as read, other times not, but was always returning as unread in the second Debug check. I also sometimes saw in the main application that it would be read initially and then not be. A few times, I had to re-run the Application_Startup sub manually because deleting an item would not trigger the event-handler at all. — Ben S., Apr 28 '16 at 15:58
Were you trying to say that the second debug check always returned as "read," or do you mean that it is inappropriately returning as "unread"? If it's returning as "read," when the ItemAdd event is triggered, does the item stay read when it gets into the deleted items folder or does it revert back to unread? — OpiesDad, Apr 28 '16 at 16:07
If it's not reverting back, do you have any other code in outlook, or is this the only code you have running? — OpiesDad, Apr 28 '16 at 16:07
@OpiesDad, sorry for the lack of clarity. To start with your last question, there is no other code running in Outlook. I can't tell if the second check is instantaneously correct and the message is revering or if the check is completely in error. To see if the message is reverting to unread, I put a 10 second delay in and ran a third check (see edit above), but that returns the item is read despite it obviously not being so. I added the manually-run CheckStatus sub to see if the debug checks mid-execution of the sub were just buggy, but that still erroneously says the item is read. — Ben S., Apr 28 '16 at 19:01

score 0 · Answer 1 · edited Aug 01 '17 at 06:33

This is too long for a comment, but I am confused by the problem, so I will restate it in my own words to clarify and show the process in steps.

The item gets deleted and may or may not have been read.

The DeletedItems_ItemAdd procedure is automatically called.

It seems like you may be having issues with this being called sometimes, but that this is not your main issue.

Item.UnRead is output. This seems to be working.

The message is checked to see whether it is unread, using the Item.UnRead property. This will return False if read, and True if not read. Item.UnRead is then set to False if it was True. If it was already False, it remains False. At this point, EVERY message should have the Item.UnRead property equal to False which actually indicates that the item has been read.

Item.UnRead is output.

What I am interpreting from your question is that this is always False, which means the item is read. Per step 4, I believe this SHOULD be False.

Your note suggests that this "may or may not be correct," but I do not understand when it is not correct.

There is a pause.

Item.UnRead is output.

Your note suggests that this has a value of False, indicating the item has been read. You believe this to be incorrect. I do not understand why.

A follow-up check is performed, outside of the normal procedure. I will assume that the code works correctly and that the correct message is checked. Again, you note that Item.UnRead is False, indicating the message has been read and then state that this is incorrect. Again, I do not understand why this is incorrect.

If my analysis is mistaken, please correct so that I can assist. As is, I cannot understand the problem. The code seems to be trying to set every message to read by setting the Item.UnRead property to False. Every check that I can see is returning False. What behavior is expected?

Your analysis is correct; I am just not doing a good job of explaining myself, and your patience and help are very greatly appreciated. The reason I say the return is incorrect is because while checking Item.UnRead programmatically returns FALSE--the item is read--the UI shows it as unread: Bolded when looking in the trash folder, and added to the unread items counter in the navigation pane. If I open the item or highlight it and manually mark as read, the UI then changes to show the item as read. — Ben S., Apr 28 '16 at 20:59
The reason I wrote "may or may not be correct" is because there is a few tenths of a second when the item moves into the trash that the unread items counter for that folder does not increase, but then it inevitably does. I say "may or may not" because I'm not sure if that means it was moved, marked as read so it didn't show in the counter, and then reverted to an unread status or if that slight delay is just the result of lag in the counter updating. — Ben S., Apr 28 '16 at 21:04

score 0 · Accepted Answer · answered Apr 28 '16 at 21:19

I haven't been able to figure out the exact issue you are having, as I can't replicate it, but try this:

Option Explicit

Dim WithEvents MainFolder As Outlook.Folder

 Private Sub Application_Startup()
     Set MainFolder = Session.GetDefaultFolder(olFolderInbox)
 End Sub


 Private Sub MainFolder_BeforeItemMove(ByVal Item As Object, ByVal MoveTo As MAPIFolder, Cancel As Boolean)

     If MoveTo.Name = Session.GetDefaultFolder(olFolderDeletedItems).Name And Item.UnRead = True Then
         Item.UnRead = False
         Item.Save
     End If
 End Sub

This seems to be doing the trick! Thank you so much. I really appreciate you taking the time and effort to help me out. — Ben S., Apr 29 '16 at 13:53

Mark items as read when deleted/moved to trash

2 Answers2