Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

looping through inbox messages / debugger under Outlook VBA

1,473 views
Skip to first unread message

Mark VII

unread,
Apr 9, 2008, 3:21:00 PM4/9/08
to
Greetings --

I'm trying to automate the process of detecting certain incoming emails and
writing them out as plain text files under Outlook 2003. Am running into a
couple of problems.

I have a rule pointing to a VBA subroutine, and the rule appears to trigger
when I use Run Rules Now. However, the VBA IDE does not behave as I am used
to in Access, Excel and Project. If I set a breakpoint, the code does not
break. Stop statements don't work either. Sometime a MsgBox statement will
pop a message box, sometimes not. Debug.Print statements sometime put
something in the Immediate window, something not. Not being able to set
breakpoints, view the content of variables, watch the loops loop, etc. is
making this very hard.

The underlying task is to read through the messages in the inbox and write
the body of ones that contain a certain keyword out as plain text files.
Between what I've found on the net and my own knowledge of object models,
here's what I've got at this point.

Public Sub ReadMessageBody(oItem As Outlook.MailItem)

Dim strId As String
Dim oNameSpace As Outlook.NameSpace
Dim oInboxItem As Outlook.MailItem
Dim oMailItem As Outlook.MailItem
Dim oFolder As Outlook.MAPIFolder
Dim oMsg As Object
Dim strBody As String

'* point to the name space
Set oNameSpace = Application.GetNamespace("MAPI")

'* set a reference to the inbox folder
Set oFolder = Application.GetNamespace("MAPI").GetDefaultFolder(olFolderInbox)

'* loop through the inbox
For Each oInboxItem In oFolder.Items
strId = oInboxItem.EntryID

Set oMailItem = oNameSpace.GetItemFromID(strId)
If Left(oMailItem.Subject, 6) = "Deploy" Then
'* save message body as text
Else
'* something else, ignore
End If
Next oInboxItem

End Sub

As best I can determine with no debugging capability is that the sub is
called, but does not enter the For...Next loop. Also, it appears to fire
once per file in the Inbox.

Can anyone give me any suggestions on how the use the IDE in Outlook? This
would be a lot easier to get working if I could used the debugger in the
usual fashion.

Thanks a million...

Ken Slovak - [MVP - Outlook]

unread,
Apr 9, 2008, 5:11:23 PM4/9/08
to
I don't know what's broken but none of what you describe is at all normal.
The Outlook VBA project should have identical debugging capabilities with
any other VBA project. I've never seen things like breakpoints not working.

What if you try to run your code manually by putting the cursor in a caller
procedure that calls the rule script procedure with any random mail item and
then press F5 to hit a breakpoint, can you step and otherwise do normal
debugging then?

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007
Reminder Manager, Extended Reminders, Attachment Options
http://www.slovaktech.com/products.htm


"Mark VII" <Mar...@discussions.microsoft.com> wrote in message
news:594028BA-023B-4EB3...@microsoft.com...

Mark VII

unread,
Apr 9, 2008, 6:15:02 PM4/9/08
to
Hi Ken --

One thing I'd already tried was to have a rule that invokes a sub, and the
sub calles the procedure that does the actual processing. Neither F5 for
breakpoint nor Stop statements worked there.

FWIW, I started with the processing logic in the sub invoked by the rule,
same results.

Interestingly, if I invoke the sub that does the actual processing from the
Immediate Window, breakpoints work like they should.

One thing I didn't mention is that I had been kicking off my rule from the
"run rules now" part of the Rules and Alerts dialog. Wonder if that's making
a difference, because there a dialog open.

Any thoughts in light of that?

Thanks,
Mark

Sue Mosher [MVP-Outlook]

unread,
Apr 9, 2008, 7:57:16 PM4/9/08
to
What I don't understand is why you're using a rule to fire off a process that iterates the entire Inbox. The whole point of a rule is to process the message that met the rule's conditions, i.e. the oItem object in your Sub's declaration. If you want to process all the items in a folder, don't use a rule for that, just write a normal macro.

--
Sue Mosher, Outlook MVP
Author of Microsoft Outlook 2007 Programming:
Jumpstart for Power Users and Administrators
http://www.outlookcode.com/article.aspx?id=54


"Mark VII" <Mar...@discussions.microsoft.com> wrote in message news:594028BA-023B-4EB3...@microsoft.com...

Ken Slovak - [MVP - Outlook]

unread,
Apr 10, 2008, 9:23:20 AM4/10/08
to
I'd agree with Sue, restructure your code to do what she mentioned and then
see if you still have those debugging problems.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007
Reminder Manager, Extended Reminders, Attachment Options
http://www.slovaktech.com/products.htm


"Mark VII" <Mar...@discussions.microsoft.com> wrote in message

news:F8D95549-2CF2-418E...@microsoft.com...

Mark VII

unread,
Apr 10, 2008, 10:58:02 AM4/10/08
to
Hi Sue --

Points well taken. What I did is driven partly by our processing
requirments, and partly due to my inexperience with programming Outlook. (I
can make Access and Excel sing and dance, but this is my first attempt at
automated processing of incoming email.) Here's a capsule on our situation
and my thought process, and am open wide to feedback. I've got a question
for you at the end.

We have some software that creates very large log files as it runs, but no
built in tools to analyze the logs. We have an Access database that parses
the log files, and loads some tables so we can query this data. Currently,
we save these log files by hand. Because our software sends out an automated
email with the log file text in the body, I want to automatically save the
body of these emails as a plain text file and move the emails to a desingated
folder.

Based on the research I've done so far, if a lot of emails arrive in a short
period of time, a rule that triggers a script may not always fire.
Similarly, I've read that the ItemAdd event and the NewMail events don't
always fire. Consequently, I thought it prudent to walk the whole inbox, so
we don't miss any files.

This leads to a question about your suggestion -- if I create a standard VBA
program, what is the best way to trigger it when a new email shows up?
Should I just write the program to run in a loop, looking for emails that
meet its selection criteria? (These log files come from a specific email
address and have specific text in the subject line.) This needs to run on a
user's PC (particulary mine), so what I do can't tie up the machine.

Thanks a million,
Mark


Sue Mosher [MVP-Outlook]

unread,
Apr 10, 2008, 11:13:00 AM4/10/08
to
I would use the NewMailEx event, which is the most reliable of all those available for processing new messages; see http://www.outlookcode.com/article.aspx?id=62 . I've seen it skip items only when running under extremely heavy load on a POP3 account. Check each new item to see if it meets your criteria. If so, process it.

If, after a while, you find that some log messages are being skipped, you can add code to the NewMailEx event handler to check to see if any older items are unprocessed. Use the MAPIFolder.Items.Find or Restrict method to do a search. Or, supplement NewMailEx with a Windows API timer routine that fires off every few minutes to check for new items.

--
Sue Mosher, Outlook MVP
Author of Microsoft Outlook 2007 Programming:
Jumpstart for Power Users and Administrators
http://www.outlookcode.com/article.aspx?id=54


"Mark VII" <Mar...@discussions.microsoft.com> wrote in message news:7B011ADE-E543-416F...@microsoft.com...

Mark VII

unread,
Apr 10, 2008, 11:23:02 AM4/10/08
to
Sue --

Thanks a million for the suggestions. I'll check them out..

Mark

0 new messages