The non-debuggable unit
The non-debuggable unit
I have a unit that now refuses to have blue dots when compiling. Doesn't matter if it is in debug or release mode.
- It is referenced in .dpr file
- I've searched all paths for stray .DCUs and found none
- I've have deleted .dcr, .local and .identcache files
- I've done Clean and Build, and still no blue dots and breakpoints
Once running, I can set breakpoints, but some lines will not accept them (such as in multiline statements)
#annoying
I have a unit that now refuses to have blue dots when compiling. Doesn't matter if it is in debug or release mode.
- It is referenced in .dpr file
- I've searched all paths for stray .DCUs and found none
- I've have deleted .dcr, .local and .identcache files
- I've done Clean and Build, and still no blue dots and breakpoints
Once running, I can set breakpoints, but some lines will not accept them (such as in multiline statements)
#annoying
You sure the code is actually in the binary? If the linker decides that it's not needed you don't see the blue dots. Any include file that might specify {$DEBUGINFO OFF}?
ReplyDeleteAlso non windows linebreaks might cause the editor to be wrong about the indicators. I can reproduce this when I change the EOL to Old MAC format (only CR) using Notepad++.
I sometimes get that issue also. The only way I found to clean it is to do a clean for both release and debug, then CloseAll, then quit the IDE, restart the IDE and rebuild. Usually the blue dots are coming back at the right place.
ReplyDeleteSometimes I have a similar error: the blue dots are out of sync with the source code, prohibiting to put breakpoint to some lines. It can be see that this out of sync starts at a given point in the source. I then move that part of the code before everything and usually it works. I never had time to find out what the compiler issue there is. And it is almost impossible to reproduce.
One more note about the above: just after compilation, the blue dots are at the right place but as soon as you debug, they are out of sync.
Is the code in a package? Make sure you are in the right source file.
ReplyDeleteSince it contains the core objects, I am pretty sure it's in there. Nothing would work if it's not in there. That said - the types are mostly abstract classes or classes with abstract methods, i.e. never instantiated. Still, it used to have blue dots.
ReplyDeleteAnother unit had DEBUGINFO OFF, but it was commented out. That unit shows blue dots.
The file was in ANSI format. Tried saving it as UTF8. Will that fix linebreaks?
No packages.
Testing François' trick.
Nothing helped. Not sure that I have fixed an eventual line break issue - but how to spot one in 4300 lines? Can unit size be a factor?
ReplyDeleteAbstract methods have no implementation and no blue dots imo. Blue dots are in the implementation section only.
ReplyDeleteLars Fosdal As to line breaks, open the file in Notepad++, set the line breaks to Linux style, then back to Windows, and save. No need to look for them.
ReplyDeleteI did have an experience in the past, however, where the problem was triggered by the existence in the source of a zero byte. Had to fix that with a hex editor. It did not bother the compiler, but it did confuse the IDE parser.
There are numerous methods that deal with the generic types which have implementation parts. The classes themselves are always inherited or used with a type argument.
ReplyDeleteIt's in one of these
The Structure view is littered with silly errors related to "not containing" free, classname, qualifiedclassname, classtype, etc. - but that should be irrelevant.
Have the same issue with certain generic code in XE3. As you say, highly annoying.
ReplyDeleteI sometimes managed to shoot myself in the foot, when I had the (same) unit open than the one that I intended to debug, but from a different path in the file system. Delphi would allow me to set break points and everything, but I would never arrive there, since I was looking at the wrong, although identical file.
ReplyDeleteCould this be the case?
I see this problem all the time in XE4. The fix is always to close the project then re-open it. I get the feeling it's related to the out of memory issues Delphi has with large projects.
ReplyDeleteHave you tried adding a deliberate error to the unit? If it doesn't compile you can be 100% sure that you are using the correct file.
You can also try my Unit Dependency Scanner (http://www.easy-ip.net/delphi-unit-dependency-scanner.html). It will tell you if you have any duplicate unit names during the scanning process.
Lars, just type some nonsense into the unit and compile. If you get no errors then the compiler uses a different source file.
ReplyDeleteChecked .dpr and .dproj references. All point to the correct file. A deliberate error causes the expected compilation stop. No duplicate unit references. I am stumped.
ReplyDeleteAs Asbjørn Heid mentions - perhaps this is Generics related?
What happens if you set a breakpoint just outside the troublesome unit, then trace into it?
ReplyDeleteI can trace into the unit, and as mentioned in the OP, I can set breakpoints too, once running - but they may appear as invalid, especially on multi-line statements - so it appears to be purely visual.
ReplyDeleteWith 30+ units in the interface uses, it's not trivial to make an example for QC...
ReplyDeleteIn my case it is absolutely generics related, and it only affects certain classes within a unit. Other classes/code get the blue dots just fine.
ReplyDeleteI can't recall right now what triggered it for me, but I do recall changing how I used generics for the class in question and that made the blue dots come back. When I made a new class with the original design in terms of generics use, it didn't get the blue dots.
I'll try to dig up the code and see what it was.
Asbjørn Heid I have that problem sometimes aswell. Mostly with generic methods (you know where the T is on the method itself). Also while debugging you end up in code that is definetely not executed in that call. But that is XE, in later versions that got fixed as far as I could see (still using XE in production).
ReplyDeleteStefan Glienke Ah yes, my code would almost certainly involve generic methods, likely in an already generic type. I'm using XE3.
ReplyDeleteMy XE5 just stopped being able to set breakpoints inside of RTL/VCL units. I can step into them by setting a breakpoint in my own code and F7. I then see the blue dots in the unit i step into. Yes, use debug dcus is checked in the active configuration. WTF is this sh*t?! :(
ReplyDeleteStefan Glienke I presume you've restarted Delphi and done a full build?
ReplyDeleteOf course, several times.
ReplyDeleteIt's weird and annoying. I still have it in my unit as well. It's a large unit (4300 lines) with a lot of Generics.
ReplyDeleteThen all I can think of is to consult some voodoo shaman or similar.
ReplyDeleteLars Fosdal Have you tried moving your development to another computer? Have you tried to reinstall (repair installation) Delphi?
ReplyDeleteMy team members see the same problem. Hoping to get a new laptop this month, so we'll see.
ReplyDelete