When debugging program in Idea (I'm using 14.1.5 Community Edition), it attempts to put the line I'm currently on close to the center of the screen. And it does so every single step. However, I find this default behavior very annoying, it looks like the code is jumping around.
I wonder if there a way to customize the debugger view in a way that the code would be fixed (as long as I'm not leaving one screen of code) and the current line highlighting would be moving around? (I didn't find it in the Debugger section of the settings.)
Many thanks.
You want to disable "Focus application on breakpoint" which is in the settings under Build,Execution, Deployment > Debugger - it's the first checkbox. It's help documentation reads:
If this check box is selected, on hitting a breakpoint, IntelliJ IDEA will show the location of this breakpoint in the editor and will attempt to bring its frame to the front.
This should do the trick.
Related
Regular Visual studio has this nice feature. I don't think it is available in VS Code.
When a breakpoint hits you can jump right to bebugging (pressing f5,f10 etc) without having to click on the IDE first. I love this feature. Does anyone know if VS Code supports this as well?
I think it is supposed to focus the vscode window. There is this setting:
Debug : Focus Window on Break
which is enabled by default. But see https://github.com/microsoft/vscode/issues/80441 and https://github.com/microsoft/vscode/pull/77213 it looks there are issues.
It doesn't work for me either on Win10. I added my example to https://github.com/microsoft/vscode/issues/105913. You may want to do the same.
I am using the Visual Micro extension for Microsoft Visual Studio, which allows me to debug my Arduino project (in opposed to the Sketch IDE).
For some strange reason, when no breakpoints are present, it automatically adds a breakpoint at the beginning of the loop function.
When running via the debugger, I can simply remove it and continue running.
However, I cannot do the same when running without a debugger (i.e., upon power-up), since breakpoints seem to be "embedded" into the code as additional code segments (though I'm not really sure how explain the fact that the debugger allows me to remove a breakpoint).
Here is an illustration of the problem:
Now, I've been able to work-around it by adding a piece of "dead code" with a breakpoint:
if (0)
{
// insert a breakpoint here
}
But this feels kinda "clumsy".
I suppose that if there is a solution to this problem, then it lies somewhere in here:
But I have not able to find it, so any help will be highly appreciated.
Found the answer!
It turns out that all I needed was to hover on top of the breakpoint and read the tooltip carefully:
As you can read on the bottom line of this tooltip, in order to switch off that automatically-generated breakpoint, we only need to disable the Visual Micro's Tutorial Mode:
And voilà - we're all done!
I am using Visual Studio 2010, and because of the amount of debug output I'm producing, and the difficulty of finding the beginning of the output for a new run, I have been manually using the Debug "Clear All" action (from the mouse right-click popup menu on the Debug output window). Plus I have to put some kind of break or dialog box in the beginning, just so I have a chance to do this before the debug output gets going.
Well after a couple of thousand times, this is getting very, very old (seriously, because its come up in almost every programming project I've done in the last five years). But I cannot seem to find any option or simple Debug.{method} to do this automatically for me.
This has been bugging me forever, and though its a simple question, I have never found an easy answer (short of writing my own listener) in any version of the .net VS IDE's.
Anyone know how to do this or have any ideas? thnx..
Right click the middle of the output window and turn off all but Program Output
What I do in cases like this is to use Debug View but to see the debug output in Debug view you need to detach the process from you visual studio debugger. You can do that through the Debug->Processes window.
What debug view provides is extra highlighting and coloring of different kind of debug output so that the relevant things are easily recognizable. Furthermore, you can stop receiving debug output by simply hitting a key on its toolbar.
I know that this might not answer your question but this at least gives you an option to do it otherwise.
I have been searching for an hour or so here and on Google and cant find the answer as to how correct breakpoints being shifted during run. I have reinstalled Xcode(3.2.2), insured load lazily is off, no optimization in target settings, and every other target setting that might cause the problem. I have also destroyed all of the user project files (except for the main .pro file) and nothing seems to correct this. Yes, I am running with breakpoints on. Yes, I have done clean builds.
When I set a breakpoint, in the debugger the break stops two or 3 (or more lines) down in the source code, single stepping continues to show the wrong line. Also, in the debugger window the dark blue breakpoint symbol is gone, it does appear in an editor window.
This is driving me batty.
I had a similar problem (weirdly shifted breakpoints) but my issue turned out to be that I had the wrong target set, so the code I was modifying and setting breakpoints on wasn't even being rebuilt! But the executable would still run, using the old code, leading to what appeared to be oddly shifted breakpoints.
Sometimes Xcode gets confused about line numbering when your source files have inconsistent line endings, e.g. because you've been using different editors and may have a mixture of different line endings in your source file. You can use a tool like BBEdit or its free sibling TextWrangler to fix this problem.
With-in "Build Settings" under the project target change the "Optimization Level" for "Debug" to "None".
I found that this fixed the issue for me.
I am working on an app with an NSTextView. When I paste random bytes into it (say, from a compiled C program) it displays gibberish, as it should. However, when I -setShowsControlCharacters:YES, the same causes a crash and gives the following error multiple times:
2008-11-22 00:27:22.671 MyAppName[6119:10b] *** -[NSBigMutableString _getBlockStart:end:contentsEnd:forRange:stopAtLineSeparators:]: Range or index out of bounds
I created a new project with just an NSTextView with the same property and it does not have this problem.
My question is, how can I debug my app to find the cause of the error? I have no idea where the bug originates. I am not familiar with the debugger built in to Xcode. If anyone could point me in the right direction in terms of how to track down such a bug I would be very grateful. Thanks.
Another set of useful breakpoints to set when your debugging Cocoa apps are objc_exception_throw and -[NSException raise]. In 10.5, all exceptions travel through objc_exception_throw but if you're targetting Tiger you should set a breakpoint on both.
There are more debugging techniques at http://www.cocoadev.com/index.pl?DebuggingTechniques.
It's not really clear how much you know so I'm going to try a very basic approach, please don't be offended.
I'm assuming the NSTextView is in a external nib/xib and is not created programatically.
If so open up your nib/xib in Interface builder and click on the offending NSTextView element.
Then hit Cmd-5 or Tools->Connections Inspector
From here you can see which Outlets/Actions to look for in the actual source code.
Most likely you're problem is manipulation of a "Reference Outlet" object, or in a "Sent Action" function.
Once you have an idea of which method(s)/variable(s) you need to watch you can open up the source code for those parts in Xcode. You can then set a break point at any line by click on that line number on the left hand side of the editor window.
Click on Run->Debugger. A new window should popup, click "Run and Go" in the toolbar of that window. Your app should run as normal until it hit's the break point you set in your source code. when the break point is hit you can mouse over variables in your code in the bottom half of the debugger window. The current values of the variables should popup allowing for easy inspection.
Usually you can gain the same information by using the Top Right panel of the Debugger to inspect the variable table.
When your done with that break point click "Continue" at the top of the debugger window and your program will execute till completion or the next break point.
This should get you started with debugging under Xcode.
Their are different kinds/uses of break points and all kinds of additional fancy stuff you can do in Xcode.
For more information check out this awesome CocoaHeads video.
Good Luck,
Brian G.