stop report print batch

[mark]

Hi,

I am printing a batch of reports via a recordset loop. For each report
printed a new report object is instantiated.

To stop the printing, the user can click the Cancel button on the Access
dialog that appears.

This is not much use in this case, as subsequent reports will be printed
via the loop.

Is there an event in code with which to trap the pressing of the
'Cancel' button so that it can be reacted to programmatically to stop
the loop from progressing?

 

[Larry Linson]

Check VBA Help for "DoEvents". Include it in your loop -- it allows events,
including keypresses and button clicks, to be processed. But you'll still
need code in the loop to check for some flag and stop processing if needed.

Larry Linson
Microsoft Office Access MVP

 

[mark]

Thanks Larry, it does the trick.

Its a shame that Access does not raise a trappable event when the user
clicks the cancel button. It would look a lot more elegant to the user.

 

[Douglas J. Steele]

I don't see how it would be any different whatsoever for the user.

Yes, having such an event might make it more elegant for the developer to
implement the desired functionality, but once it's implemented, I doubt the
user cares!

 

[mark]

I don't see how it would be any different whatsoever for the user.

Yes, having such an event might make it more elegant for the developer to
implement the desired functionality, but once it's implemented, I doubt the
user cares!

The difference to the user is significant.

Using DoEvents, the user has to respond within the short interval within
processes. Therefore multiple key-presses / mouse-clicks have to be
applied to catch the DoEvents gap. (Lengthening this gap would reduce
performance.) This is somewhat counter-intuitive.

An cancel 'event' reacting to the cancel keypress however would act with
absolute precision, doing all the work with the one click.

 

[Douglas J. Steele]

The difference to the user is significant.

Using DoEvents, the user has to respond within the short interval within
processes. Therefore multiple key-presses / mouse-clicks have to be
applied to catch the DoEvents gap. (Lengthening this gap would reduce
performance.) This is somewhat counter-intuitive.

That's not my experience. When the DoEvent is encountered, whatever's in the
input queue is handled. If you set the form's KeyPreview property to True
(so that the form-level keyboard event procedures are invoked regardless of
what control has focus), you can put declare a module-level variable (such
as mbooEscape), then include code like the following

Private Sub Form_KeyPress(KeyAscii As Integer)

If Nz(Me.chkUserBreakout, False) Then
mbooEscape = (KeyAscii = 27)
End If

End Sub

After the DoEvent command, check whether mbooEscape is true, and cancel if
it is.

 

[mark]

That's not my experience. When the DoEvent is encountered, whatever's
in the input queue is handled. If you set the form's KeyPreview
property to True (so that the form-level keyboard event procedures are
invoked regardless of what control has focus), you can put declare a
module-level variable (such as mbooEscape), then include code like the
following

Private Sub Form_KeyPress(KeyAscii As Integer)

If Nz(Me.chkUserBreakout, False) Then
mbooEscape = (KeyAscii = 27)
End If

End Sub

After the DoEvent command, check whether mbooEscape is true, and cancel
if it is.

I've just tried this now (using A97)

As long as the Access Print dialog is displayed, the KeyPress is ignored
and an system beep is produced (denoting an inappropriate user input) -
i.e. the key input is discarded and not queued. (Perhaps you are
referring to other scenarios that do allow the input to be queued.)

For the KeyPress to catch the input, the finger must be pressed against
the key until the Dialog is removed and the DoEvents is reached.

(I personally used the alt-<> shortcut that fired the &-prefixed letter
on the 'cancel' control button that is on the form - it works to similar
effect.)

As I said, this method is counter-intuitive to the user, as the system
intimates an inappropriate action (with the system beeps) which must
nevertheless be ignored with the continued pressing of the relevant key.