Does anyone else have this problem or is my Delphi cursed somehow?
I'll have a bunch of forms and files open in tabs in the editor and I'll be typing away and then suddenly everything stops - my .pas file has, seemingly at random, become read-only.
Sometimes I can just right-click the tab at the top and uncheck "Read-Only" and continue, but sometimes this option is checked and greyed-out (disabled), meaning I can't uncheck it and I can't make any further edits to the file. This too seems to be random.
In the latter case, the only solution is to save the file in question, which works, despite Delphi's assertion that the file is read-only, close its tab in the editor, and re-open it. Not catastrophic, really, but it's starting to become annoying.
Could it be that I am hitting a keyboard command combination accidentally to do this or is this a bug in Delphi?
I'm in Delphi 2010, Windows 7. Doubt it's anything to do with installed packages, but if anyone wants the list I'll generate it and attach it here.
Skip to last paragraph for quick Solution :)
Yes! this just happened to me. I was typing a line of code... a line in Intraweb's ServerController.... OnBeforeDisbatch.. anyways. I was typing..
If
and then I typed a Space... so If <---- then space... and then the IDE autofilled in
If True then
after the above line was in the system all hell broke loose.... hell being that the file would stay in a read-only mode....
I edited the file manually and removed the line
if True then
and all is good.
just to update: I do believe it is file size... 125K and then bang. at least on the server controller... IW10/Delphi 2010
update again... 8 hours later...
I reduced my source file (iwservercontroller) from 125k to well under 80k and all was good. then now right when I first press the control key to paste over a value the file goes read-only!! like wow....
going to reduce file again..
Minutes later...
after shutting down d2010 and reloading project... I have narrowed down the problem to using the "paste" command.... the second I tried to paste a clipboard value read-only occurred... but a harddrive hit occurred for a instant before the read-only activated!
Final solution!!! I got it! I couldn't believe there is a "Read Only" option in the Right Click Menu.... Click on the left side Pane where the check box is when the Read-Only appears! no more need to restart IDE and reload everything etc etc...
All fixed... whoo hoo
Nope... not all fixed... 3 hours later... I reactivate IDE and I am just about to paste in some data and then the file goes in read only (not explorer's file attributes) and the Pop up menu value is now grayed out!! like wtf!!
Full day later.. trying everything.. I have a solution!! first time I got it to go off read-only without using the PUM/insert Key
simply just access the unit in question that is causing read-only and do a single character change with a outside app. (ultraedit) and save. upon saving d2010 will detect outside changes and go switch back to insert-mode even with the pop up menu is disabled.... whoo hoo...
* Final Solution *
Things are all good now and not a single read-only but the solution is not too elegant in terms of keeping my text edit habits in check.. but if you open settings and change the editor to keep insert mode on you will be laughing to the bank... at least things are all good for me now.
Delphi2010-->Options-->Editor Options-->["Insert Mode"] check that option.
Seems since i have had the above checkbox clicked not a single Read-only.... good luck.
This happened once to me. I think it's a bug, I can't find an existing report for it and when you find repeatable steps the please create QC report for it.
This happens to us all the time - once a file gets over a certain size/complexity Delphi starts randomly going read only - sometimes accompanied by freezing for several seconds.
We think it's something to do with the syntax highlighter failing on certain constructs - certainly it comes and goes in waves, and I've had times where I've been reduced to editing a file in notepad just to get some work done.
It happens on units with no related DFM, so it's not a component doing it, and it's not storage related (Delphi isn't writing to the disk when it fails).
Yes, this just started happening to me after I installed Model Maker 11. I think the Model Maker plug-in might be monkeying around with the read only setting of a source file. (I've been using Delphi 2010 for a year now without this issue ever happening, all of a sudden it started right around the time I got MM11.) I haven't tried uninstalling MM11 yet though. So --- do you have ModelMaker 11?
I've seen it many, many times in Delphi 7 which rules out some of the explanations others have suggested.
I haven't seen it on 2010 but I haven't done all that much with 2010.
I also see a switch to "readonly" for pas files in the D2010 editor. None of the above suggestions have always worked for me. I am transferring a large project from D6 to D2010 and am making many necessary changes. On way to overcome the problem for a file that has been marked "readonly" and where (right-click in the editor "[ ] Read Only") has been greyed out, is to close the file and reopen it.
Related
My brand new Delphi XE shows hundreds of errors in 'Structure' panel. It shows errors like 'Undeclared FileExists at line 130' or 'Undeclared Create at line 242'. Even if it shows those errors, the program compiles just fine.
I also see that code insight is not always working. When I move the cursor over a variable, the cursor starts to flicker and no pop-up appears. Other times, it just highlight some units in red and it says the it cannot find them.
There are tricks to fix all these issues?
Update/Pseudo-fix:
I have found that restarting the IDE helps for a while.
I really help that one day Embarcadero will release Delphi ST (from STable).
:)
Yeah, CodeInsight and ErrorInsight are known to have lots of problems. They've gotten a bit better each version for a while now, but there's still a lot to be done. Andreas Hausladen, who's probably the smartest guy in the Delphi community, has done a lot of poking around in the IDE internals, and he says they have race condition-based bugs that probably can't be fixed without a total rewrite.
If these fake errors are giving you trouble, you can probably disable them, as Ken mentioned in his comment.
For me it usually helps to close the project and re-open it; the structure errors disappear.
It appears that much of the Error-Insight problems go away if you keep your library entries up to date.
This is was once pointed out by someone AGES ago on problem report for an earlier Delphi version and no-one seems to have picked up on it. If error-insight encounters a non-existent file in the LIBRARIES list it appears to just stop looking any further - leaving those annoying red-line squiggles everywhere! Trouble was, that problem report had so many entries everyone seems to keep missing that solution!
Go to Tools-Options and find the LIBRARY tab. Go through the lists and eliminate every entry that is ABSOLUTE but INVALID. You probably can and initially should leave any that have variables in them like $(BDSLIB) even if invalid, but definitely start by removing invalid ones that are declared without variables (which is what I mean by absolute). If you are gung-ho and just let Delphi auto-delete the invalid ones, all those with "unfulfilled" variables will disappear too - and that will break many things (this is another Delphi bug discussed elsewhere in this forum I believe). You may also have to repeat this with the Project-Options libraries, but be more circumspect here if the project came from someone else!
If that doesn't do the job immediately, then use the appropriate options tab to toggle the Error-Insight checkbox off and then back on again (closing the options dialog each time). That should get rid of any cached stuff, if such exists.
Deleting just some invalid entries worked for me on Delphi XE4.
We noticed why problems occur.
If there are some invalid invisible chars exist in code, this shows as error. These invalid chars sometime occurs when you copy some text and paste in delphi editor. Then, sometimes delphi paste text with invalid chars!
First you should copy all errored text and paste it on notepad++.
You will see that all text you copied will not be pasted as well.
You will see that corrupted text. You should look at code pasted, determine which code pasted as text. You should look which code could you see on notepad as pasted last char.
here we can see on picture captured: " RoutePatternObject); "
so after these chars some invalid characters occur here but we can not see!
So we select these text area after " ; " character.
Then delete and retype deleted codes again!
All red underline signatures will disappear!
I have had the same errors before and i asked the same question, this was the reply:
From another post:
You did not make a mistake. The problem is that the there are three
compilers in XE2 (like in previous versions of Delphi): the real
compiler (which works fine), the Code Insight compiler (which is
faster), the Error Insight compiler (which must be even more faster),
and the syntax highlighting parser (which is the fastest).
XE2 introduced a number of features that made the normal compiler
slower, and gave the Code Insight and Error Insight compilers a bit of
trouble. First of all, we have the new targets: Win32, Win64 and OSX
which cause the search paths to be different for each target (see
$PLATFORM directive), as well as build configuration, although there
is only one "Library path" for each PLATFORM (and not for the build
configurations).
The second complexing factor is the dotted unit names (scoped unit
names) that were introduced. Windows is no longer Windows, but
Winapi.Windows.
My guess is that these two additional complexing factors cause
problems for the Code Insight and Error Insight compilers. Note that
the real compiler still works. But the Error Insight shows incorrect
errors, and the Code Insight doesn't always work for these units.
You could try to explicitly add them to the project again (in which
case the full path will be used, like you mention in your question on
stack overflow as well).
What I found out was:
99% of the errors are due to edited files not being save right
(including references)
If you add profiles Save your .dpr, .dproj, .pas, .dfm files (save
unit, save project)
If all fails a save + restart will usually fix it
For older projects delete the .res file, it has botched paths,
Delphi will recreate it.
(Sorry for the bad initial post, Just got a Stackoverflow account, was not allowed to edit it. I hope this will suffice)
Copy and pasting the pas file into Notepad, clearing the pas file, saving, closing the IDE, opening the IDE then copying from notepad and pasting back to the pas file worked for me.
I just run into a problem that came out of nowhere...
A DFM file gets read just fine from Delphi when project is built, but when I build it from command line (dcc32) I get error Error: RLINK32: Error reading file "update.dfm" Failed read
What is more stranger another project containing same file builds with no error from both Delphi and dcc.
Does anyone have a clue of what could cause something like this?
I tried to build from another location, still same.
Operating system is Windows Server 2008. Permissions seems correct.
Use SysInternals Process Monitor, and watch when it goes looking for update.dfm.
You'll probably see DCC32 frantically searching everywhere for update.dfm (except the place where it is). Or maybe it will find it, but OpenFile fails with an error.
Either way: you'll find out what exactly is going on.
To try and narrow the cause of the problem down, open the dfm with a text editor, and gradually remove properties and save until the build works. That would at least indicate if it's a problem with a particular component in the dfm.
The main thing that is different with a dcc32 is the library path in the environment options. When you build from the IDE this is used. When you run dcc32 you need to specify this.
You can do this by setting the library path for the -I and -U options on dcc32, or you can use a dcc32.cfg file to hold all your configuration for the build.
RLINK32 can signify duplicate resource so consider renaming one of the forms so as to avoid the clash. Having said that hopefully the library path should resolve the issue.
I've seen this happen when you remove a value from an enum type and that value was being used in the dfm. The next time you opened the dfm the IDE would put garbage text in where the value was. Delphi 2010 if that helps.
I would just open the dfm in a text editor and remove the corrupt text.
I found this after having the same problem which seemed to happen randomly from time to time if I changed a bit of code of added a copied a component, this time the only difference I made was changing an = to <> but changing it back worked fine except now I've changed something else it's happening again - hence the reason how I found this. Being quite a newb I didn't really understand some of the other bits mentioned here but I just found by building the project first before pressing F9 seemed to work.. just for now at least.
Hope this helps someone! :)
Sometimes, when coding in RAD Studio 2009 (Delphi), suddently the behaviour of the code editor changes. After such an event, a selection is no longer cleared on character input. This often happens after a session of very intense coding (many characters per second!), so I might accidently hit a keyboard (shortcut) combination.
Is this the case? How to "fix" the issue? (I want my selections to be ereased upon character input!)
This is a bug, and you don't have to quit and restart to fix it. Just hit Insert twice (which changes the text entry mode between Insert and Overwrite and then back) and your text selection will be back to working normally. It's notoriously difficult to pin down, though from my own experience it seems to have something to do with mixing SyncEdit and Undo. If anyone's able to find any way to reproduce this consistently, please send it to QC.
When this happens, you should be able to toggle the "Persistent blocks" option on and then off again. Go to "Tools | Options | Editor Options". Turn on "Persistent blocks", and click OK in the dialog. Then go back and undo that operation, and the editor should reset itself.
BTW, this is definitely a bug. If you are able to reliably reproduce it, a test case submitted to QualityCentral would be most useful.
Quit and restart the IDE is probably your only solution.
I have found some IDE/Editor instabilities too. It's probably a bug. Restarting the IDE solves the issue.
And I haven't found it in 2010 yet.
A fairly complex project was muddling along with lots of work done last night when I decided to turn in. But thinking about adding some gestures got me up after three hours of sleep and I went at the code again, which was a mistake. I added the gesture manager and then sleepily hit the F1 key to look up the help on gestures. Coming back from THAT mistake, Delphi 2010 froze. I had compiled just before adding the gesture manager, so I presumed no big thing. I was wrong. When I used task manager to close down D2010, things didn't come back right. Lots of complaints about Nexus databases. Then, on compiling I through a fit about the res file. In and out of the IDE, renaming the res file and letting it be recreated. But on run, the program complains about "Resource 1 not found" and then proceeds to run, ignoring the INI file settings to place the form on the screen. Furthermore, it has the interesting side effect of making controls (NextSuite's FlipPanels) DISAPPEAR when clicked, instead of expanding the panel. All quite ... mind-blowing. My backup is about 21 hours old and I'd rather not lose the work done in the interim. Suggestions?
When I deleted and recreated the .RES file, Delphi didn't automatically default to turning on version information. A routine from one of the procedures in a closed routine was trying to read that resource and producing the 'very' informative error.
Lessons learned from this fiasco:
Turning on version resource in the IDE does NOT survive the recreation of the resource file
You have to have source code to all of your third party libraries.
Ahhh well, live and learn. Time and time again.
This is driving me crazy. I'm not going to take it anymore. I'm going to ask, even at the risk of eternal public humiliation! (If it's something really obvious or that I've done to the system myself).
For reasons I've never quite had the patience to work out, every so often the form I'm working on in Delphi 2007's visual form editor goes 'pseudo-read-only'; I can add new components to the form, I can move/resize existing ones (and change any properties in the Object Inspector), and I can select a component and 'copy' it to the clipboard.
But I'm completely unable to cut a component from the form, or paste a new copy down. I don't believe it's to do with the 'Lock Controls' Edit menu option as I can toggle this on or off and it has the effect it's supposed to - this disappearance of Cut & Paste happens on the right-click context menu, from the keyboard and from the main Edit menu - it's as if the form has become read only to thing to do with the clipboard.
If I close the form in the IDE and then reopen it, everything starts working fine again (just as D1, D3, D5 and D7 always did for me, previously).
I'm not going mad, as I'm sure I read something about why this happens on a newsgroup once and it's caught me out from time to time many many times in the last few months, but I've failed to find the newsgroup reference this evening and I've decided that, as more and more Delphi users seem to be making use of StackOverflow, it was worth asking here.
Help - when I'm doing lots of form-work it drives me absolutely mad!
you can try to download the clipboard monitor application to see if anything is messing with your cut/paste. I have noticed simular problems when running in a VM, the VM gets confused as to what is in the clipboard and won't let me cut/paste again until I go back to my host application open something else (notepad works fine) and copy something fresh. I think thats more a problem of the other clipboard monitoring applications on my system than anything else.
I'm using copy/paste "desing" a lot, but they never went away.
Are you using some other IDE addins that mandle with copy/paste?
I think it is a known bug in the IDE, but I can't seem to find any references to it. I also have experienced this problem. You might want to try IDE Fix Pack, although it does not claim to fix this problem.
Check that other apps can use the clipboard too. Sometimes I am paused in the middle of a clipboard operation in my app, which stops other apps opening the clipboard. Can be confusing!
The virus detector app: Webroot SecureAnywhere stopped pasting from working - when I disabled this dumb virus detector - all was good again.
I think you should try the Desktop Settings. I had the same issue and after changing the Setting to Debug, Cut/Copy started working.