Trouble with this WaitFor() procedure...

[MLH]

This was contributed by someone in this NG
last year...

Sub WaitFor(psngSeconds As Single)
' wait for specified number of seconds
' Copyright Trevor Best ([e-mail]) <-OK, so I added
thisline.

Dim sngStart As Single
Dim sngET As Single

sngStart = Timer
DoEvents
Do While sngET < psngSeconds
DoEvents
' check for mighnight as the Timer() function will
' rollover at this point
sngET = Timer - sngStart
If sngET < 0 Then
' it rolled over - add number of seconds
' in a day
sngET = sngET + 86400
Beep
End If
' now don't hog the processor
' release some CPU slices back to Windoze
DoEvents
Loop
End Sub

Trouble is - it doesn't always wait. I've watched it
carefully. Sometimes the actual waiting time is zero.
In spite of the setting of psngSeconds argument.
Anyone know what might be causing this eratic
behaviour?

[MLH]

Stick a command button on a test form with
the following code in it. Open the form & click
the button. If your debug window is open,
you'll see the problem clearly illustrated.
Private Sub Command0_Click()
Commence:
WaitTime = 10 + Int(Rnd * 41)
Debug.Print "Waiting for " & Trim$(CStr(WaitTime)) & " seconds..."
WaitFor (WaitTime)
GoTo Commence
End Sub

[MLH]

Can anyone tell me why, if you run the code behind
the Form command button described above - why does
the code keep on running even I close the form? The
only way I can stop it is to close the database itself.

I thought opening a form in design view or closing it
would halt the processes running on the form. That
must not be the case.

[Lyle Fairfield]

The VBA While is not waiting for ten seconds. It is working for ten
seconds.

Declare Function Sleep& Lib "kernel32" (ByVal dwMillisecond&)

Private Sub Command0_Click()
Debug.Print Now()
Sleep 10000
Debug.Print Now()
End Sub

What we could hope is that this sleeps more soundly than the VBA
function; that is, the cpu usage is not 100% as it is with a VBA While
Procedure. And, of course, it does not need to check for pumpkins.
Documentation indicates it suspends operations only in the thread
wherein it is called; so the absence of DoEvents !!!!!SHOULD!!!!! not
be a problem.

SleepEx is an advanced function, that when used with ?????FileEx
functions can sleep for the entire time specified but return early if
an input or output operation completes.

[MLH]

Dev Ashish posted something like this 8-years ago. I haven't
been using it because calls to sapiSleep() sub act more processor
intensive than those to VBA WaitFor() procedure. I'm reading
what you've written below, and it does seem logical. However,
I can grab windows by their title bars and move them around
whilst WaitFor'ing and I can't do that when sapiSleep'ing. Maybe
that seems contradictory to the documentation. But it's True. If
I'm WaitFor'ing say for 30-seconds, I can click the Database
window, open an object in design view then close it. On the other
hand, if I'm sapiSleeping for a similar time period, I cannot select
any other database object during that time. Nor can I grab the
form in which the sapiSleep procedure was Called by its Title Bar
and move around. Am pretty much lock out-a-doing anything
until the sapiSleep time period expires. Why is that?

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxx

On 23 Jan 2007 10:08:59 -0800, "Lyle Fairfield"
<ly***********@aim.comwrote:

>The VBA While is not waiting for ten seconds. It is working for ten
seconds.

Declare Function Sleep& Lib "kernel32" (ByVal dwMillisecond&)

Private Sub Command0_Click()
Debug.Print Now()
Sleep 10000
Debug.Print Now()
End Sub

What we could hope is that this sleeps more soundly than the VBA
function; that is, the cpu usage is not 100% as it is with a VBA While
Procedure. And, of course, it does not need to check for pumpkins.
Documentation indicates it suspends operations only in the thread
wherein it is called; so the absence of DoEvents !!!!!SHOULD!!!!! not
be a problem.

SleepEx is an advanced function, that when used with ?????FileEx
functions can sleep for the entire time specified but return early if
an input or output operation completes.

[Lyle Fairfield]

The WaitFor function yields to other processes when it calls DoEvents.
But it is enormously inefficient, looping more than a thousand times
per second of wait (depending on cpu ... on a very fast cpu I suppose
this could approach 100, 000). As well the consecutive DoEvents can
confuse the process so that if we immediately make a subsequent call to
the function, there is no wait at all (as you have noted). Removing one
of the DoEvents solves that problem but it doubles the number of loops
made.

On the bizarre side we could write the function as
Dim z As Long
For z = 0 To 30000
DoEvents
Next z
or whatever number is appropriate for your cpu.

There is no loop in Sleep and, as a result, no where to put a DoEvents
If you modify the size of your Window you will find that you can click
buttons etc in other processes, but not in Access which is the process
that is "asleep".

Trevor has contributed many great functions. WaitFor is not one of
them. If you really must be able to click in (Access) windows while the
process sleeps then you could try something like:

For z = 0 to 9
Sleep 999
Do Events
Next z

[MLH]

Based on this reply, I think I'll go with the
Sleep'er. Come to think of it, I really don't
need to be monkeying in the Access app
while procedure that is sleeping snoozes.

I would be perfectly happy to work in other
apps during that time. Will give it a try.

[MLH]

Lyle, what might I do to determine whether
(A) opening a form in dialog mode whose Timer
event property was a procedure that did nothing
but close the form 10 seconds after opening

IS LESS PROCESSOR INTENSIVE THAN

(B) using sapiSleep to effect a similar 10-second
delay in a procedure.

Like this - suppose the following is a snippet from
my procedure

....
code
code
code
more code

now do (A) OR do (B) and determine which places
the least load on the system

code continues
code
code
blah, blah, blah