How do you do? (an old dog learning new tricks)

[MyndPhlyp]

Broad strokes and the key method(s) are all I need here.

I have an unbound form, objects, etc. running off doing all sorts of data
manipulation when the user clicks a button. I want to allow the user to
click a Cancel button to stop the process, but I can't seem to do any user
input once the loop starts.

How do you enable the form (or object) to be interactive while a Click event
is off running in the background?

 

[Steve Schapel]

MyndPhlyp,

Ctrl+Break (?)

- Steve Schapel, Microsoft Access MVP

 

[MyndPhlyp]

That works. But I was looking for something a tad bit more graceful than
throwing the user into the code with and End/Debug option.

In theory, if I set the focus on the Cancel button, I should be able to get
the effect I'm looking for.

Setting the focus is no problem. However, while the code is off running,
clicking the button doesn't work - it won't sink in which means the OnClick
event isn't happening or isn't allowed to happen. I can't set a flag
trapping the event and handle it accordingly.

I'm missing the one little trick to let an event return control to the form
or button while it continues to run in the background.

Ideas?

 

[Ron Weiner]

If you have a compute intensive loop happening you may want to sprinkle a
few DoEvents into your code. This will allow the cancel button to "See" the
click. Other more serious issues are rolling back any changes that might
have already been made. So it unless you have already wrapped up your
changes in some sort of a transaction (assuming that the changes are written
to the database) you will want to take care of that as well.

Ron W

 

[MyndPhlyp]

If you have a compute intensive loop happening you may want to sprinkle a
few DoEvents into your code. This will allow the cancel button to "See" the
click. Other more serious issues are rolling back any changes that might
have already been made. So it unless you have already wrapped up your
changes in some sort of a transaction (assuming that the changes are written
to the database) you will want to take care of that as well.

Cool. DoEvents() looks like it is the majik I've been looking for. (Got
sidetracked on another project. Making a mental note now, but having
problems locating a crayon. They don't let me have sharp objects anymore
since that "little incident" years ago. Will they EVER forget?)

Thanx for the head's up about rolling back the database transaction, but it
is going to be a non-issue for now. Considering the size of the
"transaction," a rollback would cost some serious overhead. Besides, this is
data creation rather than data maintenance - I can just as easily blow off
all the rows just prior to beginning my run. I actually make a point of
turning off transaction logging and commit on every insert just to keep
memory and CPU consumption down to a minimum so as not to impact production.
(It's rather nice having that kind of latitude.)

 

[Sandra Daigle]

To add to Ron's comments - you can take a look at my Progress Meter sample
db - it shows one way of implementing a user abort by intercepting the
Escape key. This also relies on there being an occasional Doevents within
the iterative part of the process.

http://www.daiglenet.com/MSAccess.htm

 

[MyndPhlyp]

To add to Ron's comments - you can take a look at my Progress Meter sample
db - it shows one way of implementing a user abort by intercepting the
Escape key. This also relies on there being an occasional Doevents within
the iterative part of the process.

http://www.daiglenet.com/MSAccess.htm

I was thinking in terms of just setting the focus on the Cancel button and
camp out for a Click (or Enter), but an Esc would probably be a nice touch.
Thanx.