Outlook VBA ignoring my breakpoint (1 Viewer)

[Isaac]

Last week I created an Outlook VBA procedure (sub), contained inside the ThisOutlookSession module, that takes one parameter - mi as MailItem

The reason I structured/located it like this, is because that's the guideline to be followed when you want to create an Outlook rule that passes control to a script ("Run a custom script").

Several times last week I tested the script by triggering the rule to run (either by making a matching incoming email come into my Inbox, or by Run Rules Now on Inbox items), and my breakpoints worked just fine. As soon as the item came into my Inbox, bam - my screen would instantaneously change to the VBA project, with the breakpoint line of code highlighted and the code in break mode.

Today this is not happening. Wondering, of course, if my rule + script was even firing, I put a Msgbox as a line of code immediately prior to the breakpoint. Sure enough - the Msgbox displays, but the breakpoint(s) are ignored.

Before I try deleting my local OTM file and re-creating (because I see no indicators of corruption other than this...the code is actually running correctly, it would seem from all other indicators), has anyone seen this before and knows the cause?

 

[Ranman256]

an error (without error traps) will exit the sub, thus not hitting your breakpoint.
after the msgbox, put a break, then step thru to see where it goes.

 

[Isaac]

an error (without error traps) will exit the sub, thus not hitting your breakpoint.
after the msgbox, put a break, then step thru to see where it goes.

Well, if it's true that an unhandled error in Outlook vba will silently exit the procedure without going into debug mode, that's something I definitely didn't know. Thank you, I will find a way to test this out. if true, it must have something to do with the interaction between the script and the rule, since my regular subs in Outlook have no trouble going into debug mode when an unhandled error occurs.

As far as the second half of your advice, that's the problem...I am putting up breakpoint on the earliest line of code on which a breakpoint can possibly be placed. What I'm saying is that my break points are being ignored. I have tried putting a breakpoint both on the opening line of the procedure which contains its name and the word sub, as well as putting one on the first line of code that assigns a value to a variable which is the first line of code I can put a break point on, and when executing all of these breakpoints are totally ignored.

But based on the first part of your advice I will put an error handler which I hadn't put yet, and we'll see if it hits the error handler with a message box etc. Thank you for replying.

 

[Micron]

If you put a break point on the first line and it doesn't break there, insert a message box line near the top to ensure it's running at all as suggested.
You have 3 options for breaking on error, 2 of which could apply here: break on unhandled, break on all errors.
I don't agree with that comment, really. An unhandled error should cause Access to look backwards in the stack for the first procedure that contains a handler. If none is found, the applicable built in message should arise - unless perhaps you have turned off warnings.

Sometimes your visible code does not match the compiled version, which usually necessitates a decompile (which you would only do after saving a backup, yes?). Ghost breaks are usually an indicator of this, but you seem to have the opposite problem. I would try that anyway if the message box does arise and a break point after it fails to stop code, as long as it's not exiting in the next line.

 

[deletedT]

Whenever a break point doesn't stop the code, I usually add a Stop statement instead. The procedure stops there.

Stop statement (VBA)

Office VBA reference topic

docs.microsoft.com

 

[Isaac]

If you put a break point on the first line and it doesn't break there, insert a message box line near the top to ensure it's running at all as suggested.

As mentioned in OP I already did that and it did hit the Msgbox, so I knew it was running (even more frustrating).

I don't agree with that comment, really. An unhandled error should cause Access to look backwards in the stack for the first procedure that contains a handler. If none is found, the applicable built in message should arise - unless perhaps you have turned off warnings.

I tend to agree, but was trying to remain open to the possibility that there is something "different" about when a script is run from a Rule (this Outlook not Access).

I would try that anyway if the message box does arise and a break point after it fails to stop code, as long as it's not exiting in the next line.

That's exactly what I had done originally ... but it refuses to recognize (i.e., stop on) any breakpoints.

OK finally this morning I was able to find someone else with my exact problem.

Debugging an Outlook 2007 script fired by a rule

I'm trying to debug an Outlook 2007 VBA script that's fired by a rule. I've set a breakpoint in the script but it doesn't get hit. The script is actually a Sub in the ThisOutlookSession object. W...

stackoverflow.com

Except I am on O365. (Why this is a known problem yet didn't occur with me last week, I can't imagine!)

1) adding an error handler did catch an error that I didn't know about! (unfortunately I still can't tell which line caused the error, since it won't go into break mode - only directly to my error handler! I might have to try that undocumented code lines feature, ERL or something, which I've never before)
2) but without the error handler, oddly, the code still not only a) ignores my breakpoints, but b) exits the routine with NO messages/warnings due to, apparently, an error

So I guess I will have to use the method described in that S.O. post above.....call this script NOT from a rule. Tried that once and so far, the only improvement is that when I try to run it, it gives me a run-time error with NO offer to debug.

Very weird.

 

[Isaac]

@Tera
Thanks, I tried putting a Stop line near the top of my procedure - even as the first line of code, as well as a bit down.
Still when I try to call my parameterized sub, it 1) from the rule, it runs with no messages at all, or 2) from an external sub and not from a rule, then it immediately displays the error (in the screenshot above), with no offer to debug or break.

 

[Micron]

Perhaps if you post the code someone might spot the error as it's one we see often? Or at least I have (in Access anyway).

 

[Isaac]

Tried to post my code, got an error message from AWF "please enter a message no longer than 10000 characters". ???? This code is only about 3 pages, I feel like I see messages like that all the time. Will look into and post back.

 

[deletedT]

You can attach it as a text file

 

[Isaac]

ok code is attached.

 

[Micron]

You're way ahead of me on this stuff. Does any of the info posted here help?
https://www.slipstick.com/outlook/rules/outlooks-rules-and-alerts-run-a-script/

 

[Isaac]

Slipstick is great - covers the basics. Been up and down that page. Will keep trudging along. Thanks for the replies.

Now on to creating 50 message boxes in place of the standard debugging techniques that have been stripped from me for some unknown reason! Very perturbed at Microsoft. Don't usually say things like that blaming the manufacturer, but geez...

 

[Isaac]

Well, now it's working, as in, the code seems to be running correctly.

Things I learned:

• Outlook VBA MailItem.Display simply will not work (often with no error), when using the interface "run rules now" (which has a big dialogue box displayed, apparently modally). It kind of makes sense ... But took me about 50 Msgbox's to discover.
• Breakpoints are sometimes totally ignored when running a Rule and "runs a custom script", and there is nothing you can do about it. Why it is happening now after last week not happening, I cannot explain. Also in this scenario, standard run time error message + ability to use Debug and go into Break mode becomes totally unavailable.
• MsgBox's are still effective and accurate in this scenario in lieu of break mode

Things I did:

• Deleted my .OTM file and started over
• Placed a bunch of msgbox's to test my code, which was working perfectly after a while with no error
• Made sure to test my code only by allowing a rule to naturally trigger based on incoming message - not using the "run rules now" interface

This experience leaves me a bit puzzled and more than a bit doubtful about the usefulness of Outlook scripts with Rules, but at least certain errors seem to have magically disappeared. I have no choice but to deploy this to the intended user with a disclaimer as to the reliability - a bit sad, but thankfully, Outlook programming isn't my bread and butter, and I'll think twice before bringing it up in the next meeting!