somthing like option three would work fr the entire application?
It is somewhat "procedure specific" but in another way it is global.
The EnableCancelKey property persists for the entire Excel
application, even as code execution goes from one procedure to
another, and even when code execution terminates. So, you can set the
property once and it will remain at that value unless it is explicitly
changed elsewhere. However, most error handling is procedure
specific, and so you'd need to trap the error within each procedure or
at least in the initial procedure that calls others.
When an error occurs in any procedure, VBA looks in that procedure to
see how the error should be dealt with (GoTo, Resume, Resume Next,
etc). If no such directive exists in the procedure in which the error
was thrown, VBA searches up the call stack (the procedure that threw
the error, then the procedure that called that procedure, then the
procedure that called the caller and so on up the chain) until it
finds an On Error directive. If an error directive is found in an
upstream procedure, that error handler is invoked. If no On Error
directive is found, you get the standard VBA run time error dialog.
VBA's error handling is rather primitive, and it can be very tricky
and clunky to create a global error handler, because you would need to
test the error type and figure out where to resume or quit. Unlike
VBNET, which has a global Last Chance Exception Hander, errors in VBA
generally need to be dealt with within the procedure in which they
arise.
Of course, if you use Application.EnableCancelKey = xlDisabled, this
blocks the Break key in all procedures, not just the procedure in
which the value is set, and can be useful in that sense. However, be
SURE your code is correct, because you can't break out of bad code
when the break is disabled.
Cordially,
Chip Pearson
Microsoft Most Valuable Professional
Excel Product Group
Pearson Software Consulting, LLC
www.cpearson.com
(email on web site)