Well, we have some choices here.
When the user clicks on that start button, we can launch our progress bar
form. That progress bar form can/could have a cancel button on it.
So, the code behind the button could look like:
docmd.OpenForm "ProgressBar"
' now start running our processing code:
Or, we could in fact have the code that does the processing be also placed
in our form with the progress bar form.
So, in fact, yes, you can place the code in the on open of the form. In
fact, you should use the on-load of the form, as on-open is really for
checking if you want to cancel the form load. However, lets not put the code
in that cute cancel form.
And, yes, lets forget about the issue of a progress bar also for now.
So, lets just assume you want a simple form with a cancel button on it.
Our code so far is:
' first lets open up a nice form with a cancel button for the user:
docmd.OpenForm "CancelForm"
' now start running our processing code:
dim i as integer
for i = 1 to 10000
' do somting
next i
The problem with the above, is that we likely will NOT see the cancel form
until our code is finished. Why? Well, because ms-access is so busy trying
to run your code, that the displaying of the form is still in the events
queue. It will finally get a chance to display when you code is done!
However, using DoEvents will flush out the events waiting. So, if we change
our code to:
docmd.OpenForm "CancelForm"
' now start running our procesing code:
dim i as integer
for i = 1 to 10000
DoEvents
' do something
next i
Notice how I put the do events in our processing loop. That doEvents is
really like giving a swimmer a breath of air. When you run DoEvents, all
pending things like mouse clicks etc are now processed. If your processing
loop takes a VERY LONG time for each interation of the loop, then even
DoEvents make may responsd too slow to the usre, and they will think your
program is frozzen.
Futher, there is no reason why we now cannot check, or test if the user hit
the cancel buttion on that cute "cancelForm" we made.
The code behind the Cancel Buttion in that cute form has to of couse set
some value that we can check each time in our processing code loop. So, the
code beind that cancel buttion on our form could be:
bolUserCancel = True
We will of course have to define the variable bolUserCancel in that cute
forms module section. So, we have.
Option Compare Database
Option Explicit
Public bolUserCancel As Boolean
Ok, so now, lets modify our processing loop to check for the cancel buttion
that gets pressing in that cute form. We how have:
docmd.OpenForm "CancelForm"
' now start running our procesing code:
dim i as integer
for i = 1 to 10000
DoEvents
if forms!CancelForm.bolUserCancel = True then
' user hit cancel. Close the cancel form, and stop.
docmd.Close acForm,"CancelForm"
exit for ' quit out procesisng loop
endif
' do somting
next i
So, the above gives you lots of ideas. You can even for prompt the user if
they really do want to cancel etc.
As mentioned, if you are executing some long query, and NOT a processing
loop of your own, then the above is not going to work, as you can't
test/check for the cancel button in your code...can you?