Currently VS Code will only highlight errors when the file is saved. This can get bothersome, as it isn't immediately apparent sometimes if you've mistyped something or are using something wrong etc.
Is there a way to make VS Code automatically show syntax/logical errors i.e red/green squiggles underneath code?
I am working with python but I have the same problem.
As shown here: "Linting runs automatically when you save a file."
Therefore, what I did to automatically lint, is enable Auto Save. With this configuration you can achieve linting almost in real time.
I guess that for C++ will work similar. Hope it helps.
Related
(I've looked far and wide but I can't even find anyone having the same problem, not to mention a fix or anything. Closest is this thread which just announces the feature...)
The way it currently works for me, the VS2019 code lens integration of P4VS (for C++ at least) is almost completely pointless. Each function has an indicator added, but the information in each is identical - namely the change history of the entire file:
According to this Microsoft article, I would expect to either get function-level change information that pertains only to that function or a single change summary of the file at the bottom of the editor. But instead I get the worst combination of both.
I'm mainly surprised that I can't find anyone else talking about this, so I assume something is misconfigured on my part. Can't find anything in the configuration options though...
Is this just a bad implementation by Perforce or is something wrong on my end?
I have just found out that it can be turned off by Visual Studio options.
How to turn off CodeLens-References
Text Editor > All Languagues > CodeLens
I am a new programmer and I am trying to use the terminal on my Mac to compile and run the C++ code I write using the Sublime text editor.
I am able to get my code to run using the terminal, however, whenever I make changes to my code on sublime and then re-compile it on my terminal, my terminal doesn't recognize my changes and keeps on running my original code.
Does anyone know what might be happening?
Thank you so much!
I can think of two possibilities that spring immediately to mind. If you're changing your code in the editor, and that's not being reflected in the compilation, then it's likely to be one of the following. Either:
you're not saving the file in the location you think you are; or
you're not saving the file at all.
The easiest way to tell if one of these is the case is to introduce an error into your code(a), like:
int my hovercraft = full of eels;
and make sure the compiler complains about it.
If you're not saving it at all, do so. If you're saving it in the wrong place, you can usually find out where just by doing a Save As and seeing where the default location is.
If you're annoyed that you have to save, and that computers should just "work"(b), Sublime Text has an auto-save feature that may come in handy, courtesy of one Lucy Bain. Instructions (paraphrased) are duplicated here in case that site ever disappears:
Open Sublime
Find Settings and edit the user window (under Sublime Text 2 > Preferences for Mac, just Preferences for Windows).
Add the line "save_on_focus_lost": true.
Save and close the file.
At that point, whenever you click away from a particular file, it should save it.
(a) Some developers seem to have little trouble doing this without even trying :-)
(b) A not unreasonable expectation for a Mac user :-)
I'm using VS2012 and I'm quite happy with it. But the problem is, whem I'm coding in C++, that the syntax highlighting is turning off an on all over again. Sometimes, the highlighting is off and I have to reload the file. Also, it highlighting is quite slow.
Does anyone know how to fix it?
I know this is a while ago but I have had this same problem appearing randomly until just now.
It would disable when the last line in a file was a single line comment. (// blah blah). As soon as i removed that the text highlighting worked again!
Edit: In this answer I assume that your problem description is correct. In other words, I'm assuming that occasionally C++ highlighting is working, and the other times the text appears as plain text: completely black and white.
My guess is you are using an extension which modifies or replaces the way Visual Studio highlights C++ code. Try temporarily disabling all of your extensions and checking again if the editor is working. Some extensions might have the Disable button disabled; in that case you'll need to uninstall the extension for this test (possibly through Control Panel → Programs and Features).
As an example of one common extension that completely replaces the C++ highlighter is Visual Assist. However, I do not personally use that product and I haven't heard of any specific problems with it of this nature. I am merely mentioning it as an example of an extension that completely changes the behavior of Visual Studio in regards to syntax highlighting of C++ code.
For me, highlighting always stops working when the first visible line in the editor begins with the characters '//' and I trigger reparsing somehow (CTRL + S for instance).
Highlighting always works fine when the first visible line in the editor begins with anything else, even with a whitespace, and I trigger reparsing somehow.
I could indent all my comments and never experience this problem, but now that I know about it, it's not so annoying anymore, so I let it be.
This is a bug in Visual Studio 2012:
https://connect.microsoft.com/VisualStudio/feedback/details/760154/syntax-highlighting-sometimes-not-working
If you're using only Intellisense, you may go to Edit->Intellisense->Toggle Completion Mode (or hit Ctrl + Alt + Space), play with it and see if it works (maybe you've pressed this combination of keys by accident).
I've also installed Update 3 and haven't had any problems since. Who knows..
I had the same problem. Disabling the extentions sadly did not work for me.
After searching around and realizing that it only happened on larger files,
I got it to work by turning harware acceleration off.
Tools->Options...->Environment->General
*Automatically adjust [...] (off)
*Use hardware graphics acceleration (off)
In my case, it turned out that a large block of code (a 200+ line method) was commented out with // starting in the first column, and this was causing the syntax coloring not to work. I changed the commenting delineation to /* ... */ for that method and all of the syntax coloring was fixed.
Personally, I found that things like:
#if 0// bla-bla
mess up syntax highlighting badly. The solution that works for is to put a space before a comment, like so:
#if 0 // bla-bla
I installed Visual Studio 2012 Update 3 yesterday and started experiencing the exact same behavior described in the original post. Based on some suggestions in this thread, I took at look at my extensions, and disabling AllMargins fixed the issue. I've since re-enabled AllMargins and everything appears to be working as it should.
Try disabling and re-enabling any of your extensions; hopefully that will fix the issue for you.
Does anyone have a clue what could cause a breakpoint not to show the actual place of the code in a specific file?
This is the second time this has happened to me.. maybe someone could help, my parameters:
I am working in visual studio 2010.
This one specifically is a static lib but it also happened to me inside dll's.
The PDB's are generated in Z7, although this has also happened to me in the default pdb generation.
I am sure the code is compiled with the correct lib(also happened in dlls so..)
Also I have some Doxygen comments I first suspected causing this problem(could it be?)
Attached is an image that show where the breakpoint arrow is compared to the callstack of where it ACTUALLY is..
Thanks!
If you debug code that has optimization enabled, the method might just be inlined. This is at least one proven source of breakpoints not pointing to the right position.
One of the scenario's which I have generally noticed is when source file changes due to fetch of a file from source control while debugging. Break point uses the line number of older code.
So, apparently the visual studio text editor doesn't adapt well to CR..
I found that the file had some CR (and not CRLF) and that confused the compiler all together..
When I actually made a compile error on purpose, it didn't even point to the correct line...
So I added LineFeeds(LF) after every CR and it compiles fine...
(Used notepad++ to detect where it was missing but I'm sure VS has a way as well..)
Cheers.
I have a Managed C++ WinForm that suddenly stopped showing in the VS 2005 designer. The error it shows is
Could not find type 'int'. Please
make sure that the assembly that
contains this type is referenced. If
this type is a part of your
development project, make sure that
the project has been successfully
built.
I don't even know where to start with this one. Does the designer only access the InitializeComponent(void) method when rendering the form? So my question is: where do you start troubleshooting designer errors?
EDIT: I forgot to mention that this code builds and runs perfectly. It only shows an error in the windows forms designer.
This is troubleshooting for C# but I'd assume a couple of the points mentioned here would help.
What's the state of play with "Visual Inheritance"
This is usually caused by a syntax error somewhere in the code that causes the designer to be unable to run the form to render it. The best method for this is ofent sadly just reading the code looking for the problem extra brace, missing string etc. The good news is that it is most likely easy to find since you know that it preceeds the INT in the error message.
Some possibilities:
* I cause this usually by accidentally hitting the keybaord and putting some extra characters at the top of a file
* Extra braces that make the class uncompilable - missing quotes, semicolons
* Something typed at the top that messes up a common include/using statement
Diagnostics
* Sometimes you can find this by dogin a build and seeing what lione is flagged with an error and then looking around it.
* More often then not I have to just open the source file and scan through it looking for the problem.