Navigation button error trapping (1 Viewer)

[Milothicus]

I've made my own record navigation buttons on a form. they work fine, except when i get to the first record. if i click 'previous' then the 2105 error pops up "you can't go to specified record". the buttons were created through the wizard, and have error trapping in them. for some reason, it never actually goes to the error handler. the error message comes up, i press debug, and the 'DoCmd.GoToRecord , , acPrevious' is highlighted.

any ideas why the error trapping isn't working? here's the code:

Private Sub cmdPrevJob_Click()
Dim x As Variant
On Error GoTo Err_cmdPrevJob_Click
    DoCmd.GoToRecord , , acPrevious
Exit_cmdPrevJob_Click:
    Exit Sub
Err_cmdPrevJob_Click:
    If Err.Number = 2105 Then stop
    MsgBox Err.Description
    Resume Exit_cmdPrevJob_Click
End Sub

 

[MStef]

It's normal. it happend only when the first record is
reached. I tryd it and I have found it have reached a
error handler.

 

[Milothicus]

it's normal for it not to enter the error handler?

 

[Mile-O]

Smarter Navigation Buttons.

No need for error checking on control's events. Use the Form_Current event and you can make use of the form's RecordsetClone property to evaluate the location in the recordset and enable/disable the fields accordingly.

For the bit that says [YourFieldHere] list the recordset's Primary Key. Ensure your command buttons are called cmdFirst, cmdPrevious, cmdNext, and cmdLast.

 

[ghudson]

Your code has a few prolems. Try this and then compare what I did right with what you were doing wrong.

Private Sub cmdPrevJob_Click()
On Error GoTo Err_cmdPrevJob_Click
    
    DoCmd.GoToRecord , , acPrevious
    
Exit_cmdPrevJob_Click:
    Exit Sub
    
Err_cmdPrevJob_Click:
    If Err.Number = 2105 Then
        Beep 'just to hear the error ;-)
        Resume Exit_cmdPrevJob_Click
    Else
        MsgBox Err.Number & " - " & Err.Description
        Resume Exit_cmdPrevJob_Click
    End If
    
End Sub

 

[Milothicus]

Your code has a few prolems. Try this and then compare what I did right with what you were doing wrong.

Private Sub cmdPrevJob_Click()
On Error GoTo Err_cmdPrevJob_Click
    
    DoCmd.GoToRecord , , acPrevious
    
Exit_cmdPrevJob_Click:
    Exit Sub
    
Err_cmdPrevJob_Click:
    If Err.Number = 2105 Then
        Beep 'just to hear the error ;-)
        Resume Exit_cmdPrevJob_Click
    Else
        MsgBox Err.Number & " - " & Err.Description
        Resume Exit_cmdPrevJob_Click
    End If
   
End Sub

I think you missed the point...

you just changed what's in the error handler. it doesn't matter what's in there, since it never seems to reach it. my code was just for debugging to see if it was even entering the errorhandler, which it wasn't.

the error popup is the access-created form, not my msgbox...

SJ, i'll take a look at your link today. thanks...

 

[Mile-O]

If you can get it to work then there's also this - a subform you place on your form and it "connects" with the parent's RecordSource allowing navigation with smarter buttons.

 

[Oldsoftboss]

This is what I put in the Form_Current event:

Me.RecordsetClone.MoveLast

Me.cmdPrevious.Enabled = Me.CurrentRecord > 1
Me.cmdNext.Enabled = Me.RecordsetClone.RecordCount > Me.CurrentRecord

Obviously my navigation buttons are called cmdPrevious and cmdNext.

Another way to handle the error is:

Err_cmdPrevJob_Click:
If Err.Number <> 2105 Then
MsgBox Err.Description
End If
Resume Exit_cmdPrevJob_Click

 

[ghudson]

Your use of the Stop command is part of your problem.

If Err.Number = 2105 Then stop

Your error handler code does not work. The error handler code I posted above will correcty trap the 2105 error.

 

[Milothicus]

Your use of the Stop command is part of your problem.

If Err.Number = 2105 Then stop

Your error handler code does not work. The error handler code I posted above will correcty trap the 2105 error.

you still don't understand. it never had a chance to evaluate that 'if' statement.

the errror window pops up without it ever entering the errorhandler.

the code would do exactly what i wanted it to do, if it had a chance to run.

 

[Tim L]

Milothicus;

are you saying that even when you tried the code posted by ghudson that that doesn't work either? I tried your code and by using STOP the execution drops out immediately and automatically goes to the VBA editor with STOP highlighted, without even offering the chance to debug, as it does for you.

Is there possibly a module with some code that is over-riding the normal error handling procedure? Or, perhaps your Access installation has been corrupted or there's a library that isn't correctly installed? If either of the latter two I think that I'd go for a delete-reinstall, or repair, of Access to see if that will clear up the problem.

Tim

 

[Milothicus]

Actually, i noticed in another module, my error trapping wasn't working either:

http://www.access-programmers.co.uk/forums/showthread.php?t=87342

i definitely need to check my installation. i never thought of code outside the sub affecting my error trapping. i'll check that too. thanks.

 

[ghudson]

You can easily force an error. Below is what I use to test my error message.

Public Function TestErrorMessage()
On Error GoTo Err_TestErrorMessage
 
    Kill ("X:\XYZ.123") 'testing error function for this file does not exist!
 
Exit_TestErrorMessage:
    Exit Function
 
Err_TestErrorMessage:
    MsgBox Err.Number & " - " & Err.Description
    Resume Exit_TestErrorMessage
 
End Function

You can also force an error number like this...

Public Function TestErrorMessage()
On Error GoTo Err_TestErrorMessage
 
    Error 2501
 
Exit_TestErrorMessage:
    Exit Function
 
Err_TestErrorMessage:
    MsgBox Err.Number & " - " & Err.Description
    Resume Exit_TestErrorMessage
 
End Function

 

[Milothicus]

found the problem... at some point i guess i decided to play with the options... (famous last words)...

there's a little thing called 'break on all errors' that i seem to have selected, as opposed to the wiser, more relevant 'break on unhandled errors' which i'm pretty sure is the default...

thanks for all the help, and i apologize for being an idiot.

I'll get my coat...

 

[ghudson]

Yes, Break on Unhandled Errors is the option you want checked.

Here is what the help files states about the three options...

Error Trapping

Determines how errors are handled in the Visual Basic development environment. Setting this option affects all instances of Visual Basic started after you change the setting.

Break on All Errors — Any error causes the project to enter break mode, whether or not an error handler is active and whether or not the code is in a class module.

Break in Class Module — Any unhandled error produced in a class module causes the project to enter break mode at the line of code in the class module which produced the error.

Break on Unhandled Errors — If an error handler is active, the error is trapped without entering break mode. If there is no active error handler, the error causes the project to enter break mode. An unhandled error in a class module, however, causes the project to enter break mode on the line of code that invoked the offending procedure of the class.

I guess you might want to play with these if you had a debugging issue but I have yet to feel the need.