Runtime Error Driving Me Nuts!

[craigachan]

I've been getting this runtime error that closes my application. I don't get this error in the full version of Access2007. I've tried error handling but can never get it to catch. I need help! Here is the code that produces the error:

I've tried it like this:

'Check to see if there is more than 1 implant placed
If Len(Me.ImpHeader) > 2 Then '
Response = MsgBox("Include All Implants Placed In Header?", vbYesNoCancel)

If Response = vbNo Then
DoCmd.OpenForm "ChartImplantTeethInHeader", , , , , acDialog
Exit Sub
End If

End If

And Like this:

'Check to see if there is more than 1 implant placed
If Len(Me.ImpHeader) > 2 Then '
Response = MsgBox("Include All Implants Placed In Header?", vbYesNoCancel)
Select Case Response
Case vbNo
DoCmd.OpenForm "ChartImplantTeethInHeader", , , , , acDialog
Exit Sub
End Select
End If


Both do the same and Error Handling won't catch it. I read about using End statements that may cause this, But I guess I don't know if this is my case or not and don't know how to write this any other way.

Any help would be appreciated.

 

[Galaxiom]

Please edit your post and place the code in a code box with proper indented formatting. It makes it much easier to read.

What is the error message?

 

[Galaxiom]

The second way will won't work properly becuse it only has a case for No.

BTW Not applicable in your situation but a case statement where the input could even remotely have the possibility of falling outside of the expected values should always include a Case Else alternative to pick up all possibilities.

If error handling won't catch it then the error handling is set up wrongly.

It is bad practice to exit a sub in the middle of the code. Use the Exit section of the procedure. Eventually you (or someone maintaining your code) might add Exit processes which will be bypassed by the direct Exit Sub in the middle of the code and cause unanticipated, potentially catastrophic misbehaviour.

 

[gemma-the-husky]

wth run time you donyt get any error handling ie the error/debug msgbox - so any error crashes the prog

so are you saying in normal mode you dont get a debug prompt?

do you know exactly where the program fails - eg in this line

If Len(Me.ImpHeader) > 2 Then

I tihnk if impheader is null, this will cause a crash.

 

[craigachan]

Thanks Gemma and Galaxiom for your input. Galaxiom, I'll try and exit procedure to see if this works. Are you saying that I have to have a case for vbYes and vbNo. I have a case for vbNo already.

Gemma, If I comment out the above code, the rest of the code works fine. Impheader always has at least 1 digit in it so I don't think it can be null. But I'll run a test to be sure. Also when I run it in normal mode, Full Version Acc2007 if that's what you mean, I can't get an error to show up. Just in runtime.

 

[Galaxiom]

The Exit procedure was really just some advice about good design practice rather than a solution to your problem. Procedures should always leave by the Exit even if that exit doesn't include any more processing.

One day someone might add a feature that required say DoCmd.SetWarnings False. They will reset warnings in the Exit procedure confident that it will be reenabled whatever the outcome of the procedure. But they won't realise you have exited in the middle of the code. Warnings remain off throughut the application with potentially catastrophic consequences.

BTW. If you are working on someone else's code it isn't a bad idea to search for these "out the window" Exits and fix them.

My reference to Select Case was also advice on good practice rather than a solution. ( I also try to think of those who Google their way here later.)
It doesn't really apply in your particular situation because there can only be three possibilities.

However in your Select Case you only have coded for No. The other selections both Yes and Cancel will do nothing. (You could just use a YesNo.) Cancel is intended for use where the user decides to return to where they were rather than continue with either the Yes or No options offered.

Where the data is more complex it is good practice to define an outcome for every possibility in a Select Case. This is done by including a line as the last case something like:

Case Else: Msgbox "Unexpected value for whatever, please contact support"

This will warn you, especially during development that something is not right with the values being fed to the Select statement.

Sometimes too, a new value may be introduced to the data and could escape processing without anyone ever knowing unless captured with the Case Else.

 

[craigachan]

Thank you both for all of your input. Your suggestions are things that us amateurs can't get anywhere else.

I found out that one of the variables was not declared properly and fixed it. Both codes work, so I have a choice now which one to use. The funny thing was that the Editor was not catching the fact that 'Response' was not declared. I find that interesting.

Anyways, I've learned a lot about my programming and will apply all of your suggestions to future work. Thanks again.

 

[petehilljnr]

It would catch it if you had "Option Explicit" at the top of your code module.

 

[craigachan]

Thank you for your thought. But I do to have Open Explicit at the top.