You seem to be much more accomplished but
I'll give it a go.

DoEvents is a keyword that lets the processing catch up with the code so to
speak.

For example, since we were talking about the VBE... I tried a while back to
build a comprehensive Cross reference for VBE code. I went through all the
code, picked up all the variables/function names/sub names and so on and
then went through the code again to collect references to that stuff. I
collected line  numbers where referenced and defined, module names and
procedure names where referenced, counted the number of times referenced and
so on.

While all this was going on... I've always been of the opinion that you
should give the user something  to see for her money... so I updated labels
in a userform  that reflected what was going on... Looking at this procedure
out of total ... counted so many variables so far this procedure.. this
module..this project etc.

I found that the labels weren't being updated because the code was executing
so fast the label didn't have time  to update  properly... it was just whited
out... Until the end.

I fixed by putting a DoEventsstatement after each of the label updates. It
slowed the process down but you could see what was going on because the
application waited until it's command  stack was empty before continuing.

Hmmmmm... one day I'll go back to that app. I stopped because I found
someone had done something similar... not so comprehensive but it did
produce a cross reference... with *much* less complex code. He'd taken about
2 weeks and I'd taken 5 months over it till then!!! So I thought buggerit.
Ah Well!

But for *intermittent* problems.. I usually look at timing probs first and
spatter my code with DoEvents deleting them judiciously till I get the
culprit. That's worked well when it's worked.. but it's not applicable to
lots of stuff and as I said... maybe not for you.

It's just a statement... It's in the help even... but if you still want an
example I'll send a bit of code from that application.

I just think *full* cross references are soooo valuable. You can see where
things aren't referenced and so on. I went on to start deleting variables
that weren't referenced, sorting Dim statements in procs and all kinda good
stuff... like going through code and deleting stuff commented as debug etc
etc. I got zapped though when I started deleting code from the same module I
was running. Which leads me to suspect that VBA looks down the code evertime
for the next line tag rather than following through.