Error Handler - am I asking to much?

Here's what I want from my VBA error handler:

I want it to read the values of all of the controls on my form.

I want it to respond to any error that occurs while running the form.

I do not want to retype the error handler for each control on the form. Not
even just to reference a function.

Now that I've enumerated these 3 requirements, my own efforts have suggested
to me that it cannot be done. I tried creating the error handler in the
module rather than the form but that did not work because at that point the
form has not yet been defined so it will not let me reference the controls
therein. I tried creating the error handler in the Initialize function, but
that only works as long as the form is initializing.

I guess what I really want is for someone to prove me wrong and tell me how
this can be done, but lacking that I would appreciate it if someone would
confirm for me that I'm right.

Thank you very much.

Randy Richardson

 

Each object should handle its own errors. If I wrote a piece of code, would you want to be responsible for it? Then why make some module responsible for handling the errors of some other module? Further, it complicates debugging. If a procedure has no error trapping and an error occurs within it, then the unhandled error bubbles up to the calling procedure. This could reaction could chain for several nested levels until something handles it. Eventually you might get some generic message that's not very helpful in determining where the problem lies.

--
----
Ed
----
Here's what I want from my VBA error handler:

I want it to read the values of all of the controls on my form.

I want it to respond to any error that occurs while running the form.

I do not want to retype the error handler for each control on the form. Not
even just to reference a function.

Now that I've enumerated these 3 requirements, my own efforts have suggested
to me that it cannot be done. I tried creating the error handler in the
module rather than the form but that did not work because at that point the
form has not yet been defined so it will not let me reference the controls
therein. I tried creating the error handler in the Initialize function, but
that only works as long as the form is initializing.

I guess what I really want is for someone to prove me wrong and tell me how
this can be done, but lacking that I would appreciate it if someone would
confirm for me that I'm right.

Thank you very much.

Randy Richardson

 

Since my mis-spelling of the word "too" in the subject heading makes me look
like an idiot, may I here defend myself my saying it was a typo rather than
a reflection of my cognitive function?

No?

Oh wel.

 

Thank you for your response, Ed, for an explanation of your philosophy.

Generally, I'm more interested in what I *can* do than in what I *should*
do. My purpose for error trapping has nothing to do with debugging (it's
easier without an error handler anyway) and the error handler will be
identical for each of several dozens of event handlers. And, just to set
the record straight, I'm only talking about one module.

If no one sets me straight on my opinion that what I want to do can not be
done, I'll just have to assume that my conclusion is correct.

Thanks again,

-Randy

Each object should handle its own errors. If I wrote a piece of code, would
you want to be responsible for it? Then why make some module responsible for
handling the errors of some other module? Further, it complicates debugging.
If a procedure has no error trapping and an error occurs within it, then the
unhandled error bubbles up to the calling procedure. This could reaction
could chain for several nested levels until something handles it. Eventually
you might get some generic message that's not very helpful in determining
where the problem lies.

 

After rereading your previous post, it seems like what you want is not really what we would think of as an error handler. You want data validation. You can handle that in a control's OnChange event. The form does not have such an event, but you could handle validation in the form's OK button, i.e. when they dismiss the form, validate data. If all is ok, close the form and proceed or pop a MsgBox and cancel the action, making them enter correct data.

--
----
Ed
----
Thank you for your response, Ed, for an explanation of your philosophy.

Generally, I'm more interested in what I *can* do than in what I *should*
do. My purpose for error trapping has nothing to do with debugging (it's
easier without an error handler anyway) and the error handler will be
identical for each of several dozens of event handlers. And, just to set
the record straight, I'm only talking about one module.

If no one sets me straight on my opinion that what I want to do can not be
done, I'll just have to assume that my conclusion is correct.

Thanks again,

-Randy

Each object should handle its own errors. If I wrote a piece of code, would
you want to be responsible for it? Then why make some module responsible for
handling the errors of some other module? Further, it complicates debugging.
If a procedure has no error trapping and an error occurs within it, then the
unhandled error bubbles up to the calling procedure. This could reaction
could chain for several nested levels until something handles it. Eventually
you might get some generic message that's not very helpful in determining
where the problem lies.

 

It really is an error handler that I need, but it's for preserving hours of
dialog box entry labor, not for debugging. For any unanticipated error,
usually a coding error. I've found an approximate method for doing what I
wanted, though. More work than I wanted to do, but it looks like it will
work.

Debugging is important, but first I have to be sure the user doesn't lose
all his work.

All event-handling functions are going to run through an EventHandler
function that will define the error handler before continuing.

Thanks.

-Randy

After rereading your previous post, it seems like what you want is not
really what we would think of as an error handler. You want data validation.
You can handle that in a control's OnChange event. The form does not have
such an event, but you could handle validation in the form's OK button, i.e.
when they dismiss the form, validate data. If all is ok, close the form and
proceed or pop a MsgBox and cancel the action, making them enter correct
data.

 

hours of dialog box entry labor,

yikes !! I would try to find or create two routines "SaveForm" and
"LoadForm" that would loop through the form's controls and save their
current values to a temporary file. The user pushes a button on the form to
save the control values, and then when the user pushes the "LoadForm" button
it just resets the controls' values to match the file, maybe with an "Are
you sure?" prompt for accidental button clicks.

Just my thoughts... at least then when they lose hours of work you can say
"why didn't you save?"

James

 

I meant to add...

To me, this seems more do-able than trying to write crash-proof code, since
ACAD is not even crash-proof, nor Windows.

I'd help you with this part since it's something I wouldn't mind having in
my back pocket.

James

 

Thanks, James. I already have a way of saving if the user thinks of it,
similar to what you've described. I just want to have it saved in the event
of a crash, too. Although I really do try to write crash-proof code, the
error handler is the safety net for when it's not.

I got it under control now.

Thanks again.

-Randy

 

I think it could be done using late binding. Something like:

Public Sub ShowForm(byval f as Form)
Dim c as Control

On Error Goto ErrorHandle
f.Show vbModal
Exit Sub

ErrorHandle:
Resume Cleanup

CleanUp:
' Ignore all errors here since we can't deal with them anyways.
On Error Resume Next
For Each c In f.Controls
Select Case TypeName(c)
Case "TextBox"
Debug.Print c.Text
Case "CheckBox"
Debug.Print c.Value
End Select
Loop
End Sub

Now when you show the form do so like:
Call ShowForm(frmMyForm)

And all errors not trapped internally by the form will be caught by
the ShowForm routine and it will iterate though all controls on the
form and will determine their type and print their value. Obviously
only textobx and checkbox are handled above.

-Tim

 

I'm sure "Oh wel" was deliberate, but I wonder if "my saying" was.

;-)

Wayne Ivory
IT Analyst Programmer
Wespine Industries Pty Ltd

 

Ha! I noticed that almost immediately (after I posted it of course) but
thought that all you generous people would overlook it.

It definitely was another typo, but at least it looks like a typo rather
than a symptom of stupidity. Too me, anyway.

-R

 

Just to follow up, for any previous-post searchers in the future:

I found that the simplest method was to create a function to be the error
handler, and to define the error handler to go to that function in each
event-handling function. So I had to repeat the same code 140 times because
I have 140 event-handling functions. I guessed low in a previous post.

Other methods that I or others came up with (some came by email) either
didn't work or were even more work than this.

At least it's done now. Thank goodness for Control-V.

-Randy

 

FYI, a company called FMS
(http://www.fmsinc.com/products/CodeTools/index.html) makes a product called
Total Visual CodeTools that will automatically insert error handling code in
any procedures that lack them. It works off a customizable template, so you
can control the code it generates. I've only used in it Access development
so far, but it's also supposed to work in VB and other VBA environments.

Dave

 

Just a question to clarify it for myself.

The proposal that you are asking is something along the lines of a
public event that is triggered by any error that is generated within
the whole project?

E.G. There is no declaration of any error handler in any functions,
etc but once the err object raises any error it runs your error
handling code (similar to the way VBA handles errors when no error
handling is present - the default msgbox).

Anthony