Let's say before I check in, on the team explorer I right click on a file and compare it to workspace/latest version (doesn't really matter which, and the location neither, it's the same thing with code reviews, Changeset details->compare with previous) it will only show the deleted/red lines in the file, although it does show the added (green) parts in the scrollbar.
Have anyone had this problem before? I imagine a reinstall might just work, but I'd like to avoid it, if I can.
If the error is only occurs for your machine. It's more likely related to VS. Usually reinstall vs is the final solution.
You can also try the suggestion as Sachi commented, try to clear TFS and VS cache. This may do the trick.
If it's not work, still suggest you to reinstall VS. Even though this may not be a good solution. After all, it's very likely you have taken a long time to trouble shooting the weird issue and still can't find the root cause.
Related
I'm new to Xamarin/Android, and so far it's been a pretty frustrating experience, compounded by code/AXML changes seemingly not being built or deployed to the emulator. I often find that a change I've just made seems to get ignored when I build and run the app.
My suspicions were confirmed when it started throwing an exception on a line in MainActivity.cs that I had commented out. Cleaning and rebuilding didn't help, and in the end deleted the bin and obj folders and uninstalled the app off the emulator for good measure (not sure which of these fixed it though).
Is it just me or is this a common issue? Is there anything I can do to prevent it from happening? I'm using VS2015 Community by the way.
Go to 'Tools/Configuration Manager' and make sure that both 'Build' and 'Deploy' options are checked for 'YourApp.Android' for active solution configuration and active solution platform. Then do 'Clean solution' and 'Rebuild solution', it should always work.
It looks like this is a common issue, as yet unresolved.
One of the comments in the above thread suggested that the problem can occur if you've only changed C# code, and unless you also "touch" one of the xml or axml files then the latest version won't be deployed. This seemed to do the trick in my case but it could have been a coincidence - Xamarin seems to be a temperamental beast, and will randomly fail to build or deploy on occasion, perhaps depending on the wind direction, or colour of my underwear that day.
I'm still in the early stages of learning Xamarin/Android, but if I don't enjoy the experience then I'll be jumping ship to Android Studio (although I'd prefer to stick with C# if I can).
I've got a group project built in Delphi XE2 that has 3 projects that always build to the wrong folder for one option set. (I've got 4 configurations under Release and Debug, one for our software configurations and one for FastMM and it's only the debug one that I want to use for debugging that always goes in to the wrong folder. Compiling the project even says it's building to the correct folder, but the DLL always winds up in a different one which I only used once when I was unit testing the code outside of the main project.
I've deleted every associated file, .identcache, .res, .tvsproj (whatever that was) and nothing changed. One very strange thing I noticed is that I copied one of the projects to configure the second one and mimics the behavior of the one it was copied from and I never even unit tested that one, so it never had that output path configured for it.
Obviously this makes it pretty annoying to debug, I have to copy files in to the correct folder just to do that (I was kind of astonished when it actually worked, because I thought Delphi might expect to find the files in it's output path, but oh well, those things are magic)
Let me know if I can post anything to help, I don't really know what's necessary, I checked the registry for the output path that it is getting built do and found nothing that I thought was of any consequence (nothing related to these projects).
One thing I did notice was, because I copied the original project into another project (they're plugins to the same part of the main program) it has the same and when I try using it in the "Build Group" it automatically selects both projects. That's one mystery solved, but is probably a red herring?
OK so as usually happens, after 3 years of suffering with this when I finally ask the questions I'm lead straight to the answer it appears as if RAD Studio is lying to us. The configuration shows this:
but the dproj had this:
in it.
there were two conditions for cfg_3 and only the last one showed up in RAD Studio, well for some odd reason the build path was taken from the first one (even though it's specified in both). So, removing the wrong one (the first one) fixed the problem and things are now building to the correct folder.
I had imported the Utils option set when I was testing the library, but when I incorporated the program in to the main program, I removed it. Somehow it didn't find it's way completely out of the dproj and I guess (not sure why) but it seems like the other library got messed up because it shared a GUID.
I have tried changing the background color of toolbar in notepad++. I am not been successful so far. Frankly speaking I am not so liking the toolbar color and would like to have a dark background to the toolbar. Is there anyway I can do the same? Thanks in advance
Take a look at this question on Superuser. I haven't tested it, but I think it can help.
below there's the hack (as explained in the link):
The themes, as you guessed, can't do this (they only handle what's in
the text editing window). To change the colors you'll have to make
some very simple changes (since it's only changing color values) to
the source code (download from the site or GitHub).
Extract the file Find the elements whose color you'd like to change,
and change them. All colors I've seen are denoted RGB(xx,xx,xx)
Rebuild (see /readmeFirst.txt once you've extracted) I've just glanced
at these files, but I'm definitely going to work at this a little
tomorrow and I don't mind giving you my results once I've solved it.
Anyway, what I've seen at a glance is that you'll want to look in
/PowerEditor/src/ScitillaComponent/DocTabView (I think)
/PowerEditor/src/WinControls/TabBar
/PowerEditor/src/WinControls/ToolBar That's all I noticed that might
be of interest so far, but again, I'll look at it more tomorrow and
get back to you.
Edit: the official makefile will give some errors, because
/PowerEditor/src/Parameters.h references files incorrectly. Here are
the two I fixed so far:
#include "TinyXml/tinyXmlA/tinyxmlA.h" (line 33)
#include "TinyXml/tinyxml.h" (line 37)
Change those lines in Parameters.h to what I've written to deal with
them. Don't worry about the warnings ("extra tokens after #endif") -
they're just comments.
Edit 2: I'm using VS2012, in which the build process results in
numerous errors. I won't post them here unless someone eventually asks
about them, in which case I'm happy to do so. I should have a working
build up soon!
Edit 3: It seems Notepad++'s provided VS project file was created with
an earlier version of Visual Studio, and in updating the files, Visual
Studio 2012 creates many problems, so if you go that route, use
VS2010.
Edit 4: I didn't make it obvious in Edit 3, but I gave up after
realizing just how difficult it was going to be to get around the VS
errors. I imagine the code has changed significantly since I wrote
this answer as well; unfortunately I didn't note the version, but I'm
sure it was the latest available at time of writing this answer,
which, according to "All versions", was probably either 6.4.1 or
6.4.2. However, I hope this is a useful starting point for anyone else who reads (this answer has received consistent attention since
writing).
As far as I see into details of creation of the user interface elements (buttons, toolbars etc.), the answer is that toolbar color cannot be changed until developer explicitly built such a feature into the application. And N++ has no such a feature if you check its settings.
You can achieve changing of toolbar color by standard way: override toolbar painting routine after you grabbed N++ sources. Then compile custom Notepad++.exe which reflects your change.
If you feel toolbar coloring would be useful not only for you, but for number of users, consider registering a feature request for Notepad++ as many people (including me :)) already did for various features of N++.
Go to Settings> Preferences
Then select Enable dark mode.
Then you have the option to pick colors for the dark mode and can even set custom colors
I recently changed from developing iOS apps on a MacMini to a new MacBook Pro (2.2 GHz Intel Core i7). While working in XCode, I occasionally get pop-ups when the system is apparently trying to do an autosave and runs into a problem.
The pop-ups state "The document [filename] could not be autosaved. The file has been changed by another application. Click Save Anyway to keep your changes and save the changes made by the other application as a version, or click Revert to keep the changes from the other application and save your changes as a version."
Examples of the filename are: AppDelegate.m, MyLoginViewController.m. There shouldn't be anything else that is changing those files.
I can't do anything within XCode until I choose one of the options. Sometimes it seems like the system is trying to overwrite my newest code with an old version of my code, sometimes it seems like it is trying to save my newest code. So, sometimes Revert is what I need to do to keep my current version, and other times Save Anyway is what I need to do. However, sometimes, I can't tell what the system is trying to do and I choose the wrong option and lose hours of work.
This has happened numerous times over a span of three weeks.
I am using OS X 10.7.2 and XCode 4.2.1. The code is on my MacBook's hard drive.
Does anybody have any idea why this is happening?
Thank you.
This is a huge problem, and it looks like it's Lion's force-fed "file-versioning" that is destroying work.
I typed quite a bit of code into my source and saved it regularly (pretty much after every complete paragraph). Suddenly I couldn't find an entire section that I'd just written. I even did a project-wide search, in case I'd accidentally entered it in the wrong file. Suddenly Xcode raised a dialog saying it couldn't autosave the file because it had been modified externally. Did I want to "revert", or save what was in the editor?
In the several times I've seen this come up on two systems over the past few weeks, I've chosen to save what's in the editor, thinking that obviously it must be the most recent version. WRONG. I hit "Revert", and the block of code reappeared.
There is so much wrong here, it's hard to decide what's the most offensive.
Confirming that this happens on XCode 4.3.2 on an iMac running 10.7.4.
I have found that this bug may be related to having the same file open in more than one tab or window in XCode. If you carefully avoid ever having more than one window open on a given file at a time I think you can avoid this problem. However, it undermines the very useful ability to apple-click method names to navigate to the file that contains them.
This has cost me hours of original work and been the source of immense frustration. The derisive comments from others are simply inadequate.
I heard they had a complicated fix for it already at Apple, but unfortunately, it was "accidentally lost" and now they can't remember which files need what changes to make it work again. :-/
My Delphi installation has been going downhill for the past few months. It seems though that every so often when I build a release it has strange errors in it which are resolved if I build, then compile, then build, compile, etc.
I've talked to another developer who thinks that this is a compiler error. This sort of degrading performance over time has happened on other computers to us too.
What does stack overflow think could be the problem.
What I've seen most is a case where multiple versions of the same units/dcus exist in different folders/paths, and depending on almost insignificant variations the compiler/linker uses a different path and picks different versions of the units to build the exe.
I would make a huge Spring clean-up, scrutinize the lib/search paths, remove all dcus and make sure there is no duplicate versions of any unit.
And, agreed, reinstalling Delphi could help start with a clean state.
I agree with #François about the DCUs, but also want to point out an observation: sometimes it matters what was built prior to what you're building. i.e. if you have several projects that contain source code that results in various .dcu/bpl files being created in a common directory, but the project that you're concerned with doesn't explicitly call for them to be rebuilt, then you're going to end up with whatever is there. If you clear the dcus/dcps prior to building, and then find that your project doesn't build, then you are missing a uses/requires clause somewhere. Every project shoudl be able to build on a "clean slate", and not rely on leftover binaries.
That's not much to go on, but it sounds like a classic case of "bit rot". Too many things interacting in too many ways for too much time under a poorly-designed OS, leading to strange forms of data corruption.
First thing I'd do is uninstall Delphi and reinstall. If that doesn't work, try reinstalling Windows. (If it's been around long enough for this to be happening, you're probably due for an OS reinstall anyway.) And if that doesn't work, contact Embarcadero tech support.