Printable View
Halo all,
I've problem regarding debugging in visual studio. When I debug any code in VS2005 it works fine but it doesn't show me the tracing of the program in any function other than main. If I use any function, call it in main, then the arrow doesn't go to the function but remains in main(). Is there any setting by which I can trace the whole code line by line even in functions other than main() ?
Thanks
It should stop wherever you place a breakpoint - F9 sets a breakpoint on the current line. You can set breakpoint properties by selecting the breakpoint and right clicking. You can also set/remove breakpoints by left clicking at the far left of the line. You can view all your breakpoints in the breakpoints window. Use F10 to trace over the current line and F11 to trace into. This depends on your key setup but I believe it is the default when you install VS. You can also add watches by right clicking a variable in the code window and selecting add watch. Visual Studio 2005 + also displays STL containers correctly so you can add watches on them.
I find conditional break points very handy.
I also use the 'Set Next Statement' and 'Edit and Continue' functionality (to fix bugs, then jump back and re-run code to test fix) all the time.
You might want to turn the optimizer off.
Somewhat it eliminates meaningless functions which sometime we need information from them, for instance dissambling.
Sounds like you're hitting F10, which means step to the next line. You should be hitting F11 instead, which steps INTO functions instead of over them.
So if you come to a line of code that contains a function call and you do NOT want to see that function, hit F10. If you DO want to see the function, hit F11.
Once inside a function, you may decide that you are no longer interested in that function and you want to "pop up" a level. To do that, hit Shift-F11.
If you want to stop at the beginning of a particular function, hit Ctrl-B and type the function name into the dialog box. Hit Alt-F9 to bring up the breakpoint window and you can easily see all the breakpoints you have set.
Note that if there is a breakpoint set for a function X(), then hitting F10 will NOT step over the call to X(). It will always break at X() if a breakpoint is set there.
Other techniques include breakpoints that break only on the Nth time they execute, or every N times. Or, you can make a breakpoint condition on some expression, so it only breaks if that expression is true (non-zero). Even more advanced, you can attach VB scripts to breakpoints to make other things happen in the debugger. For instance, say you have two breakpoints A and B. Suppose that you're only interested in B after A has already been hit. You can disable B, and then attach a script to A which enables B. (Truthfully, it's easier to do stuff like that in gdb but you can do it in Visual Studio as well)