Debugging
This section covers IDE-related tips
on debugging, including Tools Options settings and tool windows found only while
debugging. This section also explores how to debug multiple projects.
Tracepoints
On a given line of code where you want to
log the value of a variable, you can use the old-fashioned way of doing a Console.WriteLine() or a PrintF(). But in Visual Studio
2008, there's a new feature called Tracepoints that allows you to print out
these debug statements without modifying your code. Hence, there's no having to
go back and delete code prior to a check-in or unwanted debugging info getting
released into deployment.
Tip 7.14: You can use tracepoints
to log PrintF() or Console.WriteLine() info without editing your code
Right-click in the editor
wherever you want to insert a tracepoint, select Breakpoint, and then select
Insert Tracepoint.
This brings up the tracepoint
dialog box, which gives you some helpful default settings. But for this example,
the really helpful default is in the descriptive text for logging the contents
of a variable.
You'll notice that the editor shows a diamond instead of a
circle.
And the tracepoints are logged in the Output window's Debug
pane.
Breakpoints
Where
would debugging be without breakpoints? This section covers the basics of
breakpoints, including the various ways to set breakpoints and how to set
conditions on them.
Tip 7.15: You can set a breakpoint
by clicking the indicator margin
I'm very big into starting off with the
basics, just in case someone reading this didn't know about this
tip. |
You can set a breakpoint on any
applicable line by clicking the indicator margin, as illustrated here.
Clicking here inserts the breakpoint, as shown next.
Tip 7.16: You can press F9 to set a
breakpoint on the current line
The command Debug.ToggleBreakpoint sets (or
deletes) the breakpoint on the current line, in case you don't want to take your
hands off the keyboard.
Tip 7.17: You can use Ctrl+F9 to
enable or disable a breakpoint
I didn't see this command under the
Debug menu. So, in case you want to use the keyboard to enable or disable a
breakpoint, you can press Ctrl+F9, which is bound to the command Debug.EnabledBreakpoint. Note that
you won't find a Debug.DisableBreakpoint because this is handled by the enabled command.
A disabled breakpoint still gets
saved in your Breakpoints window, even though it will not get hit during
debugging.
Tip 7.18: You can set conditional
breakpoints
When you want to break only under
certain conditions, you can right-click a breakpoint red circle (or go to the
Breakpoints window and bring up the context menu on a given breakpoint) and
select Condition to bring up the dialog box for conditional breakpoints.
You're given two options: break only
when the specified expression is true, or break only when the specified value
has changed. For this example, because I'm in a for loop, I'll break when the value of i is greater than 5.
You'll notice that the breakpoint circle
now has a red plus on it to indicate it is conditional.
Tip 7.19: You can use breakpoint
filters to break the right process
Conditional breakpoints are for
breaking at the expression level, when a particular condition is true, like
x = 5. But what if you
have multiple instances of the same app running? How do you set to break the
instance you want?
The answer is breakpoint filters.
Go to Tools–Options–Debugging–General,
and you'll see the option Enable Breakpoint Filters.
Set a breakpoint and right-click to
bring up the context menu.
In the Breakpoint Filter dialog
box, you can specify when to break. The next image shows breaking a process by
its process ID.
And you can verify the breakpoint
filter in the Breakpoints window under the Filter column.
Tip 7.20: You can press Ctrl+B to
set a breakpoint at the desired function
In case you want to set a
breakpoint at a given function, and not at the current line, you don't have to
search for the function name and then hit F9. Instead, you can press Ctrl+B to
run the Break At Function command.
This command brings up the New Breakpoint window.
Here you can type the name of the
function you want to set a new breakpoint at.
Tip 7.21: You can press Ctrl+Alt+B
to open the Breakpoints window
Under Debug–Windows, you'll find the Breakpoints window.
The keyboard shortcut is Ctrl+Alt+B,
which is bound to the command Debug.Breakpoints.
Tip 7.22: You can press
Ctrl+Shift+F9 to delete all breakpoints
You can press Ctrl+Shift+F9, bound to Debug.DeleteAllBreakpoints, to
delete all the breakpoints you've created in your solution. The command is found
under the Debug menu.
The option is also found on the
Breakpoints window in the toolbar.
Tip 7.23: You can disable the
warning message before you delete all breakpoints
The previous tip talked about how to
delete all breakpoints. If you are following along at home, you have encountered
the warning message that appears when you attempt to do this.
If you find it annoying, you can
disable it by going to Tools–Options–Debugging–General and unchecking the Ask
Before Deleting All Breakpoints option.
DataTips
DataTips are very similar to the Watch window. (See the
Watch window tips that appear later in the chapter.) However, unlike the Watch
window, where you have to navigate to a tool window, DataTips allow you to keep
your focus in the editor.
Tip 7.24: You can use DataTips to
edit a variable's content
Whenever you are debugging and want
to change the contents of a variable, you can drag the variable into the Watch
window. But you can also use DataTips to change the variable without leaving the
editor.
Hover over a variable when you have
hit a breakpoint. You'll notice a glorified ToolTip appear. This is actually a
DataTip. You can click the value of the variable to go into an edit mode. Change
the contents of the variable, and press Enter to commit.
If you have the Autos window open,
you'll notice the color change, implying the commit was successful.
Multiple Projects
If you are using only one project per
solution, this section may not have too much significance for you. But if you
have multiple projects, you can select which ones you want started under the
debugger.
Tip 7.25: How to select the startup
project from the Solution Explorer
There are two
ways you can select a project as the startup project when you have more than one
project in your solution.
The first way is via the Solution
Property pages. Right-click the solution node in the Solution Explorer, and
under Common Properties–Startup Project, you can choose Single Startup Project.
Now you can select which project you want.
The second way is to right-click the
project and select the Set As StartUp Project command from the context menu.
The startup project appears in bold in
the Solution Explorer.
Tip 7.26: You can start debugging
multiple projects
This tip
marked the one-year anniversary of doing the "Tip of the Day" series. I consider
July 27, 2007, as the kick-off date of "Tip of the Day." Wow, what a difference
a post a day makes!
Thanks to everyone who has been reading
the series. It's been an extremely rewarding experience to see these tips help
people. And I also want to express my thanks for all the motivation you have
given me to continue writing. It takes me on the average 20 to 30 minutes to
decide what tip to write, to capture the screen shots, and to add it to the
queue. I refuse to do the math to see just how many puppies I could have
potty-trained by now. I just don't want to know.
=D |
Right-click the solution in the
Solution Explorer, and select Properties. Go to the Common Properties–Startup
Project page. (It's the first page in the dialog box.)
You'll see three option buttons:
Current Selection This option selects whichever project had the
inactive selection (that is, whichever project was selected previously) when you
went to the Solution Property Pages.
Single Startup Project Usually this is the first project you had in the
solution, or it's the project that you manually set as the startup
project.
Multiple Startup Projects And there was great joy! When this option is enabled, you
can pick and choose which projects to start (and make sure you choose Start and
not Start Without Debugging).
And using the preceding example, when I
hit F5, I get the following.
Tip 7.27: How to have all processes
break when one process breaks
In Tools–Options–Debugging–General, there's the option
Break All Processes When One Process Breaks.
Let's say you are debugging
multiple projects, and you want to configure what happens when one process
breaks.
For example, let's say I have two console
applications running in an infinite loop. On the second console application, I
break the process. If I have checked the Break All Processes When One Process
Breaks check box, the first console application will break also.
And, of course, you can uncheck this
option to have the first console application keep going.
Compiling and Debugging
Windows
This section explores the various
tool windows you can use while compiling and debugging your code, including the
Error List view, Watch window, and Immediate Window.
Error List
The Error List does exactly as its
name suggests. It lists all the errors in your solution, alongside any warnings
and messages.
Tip 7.28: You can use
Ctrl+Shift+F12 to view the next error listed in the Error List
The keyboard binding is Ctrl+Shift+F12,
and the command is View.NextError. I'm a little
surprised that there isn't a default keyboard shortcut for View.PreviousError. But you can always add one
yourself.
And, of course, the status bar tries to
be helpful by showing you the error you have navigated to. =)
Tip 7.29: How to customize your
Error List view
This was one of my least favorite designs
in the IDE. When the Error List was split from the Task List in Visual Studio
2005, a row of buttons was put on the top of the Error List for users to
customize whether they wanted to see just Errors, Warnings, or Messages. But,
then again, it enables me to show you cool tips like Tip
7.32. |
For example, here's the default
with everything enabled.
And now, here's the Error List with
nothing enabled, for dramatic effect.
Tip 7.30: You can view an error's
documentation directly from the Error List
If you right-click an error in the Error List view, you'll
see a context menu pop up with the Show Error Help option.
Clicking this command launches the
external documentation viewer, also known as dexplorer in some social circles,
to that specific error.
Tip 7.31: You can do multicolumn
sorting (secondary sort, and so forth) in both the Error List and the Task
List
Both the Error List and the Task List
have support for multicolumn sorting, such as secondary sort and tertiary
sort.
For example, suppose you want to sort all
tasks (or errors) by file first and then by line number so that you can go
through each file in the order in which the tasks (or errors) appear.
To do a secondary sort, follow these steps:
Click the column that you want to
have as the primary sort (such as File).
Shift+Click on the column you want to have
as a secondary sort (such as Line number).
Rinse and repeat for other
columns.
For the Error List, you can see how
things are sorted first by File and then by Line number.
Tip 7.32: You can bind the show
Errors, Warnings, and Messages buttons to keyboard shortcuts
In the "Tip of the Day" series on my blog,
this tip was entry number 200. Considering how I blogged a new tip about Visual
Studio every day, it is amazing to think what a difference a day makes. At the
time of this writing, I'm approaching number
300! |
I'm excited about this tip. Not
because it is tip number 200—this was purely coincidental—but because I
accidentally found it while browsing the commands in the
Tools–Options–Environment–Keyboard page that contained the word Error.
Go to Tools–Options–Environment–Keyboard, and search for Errors. You'll notice that this odd Errors command will
stare back at you.
I say this "odd" command because
usually Visual Studio commands have the canonical name format of <word>.<word>. This obviously caught my eye, so I contacted the
developer for confirmation.
These commands toggle the Errors,
Warnings, and Messages shown on the Error List, so you can bind them to keyboard
shortcuts.
For
example, you could bind the following commands to the keyboard shortcuts
shown:
Now, instead of clicking the buttons,
you can just use the keyboard shortcut. Pretty cool.
Tip 7.33: How to show or prevent
the Error List from appearing after a failed build
Usually the Error List is shown (whether
it is autohiding or just closed) whenever a build fails with errors. If you like
using just the Output window (because you can double-click an error message in
the Output window and jump to that line), here's how to prevent the Error List
from appearing.
Under Tools–Options–Projects And
Solutions–General, there's the Always Show Error List If Build Finishes With
Errors check box. Uncheck this option to prevent the Error List from appearing
after a failed build.
Watch Window
The Watch window (or Watch windows,
because you can have up to four of them) not only provides a way for you to keep
track of your variables and their contents, it also allows you to make changes
to the contents of your variables.
Tip 7.34: You can use the Watch
window to quickly change a variable's value
Have you ever been debugging some
code and wanted to quickly change a variable's value without having to stop
debugging? Here's what to do.
Add the value to the Watch window. You can select the
variable and drag it into the Watch window as shown here.
Then double-click the variable's contents
within the Watch window, and you'll be able to edit.
Either click outside this field or press
Enter to commit the change, and the variable will contain the new contents.
If you need to clear the Watch window's
variable contents, just hit Delete on that row.
Tip 7.35: You can view numeric
values in hexadecimal format in your debug windows
The debug tool windows (Locals, Autos,
and Watch window) have a context menu that includes the Hexadecimal Display
command. Just in case you ever needed to see values in hexadecimal, you now know
how to do it.
Immediate Window
When you want to do
more than just edit the value of a variable, you can rewrite entire functions or
create new ones in the Immediate Window.
Tip 7.36: You can use the Immediate
Window as a glorified calculator or side-debugger within your debugger
I found the Immediate Window
especially useful when I was doing the math to automate dragging a tool window
from a docked location to a docking target. I basically had to do the math to
calculate a straight line between the two points in order to send the
coordinates to the mouse drag functions. If I did the math incorrectly (and the
inside joke here is I have a math degree), I could pull up the Immediate Window
and play with the calculations over and over again without interfering with the
main debugger. This means that the variables and state of the main debugger
would remain the same, unless I purposefully modified a value in the Immediate
Window. |
Let's start off with a very simple
example. Let's say that you have the basic "Hello World" console app, but you
want to print out the result of some calculation. Notice how the console app
just has "Hello World."
If I put a breakpoint at the very
end of this simple console app, I can bring up the Immediate Window via
Debug–Windows–Immediate and do whatever I need. Let's say I needed to use the
Immediate Window as a glorified calculator. I can figure out the value of 1 + 1,
as shown in this Visual Basic console app.
Since we're in a console application, we can
even have the value of i printed to the console window via the Immediate
Window.
And now the value of 2 appears in the console window.
No comments:
Post a Comment