"RB Smissaert" wrote:
Sleep lInterrupt
DoEvents

Thanks for the pointer. I was not aware of DoEvents and the potential need
for it.

Having just read the help page, yes, calling DoEvents before or after or
perhaps instead of Sleep sounds like a good idea.


----- original message -----

"RB Smissaert" wrote in message
...
What I mean is that Sleep won't help you to get the interface updated.
How about a little procedure that runs Sleep in a loop with DoEvents
inter-mixed?
Not sure it will work, but just a suggestion.
Try something like this:

Option Explicit
Private Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)

Sub Sleep2(lTotalWait As Long, lInterrupt As Long)

Dim i As Long
Dim n As Long

n = lTotalWait \ lInterrupt

For i = 1 To n
Sleep lInterrupt
DoEvents
Next i

End Sub

Sub test()
Sleep2 10000, 1000
End Sub


RBS


"Joe User" <joeu2004 wrote in message
...
"RB Smissaert" wrote:
Sleep won't help

Why do think so?

I am referring to the kernel interface. I have verified that the time
elapsed across the Sleep call is indeed about 100 msec (for Sleep 100),
give
or take a few msec (which is understandable).


It happens because VBA is working hard and gives
no chance to update the interface.

I don't think so.

For your edification, try running the macro below while Task Manager is
open to the Performance tab. It clearly shows a square wave with
alternating cycles of 100% and near-0% CPU utilization. QED.

Don't forget to close all windows except Excel, VBA and Task Manager. I
also minimize the Excel window.


maybe you can use Application.OnTime instead.

Why do you think OnTime would have any better behavior than Sleep?

Besides, I indicated the need for msec resolution (originally 30; now
100). I believe OnTime has a 1-sec resolution. In order to get the same
"duty cycle", the CPU-intensive macro would have to run for 10 sec before
blocking for 1 sec using OnTime. I think that would exacerbate the
problem, whatever it is.


The macro....


Public Declare Sub Sleep Lib "kernel32" (ByVal msec As Long)
Public Declare Function QueryPerformanceFrequency Lib _
"kernel32" (ByRef freq As Currency) As Boolean
Public Declare Function QueryPerformanceCounter Lib "kernel32" _
(ByRef cnt As Currency) As Boolean

Sub doit()
Dim freq As Currency, sc As Currency, ec As Currency
Dim dt As Double, i As Integer
QueryPerformanceFrequency freq
'For about 50 sec
For i = 1 To 5
'CPU-intensive period
QueryPerformanceCounter sc
Do
QueryPerformanceCounter ec
Loop Until (ec - sc) / freq = 5
'Quiescent period
QueryPerformanceCounter sc
Sleep 5000
QueryPerformanceCounter ec
dt = (ec - sc) / freq
'Sanity check -- generous tolerance
If dt < 4.9 Or 5.1 < dt Then Exit For
Next i
'Last sleep duration
MsgBox Format(dt * 1000, "0.000 msec")
End Sub


----- original message -----

"RB Smissaert" wrote in message
...
It happens because VBA is working hard and gives no chance to update the
interface.
Put some DoEvents in.
Sleep won't help, maybe you can use Application.OnTime instead.

RBS


"Joe User" <joeu2004 wrote in message
...
I am using WinXP SP3 and Excel 2003 SP3 with VBA 6.5.


I have a long-running macro that is CPU-intensive. However, about
every
1 sec, I log some information and sleep for 20 msec.

After "a while" (it varies), one or more open windows go blank. That
is,
there is nothing but white inside the window frame. Moreover, my VBA
window is no longer the active window -- none is.

When I log to the Immediate Window, that window goes blank very soon,
often as soon as one page is filled (i.e. the window scrolls).

But this also happens when I log to a file -- and this time, it
happened
to all windows, foreground and background. (I had walked away from the
computer for about 45 min.)

The system is still responsive. When I "break" and end the macro,
everything is usually restored to normal. But it is still
disconcerting.

Any idea why that happens? Any idea how I can avoid it?

I suspect this is really a WinXP issue. Any idea what NG would be
monitored by responsive people who are knowledgable in this area (the
O/S)?

I've tried posting such technical questions to m.p.windowsxp.general in
the past. The response are usually not impressive.

I have extensive O/S background, albeit not with MS Windows. 20 msec
is
usually at least two "ticks" (about 33 msec on WinXP). That is usually
plenty of time to run other non-CPU-intensive processes, e.g. for
window
updates and timer-based bookkeeping.

Nonetheless, in other circumstances, I have extended the sleep to as
much
as 1 sec, to no avail.