Please Wait screen for 2 seconds

  • Thread starter Thread starter Douglas
  • Start date Start date
D

Douglas

I have a place in my database where I want to calm the
user so I put up a please wait form. I am doing it
because it makes a better feel in a transition I am making
to another form. Then I close the Please Wait form when
the next form opens. Currenly I am doing this.

DoCmd.OpenForm "PleaseWait"

Dim vWait
Do Until vWait > 10000000
vWait = vWait + 1
Loop

DoCmd.OpenForm "Next Form" 'Close PleaseWait on OnOpen.

This is weak. How do I count seconds so the wait is
always consistent versus counting numbers.

Thank you for your help.

Douglas
 
Douglas said:
I have a place in my database where I want to calm the
user so I put up a please wait form. I am doing it
because it makes a better feel in a transition I am making
to another form. Then I close the Please Wait form when
the next form opens. Currenly I am doing this.

DoCmd.OpenForm "PleaseWait"

Dim vWait
Do Until vWait > 10000000
vWait = vWait + 1
Loop

DoCmd.OpenForm "Next Form" 'Close PleaseWait on OnOpen.

This is weak. How do I count seconds so the wait is
always consistent versus counting numbers.

How about using the Second(time) function? Use it once to retrieve the
current seconds portion of the time and stash it in a variable. Then go into
a loop repeatedly comparing to that value. (I don't know if there is a sleep
or timer method available.)
 
Douglas said:
I have a place in my database where I want to calm the
user so I put up a please wait form. I am doing it
because it makes a better feel in a transition I am making
to another form. Then I close the Please Wait form when
the next form opens. Currenly I am doing this.

DoCmd.OpenForm "PleaseWait"

Dim vWait
Do Until vWait > 10000000
vWait = vWait + 1
Loop

DoCmd.OpenForm "Next Form" 'Close PleaseWait on OnOpen.

This is weak. How do I count seconds so the wait is
always consistent versus counting numbers.

Search the online help for "Timer Event." (You got me curious enough to
look.)

=====
The Timer event occurs for a form at regular intervals as specified by the
form's TimerInterval property.

Remarks

To run a macro or event procedure when this event occurs, set the OnTimer
property to the name of the macro or to [Event Procedure].

By running a macro or event procedure when a Timer event occurs, you can
control what Microsoft Access does at every timer interval. For example, you
might want to requery underlying records or repaint the screen at specified
intervals.

The TimerInterval property setting of the form specifies the interval, in
milliseconds, between Timer events. The interval can be between 0 and 65,535
milliseconds. Setting the TimerInterval property to 0 prevents the Timer
event from occurring.
 
Hi,
Put this declaration and function in a standard module:

Declare Function GetTickCount Lib "kernel32" () As Long

Public Sub Pause(HowLong As Long)
Dim u%, tick As Long
tick = GetTickCount()

Do
u% = DoEvents
Loop Until tick + HowLong < GetTickCount
End Sub

You can then pause code anywhere like this:

Pause 2000

The above will pause for 2 seconds (values are in milliseconds)
 
Dan said:
Put this declaration and function in a standard module:

Declare Function GetTickCount Lib "kernel32" () As Long

Public Sub Pause(HowLong As Long)
Dim u%, tick As Long
tick = GetTickCount()

Do
u% = DoEvents
Loop Until tick + HowLong < GetTickCount
End Sub

You can then pause code anywhere like this:

Pause 2000

The above will pause for 2 seconds (values are in milliseconds)

Dan, I'm not particularly familiar with it, but why not use
the Sleep API?

Private Declare Sub Sleep Lib "kernel32" _
Alias "Sleep" (ByVal dwMilliseconds As Long)
 
Hi Marsh,
I guess I just got in the habit of using this when I was involved in a VB project.
I needed to pause the code *but* I also needed the app to stay responsive.

If I'm not mistaken, the Sleep api will freeze the entire app for the duration.
 
Dan said:
Hi Marsh,
I guess I just got in the habit of using this when I was involved in a VB project.
I needed to pause the code *but* I also needed the app to stay responsive.

If I'm not mistaken, the Sleep api will freeze the entire app for the duration.


Ah, I see.

Thanks
 
Actually, guys....it is FAR better to use the sleep api.

Today's modern computers can easily execute 40 million VBA instructions per
second. You read this right...40 million VBA instructions! We are not
talking about compiled c, or assembler, but good old fashioned VBA. These
new computers are blindly fast!

If you run a blank loop, or use the sleep api, you don't service the users
anyway.

However, by using the sleep api, you don't ask that processor to execute
those HUGE number of loops. Those loops are really like flooring the gas
pedal, takes all of the processing the cpu can give. While windows does a
great job of giving processing to all other tasks..you do run the pants off
of the processor when running a blank loop.

When you use the sleep api, then the time slice and ALL processing is given
to the rest of the windows system.

So, there NO difference in responsiveness when using either approach, but
running a processing loop to slow down, or cause a delay will also impact
all other processing on the computer. This is simply a waste of the
incredible and blindingly huge amount of processing we have at our finger
tips these days. Thus the api sleep should be used, as it will NOT use ANY
processing, but release all resources to OTHER windows programs.

The ONLY reason to use your own custom loop is that you CAN do some event
processing at the SAME TIME, or even check for user actions (like a cancel
button for a VERY long process)

for i = 1 to 100
' crunch some data sub
DoEvents

if forms!MyProGressBar.Cancelled = true
If MsgBox("Cancel this long update?", vbQuestion + vbYesNo) = vbYes
Then
exit for
end if
end if
next i

In the above, adding the doEvents means that all mouse clicks etc are
processed. If we use a sleep api, then you can't do that. However, we are
not talking about un-responsive problem with our code..but in fact just want
a delay.

If you just want the code to wait, then sleep the poor computer. There will
no difference in your programs responsiveness..but it will impact OTHER
programs running if you use tons of processing to just make your program
wait.
 
Excellent explanation Albert.

Thanks for clarifying the ins and outs on this issue.
 
Hi Albert,
The reason I had to do that was beause I had a loop that would create instances of
ActiveX exe's. These exe's would do their thing and then call back into the main app
by firing an event, also, within the loop that was creating these things, I was using the winsock
control to communicate with an agent on a remote PC. I had to absolutely make sure the
socket was in a particular state before continuing code execution, therefore I needed a loop
with a DoEvents in it so that the socket state could be detected and also to receive any events
raised by my exe's.
 
Dan said:
Hi Albert,
The reason I had to do that was beause I had a loop that would create instances of
ActiveX exe's. These exe's would do their thing and then call back into the main app
by firing an event, also, within the loop that was creating these things, I was using the winsock
control to communicate with an agent on a remote PC. I had to absolutely make sure the
socket was in a particular state before continuing code execution, therefore I needed a loop
with a DoEvents in it so that the socket state could be detected and also to receive any events
raised by my exe's.


I guess this topic is a LOT deeper than it seems at first
glance.

But, Dan, when you have to poll for the completion of
asynchronous activities, you have no choice but to run code
in a loop. My only thought is that it might still be a good
idea to use something like Sleep 200 in the loop? Or maybe
with all those DoEvents, it might not make a significant
difference.

Albert will probably come back and straighten me on out this
idea too ;-)
 
But, Dan, when you have to poll for the completion of
asynchronous activities, you have no choice but to run code
in a loop. My only thought is that it might still be a good
idea to use something like Sleep 200 in the loop? Or maybe
with all those DoEvents, it might not make a significant
difference.

Albert will probably come back and straighten me on out this
idea too ;-)

No, don't really have much to add. I certainly do think that
putting in a "bit" of a sleep as you suggest to save some processing
is a very good idea. I would explore this idea even in Dan's case.

I will also mention that DoEvents is a expensive command, and takes a lot of
time to execute. So, often, the doevents command is the most expensive
command in the loop! (In a very fast loop that needs to be executed MANY
TIMES I would not execute it every iteration of the loop, but perhaps every
1000th time).

However, it would seem that Dan's case was special, and sometimes you just
don't want to take any chances. Winsock can *usually* trigger that some data
is available, but you don't want to be caught sleeping since some data might
be lost. (and api "sleep" pun is intended here!). If you sleep, you might
missing something. If there is chance of data being dropped, then you want
to grab all the processing speed the computer can give. It seems that Dan's
had a good case for not using the api and did not want miss any incoming
data.

However, I think it is quite clear that for general code that needs to
"wait", then "sleeping" is far more recommended then that loop. And, of
cause if you double the processing, then the loop will take 1/2 the time
anyway. So, any delay you need should be based on time.

Of course folks like Dan gets to write all kinds of neat-o code that is
exempted from my general advice anyway!...........but that is just a
compliment to Dan's skills!
 
Well thanks for the compliment Albert!
In any case, I'm sure the OP just wanted the app to 'sleep' for 2 seconds
so my 'Pause' suggestion might not be appropriate in this case ;-)
 
Back
Top