Is it possible that in any of your loops where you call DoEvents that the
loop could be re-entrant? Any possible UI actions that could be taken to
cause one of the loops to be entered again possibly?

I use DoEvents myself in many loops that do a lot of processing to both cede
cycles and to prime the Windows message pump and to present a semblance of
responsiveness. So it's possible that where the problem is seen in my addins
is due to DoEvents, although I'm very careful to make sure my loops aren't
re-entrant. But one never knows, do one?

I do know that in .NET code that when you try to get a synchronization
context for the main Outlook thread you can't get the context unless you
first prime the message pump by calling DoEvents, I've run into that one.
But VB 6 code doesn't have that bump in the road.

I'll have to play here with commenting out DoEvents calls in my timer
activated loops and see if that does anything to remove the problem for my
users who see Outlook 2007 hangs when typing in item bodies.

--
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 McGinty" wrote in message
...
snip
I compiled our AddIn with debugging info, and downloaded all the debugging
symbols for the system, to facilitate useful debugging with VS 2005, of
Outlook's process after it hung. This helped me to definitively isolate
the problem construct, in only a few painful but bearable hours. :-)

It appears that the problem -- or, at least, one manifestation of it -- is
caused by calling DoEvents, particularly in a loop (which, of course,
substantially ups the odds of it being called at exactly the wrong time.)

My Addin calls DoEvents 103 times, I've made a point of calling it in
practically every single loop, to minimize the UI impact of background
processing/make user cancellation possible. I guess we'll have to forego
that nicety under Outlook 2007.

As for the threadedness of background processing, I found (by outputting
the ThreadID of the current thread in every debug output) that every
single thing my AddIn does, is always called on the same thread, be it OOM
events, timer events on hidden forms -- everything. I can't say it's
impossible in VB6 to execute [in-proc] background processing on some other
thread, but from what I've seen it surely doesn't happen by accident.
(Use of out-proc COM servers excepted.)

In any case, OOM object access was not implicated in any of the AddIn's
post-hang callstacks I trapped into -- in this case all of them were
enumerating XML object collections. (Most of the loops that do so in this
code are fairly tight, which may serve to explain the behavior upon which
my observations were based.)

Unfortunately I don't have any simple, clean repro code to share [yet],
but I was able to reproduce the condition consistently, like ringing a
bell, running our [arguably somewhat convoluted] AddIn code. I will try
to pare it down to something simple enough to publish here, as time
permits.


-Mark