Poor Man’s CSV Export

Recently I came to the point where I had to export the tables of a database as CSV files. While in FireDAC there is TFDDataMove, I wasn’t able to use it as I encountered a bug  in that component that rendered the output useless. (The bug has been fixed by Dmitry the day after I mentioned it, but is not publicly available yet.)

So I wondered how such a simple CSV export can be done with things available in Delphi. Well, here it is: Continue reading “Poor Man’s CSV Export”

I had a dream…

I had a dream.

While I was working on my current project the WOMP (White Owl Mail Provider) dropped a message at my doorstep. The message reads

You are invited to a special event. Be prepared to be picked up at 7 pm.

Point seven o’clock a coach drawn by two unicorns came up the driveway (I never knew we actually had one) and stopped at the front door. A beautiful young woman in a tight business costume stepped out, smiled at me and said: Hi, I am the Countess of Lovelace, but please call me Ada. Come in – we don’t want to be late, do we? Continue reading “I had a dream…”

When, What, Why!

A common pattern seen in Delphi code is the “code inside an event handler” syndrome. Lines and lines of code are placed inside an event handler. Not enough, these event handlers are often called directly from other places in the code – just because the code inside it needs to be executed. Take that as a big sign of code smell!

You know what? The event handler is not the right place for that code.

Extract it into a separate method – or probably more of them. Name those methods so that the name describes what the code executed is supposed to do. (It is probably not doing that, but that is a case for debugging.)

You can give some extended description in a comment to the method. If you have Document Insight (you should have the Express version with any recent Delphi), use it to display this comment wherever you hover the mouse over that method name.

Place the method calls into the event handlers. May be, you can write a little comment that explains why you are calling these methods. Don’t reword the method names here.

Remember: The event handler names tell you when that code is executed, the method names tell you what is executed and the comments tell you why it is executed.

BTW: Don’t try to be clever and rename the event handler so that its name resembles the what. You will have a hard time to find out the when! It would only be stored in the event wiring of the DFM and needs the Object Inspector to see it. It only makes the code harder to read. Keep the event handler names as given when possible. In case it is wired to multiple events, name it according to its usage (like DataSetsAfterPost), not its purpose.

18 Years of Delphi Programming

Some weeks after I got my Delphi 1 I had some contract work for a CAD/CAM system at a company located in my home town. After discussing a specific problem with their chief programmer (he was on C++) for the whole morning I was not able to convince him that my proposed solution will work.

During lunch break I went home, started Delphi and just wrote a prototype for proof. When I came back only about an hour after I left and showed him the working sample, he couldn’t believe it – always trying to find out how I did manage to cheat.

A few months later he quit…

Happy Birthday Delphi!

Do you know Build Groups?

Can you make a build in one step? (It is #2 in The Joel Test, but that is not a main topic of this article.) If you can, you have probably set up a clean build system for doing daily builds (#3 of The Joel Test) or even continuous builds based on a source control system (#1 of The Joel Test) and some of the many really useful tools available. The build system (hopefully) takes care to make sure that your sources are at least compilable for the different platforms and different build configurations as they are available in more recent Delphi versions.

You also do Smoke Testing before you check in, don’t you? There is no reason to break the build just for being lazy. But here things may become somewhat complicated, at least when you are developing for different platforms and some of the target platforms are currently not available in your working environment. But the least thing you can do before checking in is to make sure it will compile – for all platforms and all build configurations and whatever combination of those is feasible!


The Delphi IDE actually provides the necessary buttons to change the platform and build configuration for all projects in the current project group with only a few mouse clicks, but even that might sum up to plenty of clicks and actions, which is as tedious as it is error prone. Here Build Groups come to the rescue.

Build Groups are a lesser known part of the Project Manager. They are useful to compile, build or clean selected projects of a project group  for different platforms and build configurations in one step.

To make use of them you have to click onShowBuildGroups.bmp Show Build Groups Pane inside the Project Manager. This will attach a new window inside the Project Manager where you can manage your build groups.


For illustrations I am using the DataSnapDemos sample from Delphi here, but this should work with every project group.

First thing to do is create a new build group. Click the appropriate button CreateBuildGroup.bmp, enter a decent name and you end up with a list of all available projects from the current project group. By default each project comes with its current build configuration and platform.


Now click into the Configurations column of the DelphiDataSnapServer project. A second click will switch to edit mode which unveils an ellipsis button. Click it. From the configurations available for this project select the ones that should go into this build group.

Do the same for the Platforms column. You are prompted with a list of all platforms for the selected project.SelectPlatforms

After selecting the required configurations and platforms for each project in the group, you can compile, build or clean the whole pack with only one click. Very handy to make sure your changes actually compile when you are working with lots of {$IFDEF Debug}.


Oh, btw: You can have multiple build groups for different purposes or to target only part of the projects. Just select the projects you need.