Thanks for your help. As you say, this is one of those issues one despairs
of ever resolving because of all the variables.
I'm doing a debug.print (prints to a window in VBA). I've tracked where the
VB code is at every step, and it's doing nothing at all at the time the
Timer Event should fire.
The timer event (which is supposed to fire every 15 seconds) has been
reduced to this:
Debug.Print "before:" & Now()
If Minute(now) = 4 Then DoSomeX 'DoSomeX just does some more logging
Debug.Print "after: " & Now()
The debug window shows that the timer "forgets" to fire for a few minutes at
a time, randomly about twice a week, but only AFTER printing "after:"--so
it's not that some code in DoSomeX is preventing the timer event from
firing. Yes, there could be other things Vista is doing that prevents the
timer from firing, but I find that doubtful. First, at the list of times it
fails I've seen no CPU activity or disk activity, and no events in the event
viewer. Second, I've shutdown practically every Vista service that could be
shutdown (including disk defragmenter, the Windows Defender, System Restore,
Firewall, windows Search/indexer, and basically everything except basic
networking). I don't have antivirus on this system, which is usually a
culprit in mystery behavior (and no viruses on this system either).
Is there some alternative api code that I should use to get to the Windows
timer or system clock directly from within VBA (using a declare)? I suppose
I'd need callbacks to do that--but I need to get this to work. The
identical vba code worked flawlessly in Windows XP and office 2003, on the
same hardware. it could be that a bug has been introduced when vba Timers
are left running continuously for a long time, but it could be something
else entirely.
