Breakpoints

One of the easiest breakpoints to set is the run-to-cursor breakpoint. Suppose that you suspect that the Visual Basic Scheduler doesn't test for a leap year properly. You can click the first statement in the standard module's IsLeapYear() function and select Run To Cursor from the Debug menu. The program starts up as usual but halts at the breakpoint and highlights the line.

The program isn't halted permanently. Up to this point, all the program variables have been initialized, the code has run, and its effects are available. If output occurred before the cursor's location (none did in this example of the Visual Basic Scheduler), you would have seen the output, such as the Form window, appear on-screen as usual. The program, as indicated by Visual Basic's title bar, is in its break state reached due to the breakpoint. The yellow highlight is the line where the cursor rested when you chose Run To Cursor from the Debug menu.

Here is the procedure where this particular example stops:

Public Function IsLeapYear(iYear As Integer) As Boolean
    If iYear Mod 4 = 0 Then
        IsLeapYear = True
    Else
        IsLeapYear = False
    End If
End Function

Perhaps the leap year doesn't work because it receives an incorrect year value from whatever procedure passed iYear to the function. Therefore, you can look at the current value of iYear to see whether it contains what you expect.

Looking at a variable's contents has never been easier. As Figure 36.4 shows, assuming that the current year is 1997, all you need to do to see the value of iYear is rest your mouse cursor over the variable.

FIG. 36.4

Visual Basic pops up with the variable's value.

Suppose that the year is not 1997. You've just found that the leap year calculation is okay and you have to search back further in the code to see where iYear got its value. If the variable has a correct value, however, you might want to run the program a little further.