Access VBA: Suppressed Runtime Errors

Question

While I'm developing my MS Access application, I open it with shift click. When an Error occurs, that is not trapped (by ON ERROR ...), a message box pops up informing me about the error. This is a good thing.

When a user open my application, he does't shift click, and an appropriate Start Form opens. However, now untrapped Errors don't show up, the application behaves as if the user clicked the Stop Button on the message box. I don't want this behaviour.

Is there an option / property / variable that provides the same behaviour in the production code (preferably even when the application id converted to an mde) as in development, i.e. show a message box for every untrapped error? Or is it neccessary to trap errors in every single event routine and pop up a message box by program?

Answer 1

It turns out, this is a side effect of setting the AllowSpecialKeys property to False. This can be done programmatically, but I did it in the menu under Tools > StartUp.

Since this property allows the user to open the code editor, it kind of makes sense, but the relationship of the phenomen described to this option was puzzling for me.

Does this mean, that if I want to hide my code, I need to write all those error handlers? Or is there one central place (like a main method in Java) where I can invoke an error handler. Alternatively, could I allow specical keys and just protect the code with a keyword?

Answer 2

You can create your own error handler and add it to all procs, subs and functions. You have this very nice MZ Tools VBA add-on that allows you many thing such as adding line numbers to your code, "preprogramming" your error label, etc.

If you are smart enough, you'll be able to use this add-on to generate a standard "error management" code displaying things such as err.number, err.description, and the undocument erl value, which is the number of the line where the error occured (you must first have your lines numbered before being able to get this value).

EDIT: I just opened this question on a similar subject.

Answer 3

As alluded to, MZ-Tools 3.0 is a great tool to aid in quickly adding error handlers. Also remember that errors which occur in procedures without error handlers "bubble up" to the last-invoked On Error statement. (And if no statement exists you get the little gray debug box.) The net effect of this, is that you can do minimal error handling by simply adding error handlers only to those procedures which are Public (or Friend) or called by event. This will make sure you always have at least 1 "top level" error handler invoked. If you want to add special handling to your private procedures after that feel free. If not, when an error occurs in them they will "bubble up" to the top level error handler.