I am using Xamarin Studio 5.10.2. In the debugger I can set breakpoints, run, and the debugger does stop at the breakpoints. However, it does not bring the location of the breakpoint into view. I know the breakpoint is hit because it displays the call stack in its window. When I double-click on the top item of the call stack, the source file is opened and the line pending execution is displayed in the center of the editor.
I can step along execution and see the lines highlight as it goes through them, but it never re-centers the current line and it will step right off the bottom of the window. (I can keep it in view by either manually scrolling or double-clicking the top line of the call stack.)
In Visual Studio (with which I'm much more familiar), the pending execution line is displayed automatically when the breakpoint is hit---no need to double-click on the call stack. Is there a way to get this behavior in Xamarin Studio?
Related
I am working on a program and a lot of the buttons and menu items are dynamically created. Its especially hard to work on because I don't know where they are created and assigned to. It would help if I could start up the program via debugger, get to the menu, then switch to "line by line" style debugging like pressing F10, where the next line of code ran would break, and then press one of the buttons to get more info about it once the break happens. Is there any way I can do this in visual studio?
In Visual Studio, you have the Solution Explorer. There you see the Project files, they are under the top level Solution. If you right click on your main project, go to: Debug > Step Into New Instance.
If you work on a .NET application, you can use my Runtime Flow tool to see what code is executed when you select a menu item or press a button.
The closest way I could figure out how to do this is to go into Debug>Disable All Breakpoints and then when I get to where I need to be in the program go back and Enable All Breakpoints. Of course this only works if there is a large number of breakpoints in places in the program.
When I have a code file open and a breakpoint hits, Visual Studio automatically switches the open page to the corresponding file and places the cursor on the corresponding line.
This is quite annoying in my present use case where I'm looking at-on screen values and code lines in a shader file simultaneously, using a breakpoint and F5 to jump to the next frame will switch from the shader file to my breakpoint location.
This is not about VS stealing focus, but about preserving internal focus within VS. I just want silent breakpoint hits.
In Visual Studio 2015, you need to right click the breakpoint to choose "Action" option. It will open the Breakpoint Settings dialog. Now you can add the message that you want to write in Output window and check "Continue execution" option. After setting the output message, the breakpoint will not be hit.
In Visual Studio right click on the break point. In the context menu select the When Hit... menu option. On the When Breakpoint Is Hit dialog box check the Continue execution checkbox. Use the Print a message text box to customize a message to be written to the Debug output so you can tell the breakpoint was hit.
I want to remove several breakpoints along my program execution path. XCode stops at each breakpoint and I want to clear it immediately. In contrast to all other tools that I used to, Xcode does not put cursor on the line it stopped. Therefore, "toggle breakpoint" shortcut instead of clearing current breakpoint, puts breakpoint somewhere out of sight.
To clear current breakpoint I need to grab mouse or press extra shortcut before actually clearing breakpoint. It gets very annoying for several breakpoints in row.
Maybe there's workaround?
You can click inside the topmost thread in the Debug Navigator ⌘+6 to see where you stopped.
If you want to automatically skip a breakpoint or perform other actions when it's triggered you can Right-Click or Control+Click the breakpoint, choose Edit Breakpoint... then check Automatically continue after evaluating actions.
1) I put a breakpoint, VS breaks where I put the breakpoint.
2) I then start browsing around the code normally to put another breakpoint
somewhere down the execution path. (maybe in another class in some other cs file)
3) I would now like to return to where I first stopped (just navigation in the code. Do not confuse with the go back in debugger feature used in VS's intellitrace debugging tool)
Right now I place a bookmark and return to my bookmark. But I forget most of times to place a bookmark. Hence this question. There's got to be a shortcut to get back to current line of execution or stopped at or whatever phrase is used to describe this. I also have Resharper if I can craft up some hotkey or shortcut. Anyway I can get back to where the debugger has "broken". I sometimes also use Ctrl - multiple times to navigate backwards.
thank you
That would be the Visual Studio command "Debug.ShowNextStatement" (usually assigned to Alt+Num*). You can also use the Breakpoints Window (Alt+Ctrl+B) to navigate between your breakpoints.
UPDATE: I implemented #Alex 's request for a more discoverable and accessible MenuItem for this functionality, as part of a commercial Visual Studio extension I created called OzCode. It works similarly to Resharper's Context Actions: when you are in break mode but have navigated far away from the 'current statement', this QuickAction will appear:
I tend to use the call stack window, double click the top line in the stack trace causes the editor window to display the code line where execution halted
Often, when I have a breakpoint on some line in Visual Studio, The program will run and stop there. great. I will then click the red circle (or press F9) to remove it. Obviously I don't want my program to keep stopping there. The problem is that the next time I refresh the page the breakpoint is back! The only way to permanently remove it is to open the breakpoints window and remove it there. Why does this happen and how can I change this behavior?
I have noticed that these breakpoints which keep coming back have a little plus next to them in the breakpoints window which when you click on - open up many sub lines of breakpoints. What is the deal with that?
Thanks,
Adin
Helpful Key combo: to permanently delete all breakpoints, press CTRL + SHIFT + F9.
Just clear the breakpoint while the debugger is off. When you clear or add a breakpoint while debugging, the action only lasts for that debugging session.
The plus in the breakpoints window is there when one user-supplied breakpoint binds in multiple places. This can happen when a single file is loaded multiple times in the same debugging session, for example. The + lets you look at each of the places it bound.
#Joel: modifying breakpoints during a debugging session does not make your change temporary, although there are circumstances (like the original question), where the actual behavior can be non-obvious.
I've post suggestion to MS to fix it:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=391642
It appears since Visual Studio allows multiple breakpoints on a single line, i.e. in separate sub-clauses, architecturally it allows multiple identical breakpoints. The interface does not necessarily reflect this and you will see the removal of a breakpoint as graphically removing it, but not programmatically removing all instances of it.
Looking at the Debug > Windows > Breakpoints window shows for a given set of breakpoints on a line, they are stored in a sub-tree under that line item. Removing a breakpoint while watching this list will reveal the behaviour, that only one of a series of identical breakpoints is removed from the list associated with that line. By removing the breakpoint line item and with it all sub items it will completely remove all instances of the breakpoint.
Wipe the breakpoint out using the Breakpoints Window (Ctrl + Alt + B).
While debugging, when you hit the breakpoint, look at the BreakPoint window for the one that is bold.
Then, right-click it and choose Delete.