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! :)
Related
From time to time, when I load a project into the XE6 IDE, the following error occurs
This error results in the TZConnection component being removed from the Datamodule for some inexplicable reason. Note that the project has been loading without issue for ages and just out of the blue, this occurs.
Has anyone seen this before and know of a way of stopping it from occuring ?
It also occurs with other components, not always the TZConnection component but mostly ZConnection.
Like I said before, this appears randomly. I could close project A, open project B then close it and return to Project A and bang!, the error occurs.
Any clues ? (note that this also used to occur in Delphi 2007)
The Zeos libraries are themselves causing this problem.
To see why, and to fix it, use Delphi to launch a second instance of Delphi, and debug the issue directly.
I wrote a blog post showing exact steps here.
The key is to set the executable that will be run for your zeos package, be sure to build them in debug configuration, and then click the Run button on the Delphi IDE toolbar. A second delphi instance will start. Open the affected form but be sure to be using the IDE instance that is Being debugged as opposed to the one which is currently doing the debugging, when the exception occurs that is causing your component to delete itself, you will be able to step into the package code and see the problem.
I suspect a DLL-hell path issue. (Multiple copies of Zeos or other core BPL/DLLs in your path.)
Actually, it doesn't sound that inexplicable - it's probably caused by an exception occurring as the DataModule (or some form with db-aware components connected to it via properties) is being loaded into the IDE (see below). Have you tried checking that wherever your ZEOS .BPL files are located is on your system Path? Likewise any .BPLs they depend upon - see the "requires" clause in the .DPK file(s) for Zeos.
This sort of problem arises fairly frequently with flaky DB components, maybe more so than other types of component because db components more frequently involve linkages between datamodules and forms, e.g. when db-aware components on the forms are connected to others on the datamodule.
So, sometimes, whether this sort of problem shows up or not depends on the order in which the IDE will re-open them - try closing the project with only the dm open and then re-opening it. A bit of experimenting with which datamodules and forms are open in the IDE and in which order may help you pin down the problem. If/when you have a reproducible sequence of steps to provoke the problem, report it to the authors.
A fairly reliable way to determine whether the problem is being caused by an exception as a project loads is to run one instance of the IDE inside another. As long as the first ("outer") instance of the IDE has the debugger set to "Break on Language exceptions" it should be able to take you straight to the source of the exception (assuming it occurs, of course) when the project is loaded by the second instance. It may take a few goes to "catch it in the act" of course, but it is hugely satisfying when you manage to. Good luck!
Unlike MartynA I doubt this would be caused by an exception.
I would more likely expect such issues to be caused by windows path environment variable being too long.
Unfortunately still many component vendors and even some programs modify "windows path environment variable` to make their own files accessible by other programs.
And when windows path environment variable fails to provide sufficient information windows will try to find the files in default system directory which is C:\Windows\System32
So I would strongly advise checking the windows path environment variable to check its length.
The easiest way to do this is by simply starting the command prompt and typing in path directive or perhaps path >> D:\path.log to export the path environment variable information into a file for easier reading in case if it is long.
EDIT: BTW I just checked my path environment variable and I see that I will have to do some cleaning because it contains entries for both Delphi XE8 and Delphi XE 10 Seattle file locations even thou I have removed Delphi XE8 from my computer. Not to mention some entries from some programs that I have removed quite some time ago.
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.
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.
From time to time I lose breakpoint functionality in Delphi.
I thought this to be a Delphi 2009 issue but now I have also it in Delphi XE.
In Delphi 2009 by deleting .dproj file I made the breakpoints work again.
In Delphi XE I am not able to make breakopints appear. I have update 1 with all hotfixes applied.
Does anyone have a solution?
Debug info isn't present in the file.
Make sure that you're using the Debug configuration. (Project Manager tree, expand Build Configurations, make sure Debug is bold. If it's not, right click Debug and choose Activate from the context menu.) Make sure you then do a Build of your project, not just a Compile.
If that still doesn't work, go to Project->Options from the IDE's main menu, click on Compiling under Delphi Compiler, and check the Debugging section on the right half of the window. Make sure that Debug Information and Local Symbols are both checked. If you're trying to trace into the VCL's own source, also check Use debug .dcus (you'll want to turn this off and do a full build of your project as soon as you're done, as it gets annoying when you're debugging normally). Again, you'll want to build and not compile.
If all of the above fails, another possibility is that the code unit you have open in the Code Editor isn't the same one being seen by the compiler. Make sure you don't have multiple copies of the file on your computer in a location that the compiler might find first. If you're not sure, delete the .dcu files with that unit name and then do a build of your project, and see if the newly created .dcu is in the location you'd expect.
I found a better way.
From the Project Manager tree, right click on the project and choose "Clean" from the popupmenu.
The breakpoints reappear magically and it is a very fast method.
I suspect this happens when you have done a release build, with debug disabled. Then you switch back to debug configuration and do a compile rather than a build. The files where you can't set breakpoints correspond to those with DCUs produced by a compile with debug disabled.
Simply doing a build to re-generate all DCU files will make your breakpoints work again.
Here's one more reason to misaligned code vs breakpoint markers (blue/red "pill" in the gutter).
The editor recognices three different line endings,
CRLF (Carriage Return - Line Feed pair)
CR only
LF only
Of these, CRLF is the default in the editor.
The compiler however, doesn't seem to consider CR only as a line ending, only CRLF and LF only. Thus if your source file happens to have one or more CR only, the "blue pills" will be offset from the source.
You might have got source files with CR only EOL (end of line) character from e.g. the internet. I recall MAC OS used CR only as EOL.
To verify the EOL's in your file, you can turn on the displaying of EOL's in the editor
( Tools - Options - Editor options - Source options - Show line breaks).
The symbols look weird (see images below), but are just C on top of L for CRLF, C on top of R for CR and L on top of F for LF.
The following images show the normal EOL's (CRLF) and the EOLS's after I forced CR only for one line and LF only for another line in a hex editor. As said above, it is the CR only that offsets the break point markers from the source code.
Normal CRLF EOL's:
One line with CR only and one with LF only:
Fix
To reset all EOL's to CRLF, untick Preserve line ends in Editor Options
( Tools - Options - Editor options),
make a trivial change, so that the file is marked as modified, close the file, save changes to XYZ.pas? YES, and reopen.
Now all line endings are CRLF. Rebuilt the project and all the breakpoint balls will be in the correct locations.
Turning on remote debugging symbols did it for me (nothing else worked). Project > Options > Linking and check Include remote debug symbols.
I had the same problem with XE4. This is why I found this article a couple of hours ago. None of the above solutions worked for me. The correct solution for me - up to now - was to add "remote debug symbols" option. Strange because I don't use remote debugging. Anyway it looks OK now.
It is a bug, restarting Delphi will fix your problem.
Try remote debugging to your local PC.
Why it works: (source)
When you debug Delphi projects locally, RAD Studio does not use your RSM debug file because the compiler holds the symbol tables in memory. However, when you debug Delphi projects remotely, you must generate an RSM debug file that contains those symbol tables; otherwise, RAD Studio does not stop at your breakpoints.
Of course, you must first configure your project's "Linking" option "Map file" to "Detailed" to generate the *.rsm file. See Overview of Remote Debugging for how to get started.
I had a related problem: I lost the breakpoints in a particular file, but the other files were fine. What had happened was that I had renamed that file, but unknown to me the DCU for the old file was still being used because it was being referenced in a "uses" clause somewhere.
The solution is to manually delete all the DCUs (doing a "clean" is not enough because the old file represented by the DCU is no longer in the project) and rebuild. You will get a compile error showing the bad "uses" clauses.
Another reason for not working breakpoint could be (often tested with delphi5):
Too many procedures in a unit.
The solution is to move procedures to another unit
Although this is an old question I can confirm that this is still an issue in the current version of Delphi 10.3 Rio.
The answer above regarding line endings
https://stackoverflow.com/a/53360447/6445054
Solved the issue for me I had imported some very old Delphi code which had CR line endings
in a couple of places, as soon as I started moving code around the debugging broke completely.
The option to turn line endings on has moved slightly in Rio it's now
( Tools - Options - Editor - Source - Show line breaks).
In delphi 7 there seems to be a real bug on setting breakpoints.
I had a unit where many texts are definied in a
const constname : array[0..x] of record-type = (...);
in interface section, where record-type has some AnsiString items.
In the implementation section there are some procedures.
In some particular cases, when I set a breakpoint anywhere within a procedure, delphi does not stop at it!
Remarks: all options for debugging are set properly (as for F7 causes delphi stop at the "begin" of the program, blue dots are visible in the whole unit the line stays red while executing the app) and all DCUs that have according PAS files were deleted from all of my disks and within all folders, before I did a complete build on the whole project. So no wold files should hang around anywhere.
For testing, I renamed the PAS to another name, never ever used before, and surely nowhere else on any disk, then adapted all sources and recompiled, just to be sure that delphi and I are looking at the same PAS file - but the breakpoints did not work either.
But there another, very weird thing happened: the text consts (!) changed within my executable (not within exe file, but obviously within memory)! Those texts were checked for correctness during program start, and sometimes it complained about errors! Display of the texts in a messagebox showed, that there was changed a sinlge character within that texts, that are defined as const. For test, I tried to assign something to that consts within my code, but, as expected, compiler complained, so it cannot be an ordinary assignment that causes the change of the text. Must be a wrong pointer. Weird.
So, hours of testing followed, looking for any source code that might have set up a wrong pointer that later could cause that change in a text const. I placed the messagebox into the initialization section of the first unit within the chain of unit initialization I was able to edit, but the changed char was already there! Must be changed very early during startup of my application, then!
Finally I figured out, that the char that appeared in my texts always was an $CC - which exactly is the assembler code for INT 3, the code that delphi is using for setting a breakpoint. And when moving a breakpoint within that unit a line up or down, the position of the changed character also moves some chars left or right! And the number of characters the wrong one moved just correlated with the estimated amount of assembler coded bytes the concerned lines needed. Setting two breakpoint in lines near each other, suddenly two characters changed! When removing all breakpoints from that unit, the text remained unchanged!
So there's only one conclusion: delphi itself is changing that texts when trying to set a breakpoint and fails to do so. I was unable to get rid of this bug. None of the tips about re-synching delphi's internal bookkeeping of source and object code files did help me out!
As the concerned unit mainly consisted of {$I} lines between multiple {$IFDEF}s, for including some different, but long pascal texts, I considered delphi having problems on too long inclusions or on evaluation of conditional compiler directives. So I removed the includes and put the source text immediately into the unit, and removed the {$IFDEF}s - which compiled without errors, but setting breakpoints also changed my text constants, instead of stopping execution. All the same!
I solved this for now by splitting the unit into two units, one holding just the text consts in it's interface part, and a second one to hold the procedures. And now, without changing any compiler nor linker settings, all breakpoints do work like expected and not text is changed any more!
So, if breakpoints do not work for you, while you are sure they should, possibly delphi is the culprit and fails to set the breakpoints at the correct place. In case of it is changing just some texts, maybe that never gets to your attention. Splitting the unit helped me out, maybe that helps you, too.
If the file you're trying to set breakpoints in is part of a DLL, you need to make that DLL active by double-clicking on it in Project Manager so it turns bold, and then build it. Then the blue circles will show up next to lines where you're allowed to set breakpoints.
I solved my issue by making sure Debug was set to Local:
In my case, I was setting breakpoints in a unit that whilst open in the IDE was not part of the currently active project. Such breakpoints also show as green. IOW I was not on the right page at all.
(I discovered this after trying all of the above .)
If the project group uses packages (BPLs) ensure that none of them have any compiler warnings regarding implicitly imported units. If these exist you will only be able to step through the code via the CPU debug window.
Bit late answer but I stumbled on this problem too.
If I activated the MyPackage.bpl (bold) in the project manager with the debug configuration, then compiled it, I could see the IDE registered the debug information (blue dots on left of editor).
But when I activated my MainProject.exe (the one using MyPackage.bpl), those blue dots would disappear, indicating that the debug information is no longer present. After some head scratching, I realized that I did set up a dependency (right click on MainProject.exe -> Dependencies) on the Release configuration of MyPackage.bpl and not on the Debug configuration.
Each time I compiled MyProject.exe, it would link with the Release configuration, not the debug configuration!
So check your dependency configurations!
I had MSBuild checked under Delphi Compile (we do MS Builds). That was preventing breakpoints from working. Unchecked and it works.
By using F9 to run the app, breakpoints will work as expected. I am using XE4 and I do not know if this will "fix" prior versions of Delphi.
Since this is the best resource I found on this issue when encountering this problem with a new install of Delpi XE on a new laptop, I will just add in one more possible answer for Delphi XE.
If you are using a two monitor setup and the code editor window is on the 2nd monitor, the tooltips will not show. Works fine if the editor window is on the primary monitor. Very frustrating. May be a driver issue.
My system configurations are a follows Delphi2010 on windows 7 professional. I have a problem with some of .dfm files in the project.
I got it as follows. First of all I needed to change some datatypes of TOraQuery component fields from TStringField to TWideStringField and I started it doing manually like opening .dfm change one by one (Find-Replace) everything was fine later on because our project is huge I decided to change everything at once so by using Notepad++ editor and by using option Find in Files and replace all I did replacement. So after this operation I started getting this error like 'TWideStringF class not found' when I wanted to open particular .dfm file. I cannot open this .dfm files even if I press ignore.
PS: Even when I try to open files that has errors in Notepad++ editor to get the line TWideStringF I cannot find it.
How to solve this problem ?
Can anyone give me a clue ?
thank you.
Try finding the "TWideStringF" in ALL your source code first to know where the problem is comming, after that, well, all dependes on what you find!
The Delphi IDE need to be able to find the classes specified in the DFM. It creates instance of these on the design surface for you to interact with.
Editing a DFM by hand is a common practice. I do it often, as sometimes it is faster than any other method. However, it comes with a problem if the class or property can not be found it can cause the DFM not to load. So extra care must be taken to insure that manual edits done correctly.
In this case you can restore the file, and redo the search and replace, or to look at the instances where it's broken and fix them all by hand.
Search for: TWideStringF I suspect you will find that is missing the remaining ield required. Note: Searching in IDE will not work as it won't search DFM files.