16 is the magic number

I have been developing a VBA in Outlook 2002. What this does is grab all spam and fiddles with it so they all end up in the delete folder. Works pretty well but isn't ready for prime-time yet.

But something I just noticed that I have never been aware of before. If I have 16 spams received at once so that the VBA acts on them all is fine. The program does what it is supposed to do. But if I have more then 16 mail items say 17 received at once then the VBA program fails to do anything. It doesn't run. 16 and less no problem. More than 16 failure. The VBA never even initializes. It just gives up without even getting out of the starting gate.

So this means if someone were to not access their Outlook 2002 for a period of time and then did and if there were more then 16 mail items waiting on the server for the client, the VBA I have made would fail to initialize.

I can reproduce this every rime. It has nothing to do with the type of mail items received. It is the number of mail items waiting to be served to the client where this behavior materializes.

So my question is this. Does Extended MAPI have a way of of allowing only chunks say mod 16 of items received so that it processes them in batches and the remainder in mod 16 of course are put on hold for processing at a later time? If not do you think this behavior can be worked around in another fashion? Say by using COM+ which can release received mail items in batches mod 16 to the client Outlook 2002?

Actually I am at a loss here why this is occurring. I assume it has something to do with the fact that 16 is a magic number in Computer geek. If any number I would have assumed it would be 32 and in 64 bit operating systems 64. But 16 in a 32-bit operating system? Something ain't right.

--
George Hester
__________________________________

Not sure, but I'd guess a memory leak somewhere.

--
Patricia Cardoza
Outlook MVP

***Please post all replies to the newsgroups***
"George Hester" <hesterloli@hotmail.com> wrote in message
news:eUUgYH1PDHA.2248@TK2MSFTNGP11.phx.gbl...
I have been developing a VBA in Outlook 2002. What this does is grab all
spam and fiddles with it so they all end up in the delete folder. Works
pretty well but isn't ready for prime-time yet.

But something I just noticed that I have never been aware of before. If I
have 16 spams received at once so that the VBA acts on them all is fine.
The program does what it is supposed to do. But if I have more then 16 mail
items say 17 received at once then the VBA program fails to do anything. It
doesn't run. 16 and less no problem. More than 16 failure. The VBA never
even initializes. It just gives up without even getting out of the starting
gate.

So this means if someone were to not access their Outlook 2002 for a period
of time and then did and if there were more then 16 mail items waiting on
the server for the client, the VBA I have made would fail to initialize.

I can reproduce this every rime. It has nothing to do with the type of mail
items received. It is the number of mail items waiting to be served to the
client where this behavior materializes.

So my question is this. Does Extended MAPI have a way of of allowing only
chunks say mod 16 of items received so that it processes them in batches and
the remainder in mod 16 of course are put on hold for processing at a later
time? If not do you think this behavior can be worked around in another
fashion? Say by using COM+ which can release received mail items in batches
mod 16 to the client Outlook 2002?

Actually I am at a loss here why this is occurring. I assume it has
something to do with the fact that 16 is a magic number in Computer geek.
If any number I would have assumed it would be 32 and in 64 bit operating
systems 64. But 16 in a 32-bit operating system? Something ain't right.

--
George Hester
__________________________________

Sounds like a memory leak to me!


>-----Original Message-----
>I have been developing a VBA in Outlook 2002. What this
does is grab all spam and fiddles with it so they all end
up in the delete folder. Works pretty well but isn't
ready for prime-time yet.
>
>But something I just noticed that I have never been aware
of before. If I have 16 spams received at once so that
the VBA acts on them all is fine. The program does what
it is supposed to do. But if I have more then 16 mail
items say 17 received at once then the VBA program fails
to do anything. It doesn't run. 16 and less no problem.
More than 16 failure. The VBA never even initializes. It
just gives up without even getting out of the starting
gate.
>
>So this means if someone were to not access their Outlook
2002 for a period of time and then did and if there were
more then 16 mail items waiting on the server for the
client, the VBA I have made would fail to initialize.
>
>I can reproduce this every rime. It has nothing to do
with the type of mail items received. It is the number of
mail items waiting to be served to the client where this
behavior materializes.
>
>So my question is this. Does Extended MAPI have a way of
of allowing only chunks say mod 16 of items received so
that it processes them in batches and the remainder in mod
16 of course are put on hold for processing at a later
time? If not do you think this behavior can be worked
around in another fashion? Say by using COM+ which can
release received mail items in batches mod 16 to the
client Outlook 2002?
>
>Actually I am at a loss here why this is occurring. I
assume it has something to do with the fact that 16 is a
magic number in Computer geek. If any number I would have
assumed it would be 32 and in 64 bit operating systems
64. But 16 in a 32-bit operating system? Something ain't
right.
>
>--
>George Hester
>__________________________________
>.
>

There is a known problem of Item_Add not firing if too many messages
are received at one time. It's mentioned in various KB articles.

Extended MAPI can get around this but you can only program MAPI using
C++ or Delphi, not VB/VBA. You can use Redemption
(www.dimastr.com/redemption) and MAPIUtils.NewMail or
Redemption.MAPITable to get around the problem.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Lead Author, Professional Outlook 2000 Programming, Wrox Press
Lead Author, Beginning VB 6 Application Development, Wrox Press
Attachment Options
http://www.slovaktech.com/attachmentoptions.htm
Extended Reminders
http://www.slovaktech.com/extendedreminders.htm


"George Hester" <hesterloli@hotmail.com> wrote in message
news:eUUgYH1PDHA.2248@TK2MSFTNGP11.phx.gbl...
I have been developing a VBA in Outlook 2002. What this does is grab
all spam and fiddles with it so they all end up in the delete folder.
Works pretty well but isn't ready for prime-time yet.

But something I just noticed that I have never been aware of before.
If I have 16 spams received at once so that the VBA acts on them all
is fine. The program does what it is supposed to do. But if I have
more then 16 mail items say 17 received at once then the VBA program
fails to do anything. It doesn't run. 16 and less no problem. More
than 16 failure. The VBA never even initializes. It just gives up
without even getting out of the starting gate.

So this means if someone were to not access their Outlook 2002 for a
period of time and then did and if there were more then 16 mail items
waiting on the server for the client, the VBA I have made would fail
to initialize.

I can reproduce this every rime. It has nothing to do with the type
of mail items received. It is the number of mail items waiting to be
served to the client where this behavior materializes.

So my question is this. Does Extended MAPI have a way of of allowing
only chunks say mod 16 of items received so that it processes them in
batches and the remainder in mod 16 of course are put on hold for
processing at a later time? If not do you think this behavior can be
worked around in another fashion? Say by using COM+ which can release
received mail items in batches mod 16 to the client Outlook 2002?

Actually I am at a loss here why this is occurring. I assume it has
something to do with the fact that 16 is a magic number in Computer
geek. If any number I would have assumed it would be 32 and in 64 bit
operating systems 64. But 16 in a 32-bit operating system? Something
ain't right.

--
George Hester
__________________________________

Ken this is just too much. No matter what I try to do, to do what I want to do I can't do what I want to do becasue these Microsoft products don't do what they are supposed to do. No damn wonder it is so easy for some to take all the security that is touted for these products and turn it into rubbish. Everyday there is a new fix for a Buffer Overrun in one product or another. I understand the Windows Operating system is complex and these issues are to be expected. But why just produce more rubbish before cleaning up the rubbish that has been previously made? That I don't understand. I guess the answer is in the fact that a computer has an average life of maybe 5 years for most and Microsoft counts on this to make additional rubbish because out of date rubbish isn't rubbish anymore. It's money received and that takes care of that.

I had the sneakiest suspicion if I posed this question I'd be spammed with contenpt for being such a nabob. Thanks for clearing it up for me.

--
George Hester
__________________________________
"Ken Slovak - [MVP - Outlook]" <kenslovak@mvps.org> wrote in message news:%23Ypo9r9PDHA.3236@TK2MSFTNGP10.phx.gbl...
> There is a known problem of Item_Add not firing if too many messages
> are received at one time. It's mentioned in various KB articles.
>
> Extended MAPI can get around this but you can only program MAPI using
> C++ or Delphi, not VB/VBA. You can use Redemption
> (www.dimastr.com/redemption) and MAPIUtils.NewMail or
> Redemption.MAPITable to get around the problem.
>
> --
> Ken Slovak
> [MVP - Outlook]
> http://www.slovaktech.com
> Lead Author, Professional Outlook 2000 Programming, Wrox Press
> Lead Author, Beginning VB 6 Application Development, Wrox Press
> Attachment Options
> http://www.slovaktech.com/attachmentoptions.htm
> Extended Reminders
> http://www.slovaktech.com/extendedreminders.htm
>
>
> "George Hester" <hesterloli@hotmail.com> wrote in message
> news:eUUgYH1PDHA.2248@TK2MSFTNGP11.phx.gbl...
> I have been developing a VBA in Outlook 2002. What this does is grab
> all spam and fiddles with it so they all end up in the delete folder.
> Works pretty well but isn't ready for prime-time yet.
>
> But something I just noticed that I have never been aware of before.
> If I have 16 spams received at once so that the VBA acts on them all
> is fine. The program does what it is supposed to do. But if I have
> more then 16 mail items say 17 received at once then the VBA program
> fails to do anything. It doesn't run. 16 and less no problem. More
> than 16 failure. The VBA never even initializes. It just gives up
> without even getting out of the starting gate.
>
> So this means if someone were to not access their Outlook 2002 for a
> period of time and then did and if there were more then 16 mail items
> waiting on the server for the client, the VBA I have made would fail
> to initialize.
>
> I can reproduce this every rime. It has nothing to do with the type
> of mail items received. It is the number of mail items waiting to be
> served to the client where this behavior materializes.
>
> So my question is this. Does Extended MAPI have a way of of allowing
> only chunks say mod 16 of items received so that it processes them in
> batches and the remainder in mod 16 of course are put on hold for
> processing at a later time? If not do you think this behavior can be
> worked around in another fashion? Say by using COM+ which can release
> received mail items in batches mod 16 to the client Outlook 2002?
>
> Actually I am at a loss here why this is occurring. I assume it has
> something to do with the fact that 16 is a magic number in Computer
> geek. If any number I would have assumed it would be 32 and in 64 bit
> operating systems 64. But 16 in a 32-bit operating system? Something
> ain't right.
>
> --
> George Hester
> __________________________________
>
>