MValdez Blog » 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 ^[1]. 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 ^[2] repository in a GNU / Linux server (with Slackware ^[3], of course) to keep my precious source code versions. I use TortoiseCVS ^[4], 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 ^[5]) 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 ^[6] in Windows or JOE ^[7] 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.

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.