| Debugging, like most computer skills, involves no great secrets. In fact, all debugging is usually a matter of taking a good, hard, dispassionate look at your code. Although there are no set-in-stone techniques for solving programming problems, you can formulate a basic strategy that will get you started. When a problem occurs, the first thing you need to determine is what kind of error you're dealing with. There are four basic types: syntax errors, compile errors, runtime errors, and logic errors. Syntax Errors These errors arise from misspelled or missing keywords and incorrect punctuation. VBA catches most (but not all) of these errors when you enter your statements. Note, too, that the VBA Editor uses a red font to display any statements that contain syntax errors. Syntax errors are flagged right away by VBA, which means that you just have to read the error message and then clean up the offending statement. Unfortunately, not all of VBA's error messages are helpful. For example, one common syntax error is to forget to include a closing quotation mark in a string. When this happens, VBA reports the following unhelpful message: Expected: list separator or ) Compile Errors When you try to run a procedure, VBA takes a quick look at the code to make sure things look right. If it sees a problem (such as an If...Then statement without a corresponding End If ), it highlights the statement where the problem has occurred and displays an error message. Fixing compile errors is also usually straightforward. Read the error message and see where VBA has highlighted the code. Doing so almost always gives you enough information to fix the problem. Runtime Errors These errors occur during the execution of a procedure. They generally mean that VBA has stumbled upon a statement that it can't figure out. It might be a formula attempting to divide by zero or using a property or method with the wrong object. Runtime errors produce a dialog box such as the one shown in Figure 15.2. These error messages usually are a little more vague than the ones you see for syntax and compile errors. It often helps to see the statement where the offense has occurred. You can do this by clicking the Debug button. This activates the module and places the insertion point on the line where the error has occurred. If you still can't see the problem, you need to rerun the procedure and pause at or near the point in which the error occurs. This lets you examine the state of the program when it tries to execute the statement. These techniques are explained later in this chapter. Figure 15.2. A typical runtime error message.  Logic Errors If your code zigs instead of zags, the cause is usually a flaw in the logic of your procedure. It might be a loop that never ends or a Select Case that doesn't select anything. Logic errors are the toughest to pin down because you don't get any error messages to give you clues about what went wrong and where. To help, VBA lets you trace through a procedure one statement at a time. This allows you to watch the flow of the procedure and see if the code does what you want it to do. You can also keep an eye on the values of individual variables and properties to make sure they're behaving as expected. Again, you'll learn how to trace a procedure later in this chapter (see "Stepping Through a Procedure"). | 