avoiding propogating error messages

  • Thread starter Thread starter Christopher Glaeser
  • Start date Start date
C

Christopher Glaeser

Consider the following code sample, and in particular, the assignment
Me.Dirty = False.
------------------------------------------
Private Sub cmdPreviewFax_Click()
On Error GoTo Err_cmdPreviewFax_Click

Dim stDocName As String

If Me.cmbPrinted = 2 Then Me.cmbPrinted = 1
If Me.Dirty Then Me.Dirty = False
stDocName = "rptFacsimile"
DoCmd.OpenReport stDocName, acPreview

Exit_cmdPreviewFax_Click:
Exit Sub

Err_cmdPreviewFax_Click:
MsgBox Err.Description
Resume Exit_cmdPreviewFax_Click

End Sub
-------------------------------------------------

Some of the fields of this form are required, and if the user did not enter
a value, then a dialog box with an error message will be generated when
"Me.Dirty = False" is executed, telling the user to enter values for these
fields. At that point, I just want to resume control back to the form.
What is the recommended technique to avoid subsequent error messages from
being generated? If I delete the MsgBox statement entirely, then other
possible error messages will not be generated. How do I generate exactly
one error message with the most relevant information?

Best,
Christopher
 
In your error handler (last part of the procedure), include a Select Case
that examines the error number.

Example:

Err_cmdPreviewFax_Click:
Select Case Err.Number
Case 3314, 2101, 2115
MsgBox "Too incomplete to save"
Case Else
MsgBox "Error " & Err.Number & ": " & Err.Description
End Select
Resume Exit_cmdPreviewFax_Click
End Sub
 
In your error handler (last part of the procedure), include a Select Case
that examines the error number.
Click to expand...

Many thanks for the quick response. One more quick question. What if I
detect an error with code I write? After the dialog box error message is
generated, do I then throw an error that will then be caught later by this
select case?

Best,
Christopher
 
I think you are asking about not knowing which line caused an error while
you are trying to debug your application?

If so, you can comment out the error handler at the beginning by adding a
single quote mark, i.e.:
'On Error Goto ...
Then, when everything is debugged, do a global search'n'replace for:
'On Error Goto
replacing with:
On Error Goto
 
I think you are asking about not knowing which line caused an error while
you are trying to debug your application?
Click to expand...

My fault, my question was not clear. Here is a better explanation. I have
code for two events, one on a command bottun to print a report and one on
BeforeUpdate to ensure a field has a valid entry. Here is the code for the
two events.

Private Sub PrintWorkOrder_Click()
On Error GoTo Err_PrintWorkOrder_Click
Dim stDocName As String
If Me.Dirty Then Me.Dirty = False
stDocName = "rptWorkOrders"
DoCmd.OpenReport stDocName, acNormal
Exit_PrintWorkOrder_Click:
Exit Sub
Err_PrintWorkOrder_Click:
MsgBox Err.Description
Resume Exit_PrintWorkOrder_Click
End Sub

Private Sub Form_BeforeUpdate(Cancel As Integer)
If Me.WorkOrderTypeID = 0 Then
' warn the user
MsgBox "Enter a valid WorkOrder Type"
' send the user back to the correct control
Me.WorkOrderTypeID.SetFocus
' and prevent the form going ahead with the update
Cancel = True
End If
End Sub

Before the report can be printed, a form must be saved via the assignment
Me.Dirty = False. This triggers the BeforeUpdate event. When there is an
invalid entry in the form, BeforeUpdate will generate a dialog box with
error message and cancel the save. Now control will return to the Click
event. What is the standard practice to tell the Click event that there is
an error and to cancel the print, but that an error message has already been
generated and to exit without generating a second error message?

Best,
Christopher
 
You need to handle that yourself:

Err_cmdPreviewFax_Click:
Select Case Err.Number
Case 3314, 2101, 2115
'Do nothing
Case Else
MsgBox "Error " & Err.Number & ": " & Err.Description
End Select
Resume Exit_cmdPreviewFax_Click
End Sub
 
I have issued my own descriptive error messsages in the BeforeUpdate event
and then exited. Now, I'm trying to catch these errors in the
PrintCommandButton event to avoid a duplicate chain of errors, but I'm not
sure where or why error 3709 is being issued. Any clues on how to debug
this?

Best,
Christopher
 
Back
Top