In VS on Mac OS when I try to rename a file then if the file exists with a different case it won't let me rename it. Is there any way around this. Seems like something I would have thought would have been fixed 20 years ago :-(
not sure I understand your issue, are you trying to rename a file to a name that's already exist (with or without the same case)? because if that's the case, you won't be able since apfs isn't case sensitive as far as I know.
Related
Last time it actually worked: Monday 27/07/2018
I've been using specflow for around 2 years now. But as of today (this week) I've got an issue I never encountered before. When changing even a single letter in the .feature file as usual Specflow will regenerate the .feature.cs file. But there it's going wrong. The file becomes blank with just a single line which is a reference to my temp folder C:\Users\Me...
The thing about my username is that it's my real name and it contains a special character: "ë". Could there be a new bug introduced in the newest version from monday 6/08/2018? If so, is there a workaround while waiting for it to be fixed? Or is something entirely different going wrong?
There is a bug in the latest version of the Visual Studio extension which has problems with special chars in the username, because it's used in the path to the temp directory.
There is a post about it in the forum (https://groups.google.com/forum/#!topic/specflow/977_H2ICwT8).
The quickest way to workaround this, is to change the generation mode to AppDomain (Tools\Options\SpecFlow)
The better way is to switch to the MSBuild generation, as we will remove the AppDomain generation mode in the next months.
I'm having some kind of problem with my project that me and my friend is working on. When I try to open the project that I've been working on it gives me an error message saying that "one or more lines were too long and have been truncated" and thus I can't see my code or GUI. When my friend opens the project on his computer (The project is on dropbox so it's the same file) there's no problem at all. I've googled but couldn't find anything. I just did a repair of RAD Studio but no luck. We have 2 forms and a unit that we use, the unit and the mainform isn't working for me but the second form is no problem.
Thanks!
Make a copy of your project directory.
Search your harddisk for XXXX.pas and XXXX.dfm
Hopefully there will be some temperary files that match - like "mylostform.dfm.~1307~" . copy the newest to your project directory, and rename them to "mylostform.dfm" and "mylostform.pas".
Kind regards,
Geir Bratlie
From the comments, you have Dropbox, and the Restore functionality is available, but using it would cost you a week's worth of work.
If I was in that situation, here's what I would do:
Copy the current file to somewhere else (My Documents, for example).
Use Dropbox Restore to get the old version that works.
Make a copy of this, because you're going to be modifying it
Ensure that you can open it in the IDE.
Use Beyond Compare to open the two files side-by-side. (If you don't have this, you really should!)
If they're completely different from each other, you have a serious problem. If not, you'll see the changes you've made. Start copying changes one at a time, and after each change, save and try to open it in the IDE.
At some point, you won't be able to. That's where your problem lies. Now you can fix it!
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. :-/
After many months of postponing it, this week, I finally started using a new Windows 7 Professional PC for actual development (which is 90% still done in Delphi 7 with some of these programs still using the Borland IDAPI to access Paradox files). The previous development pc was still an XP-one.
Every thing works except for one thing: somehow the settings of the IDAPI and BdeAdmin configuration files are messed up or they are read/written in different locations. To be more precise, it looks like two configuration files are active.
It must have something to do with rights or settings being read/written in the wrong folder or registry setting, but after searching for it for a couple of hours, I give up.
Anyone had any problems with this, before ? And if so, hopefully, has any one solved this problem ?
Thx for any thoughts/solutions ...
My guess is it has something to do with the fact that Vista and Windows 7 don't allow programs to change files under the C:\Program Files folder. They create a copy of those changed files in a virtual store, the process is known as virtualization. The copies end up in the hidden appdata folder of the user account and can be found in the Local\VirtualStore\Program Files folder. The structure in that folder reflects the one in the actual Program Files folder.
Programs that access their files in the Program Files folder using a "hardcoded" path, will always get the original - unchanged - file contents.
Solution: running the apps in a virtual XP system or upgrading the apps is probably your best bet.
You could try to run the apps elevated. That is: right click them and choose Run as Administrator. Please note that it isn't enough to be logged in as an administrator. Even administrators run all processes unelevated by default. Instead of right-clicking, you can also create a shortcut and set the Run as administrator for the shortcut - the checkbox for this is on the compatibility tab of the properties dialog. No guarantees though that this will alleviate the problem.
Since IIRC D7 setup allows you to configure paths in multiple ways, maybe simply do a reinstall outside "program files"?
Afaik this solves several vista/w7 problems.
I am having some trouble updating UMDF drivers using "devcon" during a
standard code-deploy-debug cycle. The problem is that "devcon update" isn't
really updating anything unless the version number or the date of the DLL
file and the INF file has changed from what is stored in the system's driver
cache folder. After a maddening series of experiments I've discovered that
one way to force the thing to use the latest files is by doing the
following:
Change the parameters passed to
"stampinf.exe" in "makefile.inc" by
explicitly setting a version with
the "-v" option.
Modify the
resource script file ("DRIVER_NAME.rc") to first define
VER_USE_OTHER_MAJOR_MINOR_VER
before including "ntverp.h" and then
explicitly define
VER_PRODUCTMAJORVERSION and
VER_PRODUCTMINORVERSION. You'll
note that this system does not allow
us to change the build and the
revision numbers. On Win7 this
seems to be fixed at 7600 and 16385
in "ntverp.h". Is this by design?
So, I first modify "makefile.inc" and set the "-v" option to something like
"1.1.7600.16385" manually incrementing the minor version for every single
build and then modify the RC file and update VER_PRODUCTMINORVERSION with
the same number.
Alternatively, if I run a command prompt under the SYSTEM account and go and
delete the driver cache folder in
"C:\windows\system32\DriverStore\FileRepository\DRIVER FOLDER" before
running "devcon" then that works too.
Now, I am thinking I am missing something fairly basic here as this seems to
be a rather painful way of doing it. Please help! Thanks!
Why can't you just unplug the device and replace the unloaded DLL? You shouldn't need to reinstall the driver, just replace the module. Note that you shouldn't do this during production or anything that has to do with customers, but if you're writing a driver, just slam in the new module with the same version number.
On Win7 this seems to be fixed at 7600 and 16385 in "ntverp.h". Is this by design?
Yep, at least until the next service pack
As Paul Betts has suggested above, the way to go seems to be to simply replace the UMDF DLL directly in the driver folder (for e.g. c:\windows\system32\drivers\umdf\) after disabling the device either in the device manager or using "devcon". I'd asked this question on Microsoft's device drivers newsgroup before posting here but hadn't got a satisfactory response - but some folks ended up responding there after I posted here! So I'll put up a link to that post as well:
http://bit.ly/6PDxKT