why does the Rule get Un-Checked in Outlook 2003?

[Zoe]

so, there is a small Sub CustomMailMessageRule(Item as MailItem)

every morning, I have to go and check the rule (named Test) as it's listed
on top of all other rules and always unchecked

what process goes and unchecks it ?

the machine is automatically closing OL2003 every night at 04:00 and
restarts itself and restarts OL2003

when I come into the office, the rule is unchecked

 

[Ken Slovak - [MVP - Outlook]]

Usually if a rule ends up unchecked it's because there was an error in your
Sub.

 

[Zoe]

Usually if a rule ends up unchecked it's because there was an error
in your Sub.

yet it continues to run just fine while I'm in the office

it's the small email logger (with header and sender) I wrote about a few
days ago.

could a temporary unavailability of the network server cause it to error and
uncheck itself? If yes, then would an On Error routine negate the effects of
the unchecking?

 

[Ken Slovak - [MVP - Outlook]]

That could do it. I don't know if an error handler would help, it certainly
should be used in any case as a good practice.

 

[Zoe]

That could do it. I don't know if an error handler would help, it
certainly should be used in any case as a good practice.

Just now, one minute ago, while working on email, a message box popped up

"Rules in Error"

There is no information what is in error and the only option is Close

the test rule was thus unchecked in the Rules list and I had to go back and
manually check it again.

I have an On Error Goto Exit: in the start of the Sub and it's been happily
running all day long
Apparently that is not enough to keep the rule turned on and I wish I could
tell what was the error?

 

[Ken Slovak - [MVP - Outlook]]

Comment out your error handler and see where the code breaks when you do get
an error. An alternative that would also require manual monitoring would be
to set a breakpoint in your code and step the procedure to see where any
errors happen.

 

[Zoe]

Comment out your error handler and see where the code breaks when you
do get an error. An alternative that would also require manual
monitoring would be to set a breakpoint in your code and step the
procedure to see where any errors happen.

the error happens if in rapid succession multiple, subject only or subject
plus one line body emails arrive.

the Sub is not able to parse the received item fast enough and errors on the
2nd received email.

still don't know why and how to solve it.

surely OL2003 should be able to handle hundreds of back-to-back emails?

besides, what's the use of the On Error exit routine if it's not executed on
an error?

 

[Ken Slovak - [MVP - Outlook]]

The error handler is being executed, the problem is probably that your code
is taking too long and causing Outlook's input events to be missed. If a lot
of items come in at once there's a MAPI limitation anyway that would cause
the event to not even fire. That applies to the ItemAdd, ItemChange and
ItemRemove events on the Items collections of folders as well as to the
NewMail event. Even NewMailEx misses items sometimes.

I never use rules handlers like that anyway, there's too much out of your
control and too many cases where rules processing causes missed items or
interferes with other code that runs when items are added. I use ItemAdd
handlers for the Inbox and a timer based sweeper that sweeps the Inbox at
intervals to process any items that the ItemAdd handlers might have missed.

 

[Zoe]

use ItemAdd handlers for the Inbox and a timer based sweeper that
sweeps the Inbox at intervals to process any items that the ItemAdd
handlers might have missed.

care to share an example?

 

[Ken Slovak - [MVP - Outlook]]

An ItemAdd handler example? Look for ZapHTML at www.outlookcode.com for an
example that converts incoming HTML emails into plain text.

 

[BWCoaster]

Hi Ken,

I have seen you answer similar queries with the same way elsewhere and was
wondering if you could clarify something for me.

How do you set up a 'timber based sweeper?' I have done some searching, and
it appears that Outlook does not have any abilities to run scripts on a
timer. This does seem like a big omission to me. I would welcome any
direction you could provide.

Is there anyway for the calender/reminders/tasks to kick off an event that
would trigger a script? Outlook scripting is very new for me.

I have been thinking of other ways to how to get around the issue of
potentially missing emails to process if more than 15 hit the inbox at the
same time. Does this sound workable to you? - The itemadd event fires of the
script to process the first email that hits the inbox. At the end of the
processing, it moves any/all emails from the inbox to a tmp folder, and then
if there are any emails in the tmp folder it moves the first one back, thus
triggering the itemadd event again. exit sub and let the process begin again.
I think this may still fail if emails only ever arrive in big chunks
though?? What do you think?

Thanks very much,

B

 

[Ken Slovak - [MVP - Outlook]]

It's a timer based sweeper.

How you set that up depends on your programming language and platform. In
almost every language other than VBScript, which doesn't let you handle
ItemAdd anyway, you create a form and add the timer control that comes with
your language (VB.NET, C#, VB6, etc.) and use that. Another way to do it is
to use a Win32 API based timer, which doesn't require a form at all.

I usually set a timer for 30 second or 1 minute intervals for my sweeps. I
write a user property or named MAPI property to processed items if some
already existing property doesn't indicate processed items. I set the
property for items processed in ItemAdd and process others without that
property during the timed sweep.

I would not mess around moving items around in attempts to trigger events.

 

[BWCoaster]

Thanks for that Ken.
I had tried implementing something to move mails around as described, but it
does not work well, and creates other issues as you alluded to.

I don't have the means to create a 'timer based sweeper' outside the Outlook
environment at the moment, but I have found a work around that seems to be
working well at the moment.

The itemadd event fires a procedure that always loops through all items in
the inbox, and keeps looping until the inbox is empty (as I move processed
emails out of the inbox), however flagging all processed emails would work
the same I expect.

Thanks again,

B

 

[Ken Slovak - [MVP - Outlook]]

One thing to watch for when handling events like ItemAdd is not taking too
much time in the event handler. Most of the events are not re-entrant so the
event will be blocked if an instance of the event is still active. It's the
same thing at a hardware level when you handle interrupt requests. Take too
long handling an interrupt and the next instance of the interrupt won't
fire.

 

[BWCoaster]

Not sure if I totally comprehend this, is this what you are saying:
If an incoming email triggers the ItemAdd event, and it takes 2 mins to
process that email, if another email arrives whilst processing it will not
trigger the ItemAdd event (because the event handler is busy)?

Would this cause any other issues?

I am not too concerned if this is the only issue because the procedure
called by the event handler loops while 'myInbox.Items.Count > 0' After
exiting the loop, the procedure ends, then the event handler releases a few
objects and ends also.

Even if emails arriving 'queue up' if you like to fire the event handler
when it becomes available, it will call the procedure with the loop, but if
there are no emails in the inbox (because they were already processed in the
previous still running loop) it will just skip over it and end.

Thanks,

B

 

[Ken Slovak - [MVP - Outlook]]

Yup, that's exactly what it means. The following event won't fire.

For new emails you might want to use NewMailEx, which has a higher limit
before it starts to get flakey if you don't find your workaround adequate.

 

[BWCoaster]

Thanks for that.

Yeah - I'll be keeping a close eye on it over the next couple of months.
I'll keep NewMailEx in mind in case of any issues. It will only be in highly
unusual circumstances that I would be getting a large volume of simultaneous
emails in this system. Having said that though, experience has taught me to
expect the unexpected!

B