When a Visual Basic procedure is running, a user can interrupt it by pressing CTRL+BREAK or ESC. Although you may need to be able to interrupt procedures when you're debugging, you might want to prevent the user from interrupting procedures in the finished application. If you do allow user interrupts in a finished application, however, you can make sure that your procedures are notified of them so that the procedures can close files, disconnect from shared resources, or restore modified variables before returning control of the application to the user.
You can trap user interrupts in your procedures by setting the EnableCancelKey property to xlErrorHandler. With this property setting in effect, all interrupts generate run-time error 18, which you can trap using an On Error statement. You can handle this error to halt the procedure and exit the program. However, if you use the Resume statement to continue running the procedure after a run-time error has been trapped, the interrupt is ignored.
The following example illustrates a procedure that requires a long time to complete. If a user interrupts the procedure while it's running, an error is trapped — first to confirm that the procedure should be stopped, and then to exit the procedure in an orderly way. Note that you can use only one interrupt handler for each procedure, and that the same handler is used for all other run-time errors encountered in that procedure.
Sub ProcessData
' Set up user interrupt trapping as a run-time error
On Error GoTo UserInterrupt
Application.EnableCancelKey = xlErrorHandler
'Start a long duration task
OpenDataFile
For x = 1 To 1000000
ProcessRecord x
WriteOutRecord x
Next x
CloseDataFile
Exit Sub
UserInterrupt:
If Err = 18 Then
If MsgBox ("Stop processing records?" , vbYesNo) = vbNo Then
' Continue running at the point we were interrupted
Resume
Else
' Close open files before returning
CloseDataFile
Exit Sub
End If
Else
' Handle other errors that occur
MsgBox Error(Err)
Resume Next
End If
End Sub
You can also ignore user interrupts completely by setting the EnableCancelKey property to xlIgnore. With this property setting in effect, Microsoft Excel ignores all attempts by the user to interrupt the procedure that's running.
Note
Use caution when disabling or ignoring user interrupts. It's possible to write code that never returns or ends. If you disable interrupts by setting the EnableCancelKey property to xlIgnore, or if you always use the Resume statement to return from a trapped error, your procedure won't return control to the user.
You can restore the default interrupt processing of Microsoft Excel by setting the EnableCancelKey property to xlInterrupt. To prevent a procedure from permanently turning off user interrupts, Microsoft Excel always restores the value of the EnableCancelKey property to xlInterrupt whenever code execution ends. To ensure that interrupts are handled properly, you must write your procedure so that it explicitly disables or traps interrupts each time it's run.