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!
Related
I have been given a project that is the biggest pile of spaghetti I have ever seen, with 0 unit tests or any obvious naming conventions.
I find it hard to believe there is still no way while running in Debug to have Visual Studio automatically break on the next executing line of solution code.
In this case, I know the code is hitting a specific 5000 line of code file - but there isn't even an easy way to just write a breakpoint to every single line!
Is there any logical reason why in 2017 (or even 2010) this functionality doesn't exist?
Or perhaps it does and I haven't found out how!
Is there any logical reason why in 2017 (or even 2010) this functionality doesn't exist?
Please Put a break point in your code -> debug, then Right click on the text editor in VS, you will see below:
You can use the "Break all" button in the visual studio (Ctrl+Alt+Break is the default shortcut).
You might need to switch between the running threads in order to see highlighted instruction within your code.
Then you can just continue debugging, as usual.
If you do not see any of those two controls, go to View->Toolbars and check both "Debug" and "Debug Location".
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.
In Visual Studio 2013 Ultimate, if I edit my C# file (ASP.NET project) and then press F5, without explicitly saving, breakpoints are not hit. They are shown at runtime as empty red circles.
If I save, then press F5, they work as expected.
Even though saving before build is happening, I assume for some reason the debugging is happening against an older assembly? Holding the pointer over the empty circle reports "The breakpoint will not be hit. Source code is different from original version... to allow this disable the option 'Require source files to exactly match'"
I have tried resetting all my options to the defaults, but it still happens.
To exhibit this behavior, the edit seems to require a code change, not just adding a comment.
Tried all these but nothing works: "The breakpoint will not currently be hit. The source code is different from the original version." What does this mean?
Possible klunky fix:
However, I have experimentally added a post-build event, calling a small exe that does Thread.Sleep(5000). This seems to fix the problem!
So is my PC just too damn fast?!
I discussed this with MS, and they suggested the following on the command line
devenv /resetuserdata
This has fixed my problems. Don't forget to save your VS settings first, if you want keep them.
This is occurring in Visual Studio 2005, in an ASP.NET Web Application.
For example, if I try to set a breakpoint in the following code:
if (frustrated)
{
bool cry = true;
} <-- breakpoint here
It will set the breakpoint on the indicator margin, but when I actually hit F5 to debug the application, the breakpoint will flicker on and off (the little red circle literally vanishes then reappears) before disappearing altogether. Other breakpoints will work, just not ones ending on a closing bracket. This used to work, until I installed then uninstalled ReSharper (either it broke it, or its just coincidence).
EDIT: Just to reiterate - this is something that used to work, but doesn't anymore. I know I can put the breakpoint on a different line, but this is not what I want to do. I want it to work normally again.
EDIT 2: Resetting all of my settings did not help.
Any ideas?
Set the breakpoint on the line above it, instead of a closing brace.
If the breakpoint turns from a solid circle to an empty circle it indicates that the breakpoint could not be set usually because of a mismatch between the code and the actual binary module being loaded. This can be fixed by building or rebuilding suspect modules.
All projects opened while ReSharper was installed were affected. I went through each project and deleted the .suo file. After that, life was good - I can set breakpoints again!
Is there a good way to debug errors in the Visual Studio Designer?
In our project we have tons of UserControls and many complex forms. For the complex ones, the Designer often throws various exceptions which doesn't help much, and I was wondering if there's some nice way to figure out what has gone wrong.
The language is C#, and we're using Visual Studio 2005.
I've been able to debug some control designer issues by running a second instance of VS, then from your first VS instance do a "Debug -> Attach to Process" and pick "devenv".
The first VS instance is where you'll set your breakpoints. Use the second instance to load up the designer to cause the "designer" code to run.
See Debugging Design-Time Controls (MSDN).
It has been a pain in 2005 and still is in 2015. Breakpoints will often not hit, probably because of the assemblies being shadow copied or something by the designer(?). The best you can do is to break manually by introducing a call to Debugger.Break(). You may wrap it into a compiler conditional as so:
#if DEBUG
System.Diagnostics.Debugger.Break();
#endif
int line_to = break; // <- if a simple breakpoint here does not suffice
I have had this happen many times and it is a real pain.
Firstly I'd suggest attempting to follow the stack trace provided by the designer, though I found that often simply lists a bunch of internals stuff that isn't much use.
If that doesn't work then try compiling and determining the exception from there. You really are flying blind which is the problem. You could then try simply running the code and seeing what exception is raised when you run it, that should give you some more information.
A last-gasp approach could be to remove all the non-generated code from the form and gradually re-introduce it to determine the error.
If you're using custom controls you could manually remove the generated code related to the custom controls as well if the previous method still results in an error. You could then re-introduce this step-by-step in the same way to determine which custom control is causing the problem, then go and debug that separately.
Basically as far as I can tell there's no real way around the problem other than to slog it out a bit!
I discovered why sometimes breakpoints are not hit. In the Attach to Process dialog, "Attach to:" type has to be "Select..."'d.
Once I changed to "Managed 4.0, 4.5", breakpoints for a WinRT application were hit. Source: Designer Debugging in WinRT.
Each one is different and they can sometimes be obscure. As a first step, I would do the following:
Use source control and save often. When a designer error occurs, get a list of all changes to the affected controls that have occurred recently and test each one until you find the culprit
Be sure to check out the initialization routines of the controls involved. Very often these errors will occur because of some error or bad dependency that is called through the default constructor for a control (an error that may only manifest itself in VS)
You can run a second instance of VS and attach it to the first instance of VS (Ctrl+Alt+P). In the first instance set the breakpoints, in the second instance run the designer, and the breakpoint will fire. You can step through the code, but Edit-and-Continue will not work.
For Edit-and-Continue to work, set you control library's debug options to run a VS with the command line argument being the solution filename. Then you can simply set the breakpoints and hit F5. It will debug just like user code! As a side note, you can do this will VS and Office add-ins also.
This worked for me for Visual Studio 2022:
I opened a second Visual Studio instance
In the second instance I clicked Debug -> Attach to Process...
I selected DesignToolsServer from the process list
More details: https://learn.microsoft.com/en-us/dotnet/desktop/winforms/controls/walkthrough-debugging-custom-windows-forms-controls-at-design-time?view=netframeworkdesktop-4.8