Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Start a free Courses trial
to watch this video
We’ve set several breakpoints in our application, but what if we want to remove a few, or simply disable them? Luckily, Visual Studio ships with windows for managing breakpoints so we don’t have to remember where every breakpoint in our application is located.
Breakpoints Window
- Open the Breakpoints Window using the menu (Debug -> Windows -> Breakpoints) to show all the breakpoints set in the solution
- In a large application, the breakpoints window will be extremely helpful because it is the central place where breakpoints can be managed
Immediate Window
Sometimes we’ll want to create variables and call methods while debugging. We can use the Immediate Window to accomplish this.
- Open the Immediate Window via the menu (Debug > Windows > Immediate)
Call Stack Window
What if we’ve hit a breakpoint, but want to know what’s been executed previously? The Call Stack Window in Visual Studio will show us what’s been executed and will update as we step through code to different functions/methods.
- Open the Call Stack Window via the menu (Debug > Windows > Call Stack)
Bookmarks Window
While being able to navigate around our code using breakpoints is handy, you might want to be able to navigate code that you don’t necessarily want to debug. Managing enable/disable states for breakpoints you’re using simply to navigate is a bit overkill. Once again, Visual Studio has a mechanism that will allow us to set places just for the purpose of navigation called Bookmarks.
- Open the Bookmark Window via the menu (View -> Bookmark Window)
- The Bookmarks Window will allow you to set bookmarks on lines of code that you want to revisit later. You can also organize the bookmarks into virtual folders to keep track of the different areas they represent.
We've set several breakpoints in our application, but 0:00 what if we want to remove a few or simply disable them. 0:03 The Breakpoints window provides a central place to manage all of our breakpoints. 0:07 This is super helpful in a large project. 0:11 To open the breakpoints window, click Debug>Window and then Breakpoints. 0:13 Notice, that it has all of our breakpoints listed here. 0:19 From here, we're able to quickly navigate to every breakpoint location in our code 0:23 simply by double clicking the rows. 0:27 You might wanna keep a breakpoint by temporarily avoid hitting it when 0:29 debugging. 0:32 From this window, 0:33 you can use the checkboxes beside the breakpoints to enable or disable them. 0:34 Let's disable a bunch of these breakpoints now. 0:38 We can also create a special type of breakpoint from here called 0:44 a Function Breakpoint by clicking on the New button. 0:47 This Data Breakpoint type is only available when debugging C++ code 0:51 right now but we can create function breakpoints. 0:55 From here, we enter the name of the function. 0:58 This will cause the debugger to pause before entering any method named Prompt. 1:01 This is very helpful when debugging methods that might be overridden in 1:06 subclasses or when we want to break on all implementations of an interface. 1:10 This will cause the debugger to pause before running the base method or 1:14 any overridden methods. 1:18 I'll disable this right now. 1:20 Finally, I want to mention that from the Breakpoints window, you can export and 1:24 import sets of breakpoints. 1:28 That's the purpose of these two buttons up here. 1:30 This is one way to tell your fellow developers where exactly in the code 1:33 an issue can be found or if you need to switch to debugging an unrelated issue, 1:37 you can save off the breakpoints and then come back to them at a later time. 1:42 When a breakpoint is hit, we often want to know how the program got there. 1:46 That's the purpose of the Call Stack window. 1:51 This is one of the windows that's usually open when Visual Studio is in debug mode. 1:53 You can also open it by going to the debug windows menu. 1:58 Lets run the debugger until we hit one of these breakpoints here where we're setting 2:02 the song.name property. 2:05 We can look here on the Call Stack to see that we've stopped where we're setting 2:12 the Name property. 2:16 We can see that this is being called from within the AddSong method, 2:18 which in turn was called from the Main method. 2:23 To go to any one of these methods, we can just double click on them. 2:27 There are a bunch of options here when we right click on the call stack. 2:30 Here, we can change what is shown. 2:34 We can show or hide which assembly the method resides in or 2:36 we can also pick whether or not to show the parameter types, names and values. 2:39 This is helpful because the Call Stack can get quite full when everything is shown. 2:44 Notice that nothing calls the Main method or does it? 2:49 This is only showing code that is in this Visual Studio project. 2:53 We can see what calls the Main method by right-clicking and 2:58 clicking Show External Code. 3:01 You might be surprised to see that there are so 3:08 many things involved with starting your program. 3:10 Calling Main isn't the only place we run into external code. 3:13 We see it all the time when using code that's calling our code. 3:16 Such as in web applications or other types of software frameworks. 3:20 It's sometimes helpful to take a deeper look into the Call Stack to understand how 3:24 things are working. 3:28
You need to sign up for Treehouse in order to download course files.
Sign up