Delphi 100 251 Rev 1.0 Software Download
Billi Plancarte
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 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.
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.
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.
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.
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.
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.
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.
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 $IFDEFs, 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 $IFDEFs - 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.
Just had a run-in with this problem - opening an old .dproj (presumably from XE10) in D11.Compile worked fine, the debug dots (balls) were there.However upon run, the debug dots disappeared and any breakpoints set, turned green.
If anyone could shed the light on where did this setting come in the first place that would be great ..Someone more experienced just kindly explained to me that this screen in Project->Options drives the loading of debugger symbols - specifically the Load all symbols checkbox..
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.
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.
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.
e59dfda104