Why does simply opening a file make VS think I've made changes? - visual-studio-2010

It doesn't happen all the time, with every file, but some times when I open I file I immedaitely see the asterisk show up in the tabs, as if I've made changes to a file when I haven't.
Moving to a new application at work where this one solution has over 100 projects, skimming through the code to try and get familiar with it, it's really annoying constantly getting bombarded asking if i want to save/discard my changes when I haven't made any.
Just wondering if there's a way to prevent it / what causes it.

Related

Lines of code automatically added without warning/consent

**edited tags to reflect the cause of the problem
I've been working with Node.js for about 3 months give or take, and today I was working on a project when I suddenly got an import error on the client side, even though I hadn't touched any code there since I last ran the program. In fact, the only changes I had made were on the server side, and it was just some minor refactoring that didn't have anything to do with the imports. After frantically trying to find what I'd done, I scrolled up to see this line in server/index.js:
const { default: socket } = require('../client/src/socket.js');
I didn't write this line. It had been added without me asking or even noticing that it was there. I'm pretty sure that I hadn't clicked on any formatting tooltips, and it seemed to appear out of nowhere and was the cause of the break.
This isn't the first time that this has happened to me. I have noticed that at sporadic moments, code is added to my projects that I never asked for. So I have some questions:
Is this a feature of Node, and if so what triggers it?
As I'm using VScode, is it rather the IDE that's doing this?
How do I stop whatever's causing this from trying, and failing, to be helpful?
Thanks.
This is most likely VSCode's built-in auto-imports. You've probably typed socket and selected an auto-suggestion which contained Auto import from "../client/src/socket.js"
You can disable it with the setting "javascript.suggest.autoImports": false.
Additionally, if you're using Git for version control, try using git add -p (-p for patch) to stage your changes bit by bit instead of the entire file. This way you can review your changes in slices and you'll probably catch things like this.
That's not a feature of Node but, Some of the VSCode extensions possess capabilities of auto import. Maybe one of your extension has added that line. To prevent it disable your JavaScript autocomplete, linter extensions.

Why do files occasionally turn into read-only mode after saving in Visual Studio?

I have a really strange problem with my Visual Studio.
I usually press CTRL + S pretty often (call me paranoid, well however I got that habit some years ago now and I really don't want to get rid of it :-))
Now I had the issue that I was editing one file, changing a few dozen of strings according to a spec I had open in Word; so I switch around these two tasks pretty often, make one or two changes and then save.
The odd thing is, every once in a while, after saving, my file is suddenly in read-only-mode, so I cannot navigate through my changes (CTRL+Z/CTRL+Y) and have to reopen that file to continue to code and pray.
Indeed it feels random to me when this occurs:
sometimes I only change 1 thing and save and then it's immediately read-only,
well in other cases it will let me edit several things until it is stuck.
Someone else also experiencing this and maybe got a tip?
Maybe I hit some magic hotkey or something?
My bad, please check if your projects folder is not a synchronized one, so when you edit (change) your project, the backup tool starts to update in remote location for synchronization purposes, so locks the file.
The answer to this problem is most likely that you are currently in Debug mode - i.e. the application is being run. Click "Stop" and it'll allow you to edit the files again.
By default, you cannot edit source files while the Debugger is running.

Xcode4 breakpoints adapt to code changes?

I have a series of logging breakpoints in Xcode4 that I'm using to selectively log things as I need them. However, whenever I make changes to the code involving adding or deleting lines, these breakpoints get out of sync with where they are supposed to be, sometimes even going to a completely different function.
Is there a way to keep the breakpoint in sync with the code, rather than just rely on the line number?
I believe it should, at least it's the IDE's usual behaviour.
Just a thought. Have you tried to reinstall XCode? I have experienced all sorts of weird bugs since the upgrade to XCode 4. For example, being unable to select a XIB file for a popup window in a project---and when creating a project from scratch, I was able to select that XIB and create the popup. At the time I posted a question on StackOverflow about this and it is still unanswered ever since.
Since that time, the project was overhauled and now I build my interfaces from scratch using full Obj-C code, dumping the interface builder 99% of the time...

Visual Studio 2008 with Source Safe: Recover data lost by auto-checkout?

I am using Visual Source Safe 2005 and Visual Studio 2008.
##$% this Source Safe. With programs like Source Safe that ##$% up my data, who needs viruses, hard drive failure, and other assorted calamities.
My story starts with getting my workstation re-imaged on Monday this week. After the machine was re-imaged, I downloaded from Source Safe the source code I was working on. Thursday afternoon, I noticed that as I was working on my source code, the files were not being automatically checked out from Source Safe as I worked, however there was no problem saving my work on the disk.
So... I needed to check in my work. I noticed that the files (not checked out from Source Safe) were not read-only as they usually are, so I made them read-only.
I feel like I should have backed up my data locally at this point and I'm now kicking myself for not doing so, but the next thing that I did was I went back to Visual Studio to continue my work and see if I could get the program to automatically check out the files I was changing.
The first time that I began to edit a file (BigLongCodeFile.cs), it automatically checked out the file for me as I had hoped. However, in a split second it displayed a dialog that explained, "Your action caused a check out of file(s) BigLongCodeFile.cs, and a new version from source control has been loaded in the develpment environment. Please re-do your changes if necessary." And just like that, Visual Studio undid all the changes I had done to that file since Monday, representing hours of lost work for me.
It didn't prompt if I wanted to do this, just showed me a dialog informing me that the damage is done. With development tools like this, who needs a virus to destroy his work?
Is there some way to get my data back, or some way to avoid this?
The mistake was setting the flag back to read only, which was exacerbated by not making a copy of the files when you found things were not getting auto checked out from SourceSafe. Unless the new copy was written to a different location on the drive, which is unlikely, you are currently hosed. If it could possibly be saved elsewhere (note I am talking physically saved, not logically saved (ie, what you see in Windows Explorer == logical)) you can use an undelete utility. It is a long shot, but you can try undelete tools; I would not hold out much hope.
One of the first things to do when you find source control is not working correctly, and you have altered files, is to make a backup of the folders you have worked on. A simple copy of the structure to a temp location is good enough. Then fix the source control issue and be prepared to consolidate your efforts. There are tools for this, if you are worried someone else might have edited files.
As for why VS did not warn you? The file was flagged as if it was not changed. VS noticed something after the save operation (size change, most likely) and warned you something was in error.
In the past, I have been burned by trying to second guess software, so I know the pain. That is why copy backup is a good practice when you notice something strange. This is less problematic in TFS, but I would imagine it might just overwrite a file that appeared to be checked in (read only flag set) as well.

Why is xcode(4) so slow to dismiss errors I've already fixed?

So I hit Cmd+B and xcode throws all these errors and warnings at me. But after I fix them, xcode is sometimes slow to catch on, often requiring another Cmd+B on my part to nudge it to recheck the file. Is there a setting somewhere I can toggle to make xcode recheck for errors more aggressively?
It seems there's still room for improvement on the things that cause Xcode to retry your code. One thing I've noticed is that if you change something in a header than navigate back to the implementation, it quite often won't detect the fix until you force a build (or run it, which builds first).
The workaround? Save (Cmd-S) the file before navigating away from it or save all files (Cmd-Opt-S) if you've fixed several problems across several files.
The long-term solution? File bug reports at http://bugreporter.apple.com

Resources