Why do windows go blank?

[Joe User]

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.

 

[Homey]

i see this happen many times for many years. i don't like it but it never
seem to do anything bad so i just say that how excel is sometime whn you use
screenupdating = false.


"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.
|

 

[Joe User]

how excel is sometime whn you use
screenupdating = false.

I 'spose I could try that. But I would not think it would change anything
because: (a) the long-running macro is not modifying or even accessing the
worksheet; and (b) non-Excel windows are also affected adversely.

The other open, but background windows were Outlook Express and Notepad, for
sure. I might have also had some IE windows open, accessing some web pages.
I think the web pages were benign. But if any of those were Google web
pages, there could be "a lot" of activity going on, even though they are in
the backgound.

I did increase my sleep time to 100 msec every 1+ sec. And I closed all
windows except the Excel and VBA windows. The CPU-intensive macro ran for
45 min without affecting the system adversely.

So maybe the solution is indeed as simple as that.


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

 

[Joe User]

So maybe the solution is indeed as simple as that.

Or not. Happened again, despite the 100-msec sleep, closing all extraneous
windows, and minimizing the Excel window.


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

 

[RB Smissaert]

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]

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 -----

 

[CellShocked]

I 'spose I could try that. But I would not think it would change anything
because: (a) the long-running macro is not modifying or even accessing the
worksheet; and (b) non-Excel windows are also affected adversely.

You *think* it is "not accessing the worksheet".

I have a 30 MB DVD database that takes a while to do some lookups, and
takes longer on my macro that performs a save/close/re-open, which is
required to convert down to compatibility mode.

The HD indicator appears as if there is not much other than normal
accesses happening, but if there is a macro running, you can bet it is
looking at the spreadsheet data, even if the 'view' of it is within the
cache.

When Excel runs a macro, my CPU utilization always jumps to 100% during
the macro running. It seems to be an error at the base level. The choice
made for how many timeslices to give to a macro or some such. Either
way, it seems to be too much of a system hog.

Maybe MS should not have killed that IBM/OS/2 alliance after all. They
could do multi-thread processes way back when... on a single core.

You should see how poorly an old DOS based app runs when it was
psuedo-ported to windows. I have this major brand, expensive label
software that was based on an old DOS app, and they are so greedy that
they have yet to develop a proper windows port of it. It does NOTHING in
the background, ever.

 

[CellShocked]

Interesting. Shame that we cannot assign the priority (timeslice) level
of the vb runtime engine.

 

[RB Smissaert]

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]

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 -----