- Enabling Script Debugging
- Adding Debugger Statements
- Using IntelliSense
- Managing Breakpoints and Tracepoints
- Using Watches
- Additional Features to Explore
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Managing Breakpoints and Tracepoints
The Visual Studio IDE's support for breakpoints and tracepoints also extends to script debugging. Realistically, the techniques are the same whether you're using Visual Studio's debugging tools to debug JavaScript, C#, or Visual Basic. If you're already an expert with breakpoints and tracepoints, you probably won't learn much in the rest of this article that's JavaScript-specific. However, I like to think that some of the "how to" advice I provide will help Windows developers with any debugging task they encounter, using any language. Not everyone knows about all of these little hideaway features, so follow along and enjoy.
To insert a breakpoint, click in the right column adjacent to the line where you want the breakpoint. You can also insert breakpoints and tracepoints by right-clicking a line of code and selecting Breakpoint > Insert Breakpoint or Breakpoint > Insert Tracepoint from the context menu.
Managing Breakpoints
Breakpoints are fully manageable from the IDE. You can display the Breakpoints window by selecting Debug > Window > Breakpoints or by right-clicking the dot that appears in the left margin next to a breakpoint in the code.
The toolbar in the Breakpoints window lets you insert new breakpoints, delete a single breakpoint, delete all breakpoints, and so on. Right-clicking an individual breakpoint displays a number of options, and a few bear attention:
- Location. Displays the File Breakpoint dialog box, which displays (and allows you to change) the file path, line, and character where the breakpoint is located. You can also choose to permit the source code to differ from the original version (in case you've made some small changes to the code, but you still want to use the breakpoint as originally set).
- Condition. Supports adding a conditional breakpoint as a Boolean expression; you can select (break) when the condition is true or the condition has changed.
- Hit Count. Breaks when the breakpoint is hit a number of times. Select an option from a drop-down list to specify breaking on a multiple of a number of hits, or when the count is greater than or equal to a value you set.
- Filter. This advanced option supports breaking based on certain processes, threads, or the machine name. The When Hit option is actually the same as inserting a Tracepoint (see the next section).
Managing Tracepoints
Tracepoints are helpful when you want to track the path your code is following, but without actually breaking it. Use this feature if you need to backtrack and figure out what the code was doing, but without the laborious step-step-step that happens with breakpoints.
Tracepoint options include printing a message to the debug window, using environment constants such as $FUNCTION or $TID (thread ID), running a macro, and optionally continuing the execution of the code. The drop-down list that appears when you select Run contains a huge assortment of canned macros that you can elect to run each time the tracepoint is hit.
You also can write a custom Microsoft Visual Studio macros IDE, in which case your custom macros will also be available in the "Run a macro" list of the When Breakpoint Is Hit dialog (a.k.a. the Tracepoint dialog). The code in Listing 2 shows a very simple custom macro of the type that you might use (think "Hello World" quality).
Listing 2—A simple macro.
Imports System
Imports EnvDTE
Imports EnvDTE80
Imports EnvDTE90
Imports System.Diagnostics
Public Module Module1
Sub DisplayWindow()
MsgBox("Tracepoint Hit")
End Sub
End Module
The macro language is VBA (essentially Visual Basic). But don't be fooled; macros can be extraordinarily powerful. The Microsoft Visual Studio IDE is fully extensible, and a substantial part of the IDE is accessible through namespaces such as EnvDTE, EnvDTE80, EnvDTE90, and so on. (The numbers at the end of the EnvDTE namespaces represent extensions to the environment namespaces based on the environment's version number.)