What's going on with this? I've never seen it before and have no idea how to turn this on or off. It doesn't do it with any other block of js code (or other code, for that matter). If I could get it to do this with every single block of code, that would be more than incredible...
If I am not wrong then most probably that's the code block where you have debug point/break point set to and so it's highlighting the same area. At least, that's what it does for C# editor; hopefully will be the same for Jquery as well.
To turn it off, remove the break point and see if it still remains.
Related
I apologize in advance, this will be a very basic & general beginner's question:
Why is my debugger "breaking" on a line where I have not set a breakpoint?
Some more detail:
I'm working on a large buggy C++ project in XCode 12.4.
I've set a single breakpoint on function A. The debugger refuses to break on function A. Instead, it breaks consistently on function B. Function A and B exist on the same cpp file. I believe function B is supposed to be called AFTER function A, but they definitely do not call each other and are not called simultaneously.
I've definitely experienced the debugger stopping on various errors, but with a RED highlight, not a GREEN one - as I understand it the GREEN highlight only happens on a breakpoint I set myself.
Is this expected behavior? Am I missing something obvious?
(First post, please tell me if I'm doing anything wrong!)
EDIT: I solved & answered my own question below!
The most common cause of the debugger pausing at a place where you didn't set a breakpoint is the throwing of an exception. Some exceptions crash the program, which is where you get the red highlight in the debugger. Some exceptions don't crash the program. In those cases the debugger highlights the exception breakpoint in green.
If the debugger pauses your program with a green highlight, click the Continue Execution button (it's the second button from the left in the group of debugging buttons right below the source code editor) or choose Debug > Continue in Xcode to continue running the program.
These are all great responses and I learned a lot from them all - but it turns out the answer was much dumber.
For whatever reason, when I compiled, XCode did not delete the previously compiled binary. As for my breakpoint issue, I'm still not 100% sure what was happening, but it is solved now.
Here's how I noticed: Function A did not exist when I compiled it last time. I had created a String in function A. This string assignment returned a bad access error - so I assume it was assigned outside the program I was debugging!
Thank you to responders!
I don't like it this way:
It stretches code and reduces readability. Is there a way to move it to the right side and maybe even change "references" word to some icon, like this:
I researched this question, this type of question has been asked multiple times with similar suggestions to move indicator to not add lines in order to not stretch code:
https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/5120120-move-code-lens-to-the-left-side-instead-of-above-m
https://github.com/Microsoft/vscode/issues/23652
Display CodeLens above attributes
But Microsoft decline it every time for some reason and I couldn't find any solution to this problem.
Did someone figure out how to move CodeLens to the side yet?
I have been using Xcode recently a lot, however, every so often I'll inexplicably receive error messages about perfectly innocuous components of my code. I'd like to know how one diagnose these because as you can see in the buttom right of the screenshot, there's no log entry to go off of. Thanks.
Here's my screen shot:
It looks as if you have accidentally set a "breakpoint" in your code. You set a breakpoint by clicking on the left margin. A breakpoint stops your code automatically when it reaches that point.
Since you commented out the inside of the goBack() function, it stops at the first line of uncommented code.
The breakpoint you set is the little blue line to the left of the line self.scoreLabel.removeFromSuperview(). To get rid of it, click it and drag it into the main area of your code.
I started a new job a few weeks ago.
In my previous job, I was working with 2 screens. I know have 3 screens here (what an upgrade!)
I have always been bothered by a small bug, and since today I don't have a lot of code to do, I decided to finally try to solve this problem. The layout I want to achieve is pretty simple (see screenshots below): One file on the left screen, and another one on the right.
What happens is the following:
When I enter debug mode, the layout stays the same except one thing... the separation between two files (which is usually right between the two screens). Annoying for breakpoints and stuff, so I resize it, debug, and...
When I leave debug mode and go back to debug, the layout go back to what it was... except the separation which moved as well!
And last but not least, if I close Visual Studio and open it again, my two file views are now expanded on both screens, separated horizontally (<- this one is new, I had never seen that before).
Every time I go to debug mode, or go back to design, I would resize it to fit my two screens. And then it would shift again at the next debug. After some time it shifts with a smaller amount of pixels. Then, it just stops shifting, as if it learned that it shouldn't change. Until at some point, it goes back to normal and forces me to resize again.
I tried to use add-ons such as Perspectives or Layout O Rama , but they didn't keep any information about the two Code windows. No matter how I was saving them (let's say, one would be 20% of the left screen, and the other would expand on 2 screens), it would ANYWAY go back to the strange, shifted layout.
I also tried Visual Studio Productivity Power Tool and it's terrible. If I dock a code tab as a Window on my second screen, and dock for example the Find Results on it, it would be separated or reorganized every time I switch to Debug/Design
Has anyone experienced that yet? Am I the only one feeling that my Visual Studio is a pet who will learn how to do his own layout as time goes?
Thank you!
Also, as an image is always better than a description, here are a few screenshots:
Here, the normal, regular layout, with the red line being where my screens stop. Perfect, al dente layout allowing me to use the best of my two screens
Here, the one happening every time I go to debug. Notice how ONLY the code windows shifted (the bottom part with error list on the left and find results on the right didn't change at all )
And this is the one I get when I restart my IDE, forcing me to recreate my layout all the time
Thanks a lot!
I would like to find a way to see what happens while my XAML is being loaded. What classes are being instantiated, and in what order? Which properties are being set, to what values, and in what order? Which methods are being called (e.g. BeginInit, EndInit, etc.), in what order, and with what parameters? That sort of thing.
(If anyone's curious as to why, it's because the XAML loader is doing something magic that I can't duplicate in code, and I'm trying to figure out what it is.)
My first idea: Configure VS to debug into the .NET source code, and single-step through the XAML-loading code to see what happens. Unfortunately, source stepping has been busted for months, and there's no sign of that changing.
My second idea: Make my own classes that descend from WPF classes, override OnPropertyChanged, and do a Debug.WriteLine. Unfortunately, one of the classes I want to know about (BitmapImage) is sealed, so I can't descend from it.
Anyone have other ideas on how I could get some visibility into what the XAML loader is doing? Are there any tools (profiler, maybe?) that could give me a call graph? Is there a way to turn on some kind of logging in the XAML loader? Thoughts / suggestions?
Edit: The article Steve linked to does have the answer, though their sample code makes every event get displayed twice. For reference, here's how to make this work in code (no app.config changes required). Add these lines before the InitializeComponent() call (or type both lines into the Immediate window in the debugger):
PresentationTraceSources.Refresh();
PresentationTraceSources.MarkupSource.Switch.Level = SourceLevels.All;
This will cause detailed output to show up in VS's Output window, including the properties that get set magically behind the scenes.
You can trace a lot of the binding and loading with system.diagnostics. I've found a number of problems using this namespace. Its unwieldy like everything else in WPF, but it works. You can see what's getting set and where.