Delphi and the misplaced breakpoints case.

Debugging a Delphi applications using breakpoints within the IDE is so cool, specially if you are used to write web applications in PHP (or whatever language you prefer) without an IDE with debugging capabilities. But, what happens when your IDE behaves creative and spontaneous? In a world where you write, test, and manage releases using several platforms, Delphi should know better.

I write Windows software using Delphi from Borland. Don’t ask me what I think about Borland’s decision to drop its IDE line of products; I just hope whatever company or person that buys them the line will do better than Borland. Whatever.

As I was telling you, I write Windows software using mainly Delphi. Also, I use a CVS repository in a GNU / Linux server (with Slackware, of course) to keep my precious source code versions. I use TortoiseCVS, a very elegant CVS client, to do the usual CVS stuff in Windows. But, when preparing a source code release (you know, open-source developers release source code also) I export it, pack it and publish it from the Linux command-line. Yeah, I open a SSH terminal window (from CygWin) and do the things there. So far, so good.

Oh, wait, sometimes I have to edit the documentation files (plain text files) and I use Notepad2 in Windows or JOE in Linux (yep, Delphi, TurboPascal, JOE… pretty much the same Wordstar-like keyboard combinations). So, sometimes, only sometimes, I copy and paste text between a CR/LF line-terminated file (DOS/Windows style) and a LF line-terminated file (Unix /Linux style). Unfortunately the editors (JOE and Notepad2) allow me to mix CR/LF with LF lines in the same file. Actually I think that’s a feature, not a bug.

Well, one day I decided to do a small modification to the source code of one unit named dataman.pas. This small modification to fix a very simple bug did not worked properly, so after a quick mental code walkthrough I decided to place a debugging breakpoint in the code and run the application. But wait, Delphi did not allow me to place the breakpoint where I wanted. Mmmh… weird. Ok, let’s disable the optimizations because sometimes Delphi decides that some code doesn’t worth the time to compile it and don’t allow you to place a breakpoint there. Nop, that was not.

After two days of struggling with this problem I decided to do a deep search in the web. Actually it was not really a deep search, as I found a hint about the cause in the Delphi Usenet newsgroups. Give me a break! I was debugging a 15-minutes change (a small change that I thought it will only take me 15 minutes to do) and ended up spending two days of work. (Yes, I know, this is happening me too often).

So, what happened was the following: I edited the dataman.pas Pascal file in Linux (several months ago), effectively inserting LF-terminated lines in the Delphi code. Then, when Delphi loaded the file displayed it correctly. It compiled fine, too. But the blue dots that mark the executing lines (and the places where you can place the breakpoints) were all messed up. They were not all messed up, but only displaced. As you can imagine, debugging this was is very confusing if not completely useless.

Well, to keep it short: I used Notepad2 to set all the lines in the Pascal file to CR/LF lines and then, magically, Delphi was again behaving properly. (Later I decided to run CygWin’s unix2dos command on all .pas files). After two days, grrrrr.

Figure 1. Delphi breakpoint and compiler blue dots placed correctly.
Delphi breakpoint and compiler blue dots placed correctly.

Bad naughty Delphi, in a world where you can take your files around using several platforms, you should know better. You have a cousin, Kylix, with whom you can share source code. You really should know better.

Well, I’m done. Back to code.

Further reading:


  1. 3mp3 said,

    March 21, 2006 @ 07:41:28

    nice to hear you again dude :)

  2. DelphiCoder said,

    April 21, 2006 @ 01:55:43

    THANK YOU so much for pointing this out. I was having a very similar problem… Delphi was saying that I had a bad line, but it was 8 lines down from where it was highlighting, which was a BLANK line). Interestingly, I’ve never opened my code in anything other than Delphi, but when I went in with a hex editor, I found a bunch of stray carraige returns that were being politely “hidden” by the IDE. Once I removed those, it was showing the correctly faulty line.

  3. Michael said,

    April 24, 2006 @ 05:29:03

    Thanks also for posting this. I also am only using delphi. 6 update 2. and JediVCS. However I have been using this for years. Something has changed.. Maybe a windows xp update? Thanks

  4. mvaldez said,

    April 24, 2006 @ 06:55:24

    About CR characters appearing spontaneously in the source code, I’ve read somewhere (I don’t have any link) that when the Delphi IDE delete an unused function (for example, a VCL event without content), it may leave some CRs behind. I have not tested that theory as my problem were extra LFs, not CRs.

    Also, once I had a similar problem when I compiled a new project which included one unit named like another unit in another project (it was the same unit, I copied it from one project to another). It seems the Delphi IDE was showing me one source code but when building it was using another (already compiled) DCU file. I just renamed one of the units and then it worked. How the old unit ended in the path of my new project? I’m not sure. Maybe I mixed them up when copying one unit from one project to another. But I still think Delphi should detect these things.

    Answering Michael question about a Windows update as a possible cause… I don’t know. But we should take note that basic VCL functions (for example, string management) can use Windows API functions… maybe a change in them may cause glitches in your source code and in the IDE. But this is a guess; don’t take it seriously.


    Mario A. Valdez-Ramirez.

  5. mvaldez said,

    May 25, 2006 @ 08:57:51

    The following Borland bug report includes some information about this problem:

    Report From: Delphi-BCB/IDE
    Report #: 5175

    The IDE gets the focus on the wrong source code line during debugging.
    This is either due to
    (1) source lines that are separated by other than the standard CF-LF terminators; or
    (2) the debugger is confused about which source file is supposed to be synchronized with the execution.
    This causes grief for almost every new programmer at least once.
    Both causes of the problem should be easy to fix.
    Added note: This report may be related to QC#7358. –JohnH, May 13, 2004


    Mario A. Valdez-Ramirez.

  6. Randall said,

    February 5, 2007 @ 14:24:30

    This article saved me hours! I was trying to figure out why my breakpoints were showing up in the most random places. I opened the pas file in regular Notepad, resaved the file, and presto, the breakpoint problem was fixed!

  7. Phil Brook said,

    May 27, 2011 @ 09:27:47

    Thank you, sir! My random breakpoints resolved now too!

  8. Rodrigo said,

    November 22, 2012 @ 05:22:12

    Wow! It saved my life…. Thanks!

  9. Anna said,

    October 29, 2015 @ 05:24:32

    Dels 21.07.2009 – 03:56 Not sold mean no more update? then too bad for me , and hey where .NET CF colepmir for D2007? i only see a preview colepmir and IDE helper for BDS 2006

  10. Jordan said,

    December 18, 2018 @ 06:47:58

    Thank You!
    This save me tons of time.
    I’ve just put it trough Notepad++ and converted to ANSI, and reloaded it in IDE. Done.

RSS feed for comments on this post

Leave a Comment

Copyright ©1994-2006 by Mario A. Valdez-Ramírez.
no siga este enlace / do not follow this link