Translating Windows messages to strings

 Delphi  Kommentare deaktiviert
Aug 242014

I could not find anything like this so I wrote it myself:

This class translates most Windows message ids into their symbolic name.

  TWmMessageToString = class
    function MsgToString(const _WmMsg: Cardinal): string; overload;
    function MsgToString(const _Msg: TMessage): string; overload;

The names are taken from

  • Delphi 2010′s messages.pas
  • Delphi 2010′s controls.pas
  • Wine

It seems pretty complete, but if a message cannot be found, the MsgToString methods return its hexadecimal and decimal representation.

The code is part of my dzlib its the u_dzWmMessageToString unit.

Aug 242014

In an older blog post I wrote about AutoComplete for TEdits using SHAutoComplete.

I just actually tried to use that function in one of my applications and found that there is a quite annoying problem with it: If you have set the OK button’s Default property to true (so it gets “clicked” when you press return), selecting an entry from the autocomplete list with the return key also closes the form, which is usually not what the user wants.

I turns out that I am not the first to stumble upon that problem.

The suggestion posted there by mghie is a bit ugly because it hooks the Application.OnMessage event which might conflict with other code that uses it.

I had another problem anyway (see below) so I extended a class that hooks a TEdit’s WindowProc method instead. Here is the code:

procedure TAutoCompleteActivator.NewWindowProc(var _Msg: TMessage);
  if (_Msg.Msg = CM_WANTSPECIALKEY) then begin
    if (_Msg.wParam = VK_RETURN) or (_Msg.wParam = VK_ESCAPE) then begin
      if IsAutoSuggestDropdownVisible then begin
        _Msg.Result := 1;
        Exit; //==>
  inherited NewWindowProc(_Msg);

The IsAutoSuggestDropdownVisible function is directly taken from mghie’s answer:

function EnumThreadWindowsProc(AWnd: HWnd; AParam: LParam): BOOL; stdcall;
  WndClassName: string;
  FoundAndVisiblePtr: PInteger;
  SetLength(WndClassName, 1024);
  GetClassName(AWnd, PChar(WndClassName), Length(WndClassName));
  WndClassName := PChar(WndClassName);
  if WndClassName = 'Auto-Suggest Dropdown' then begin // do not translate
    FoundAndVisiblePtr := PInteger(AParam);
    FoundAndVisiblePtr^ := Ord(IsWindowVisible(AWnd));
    Result := False;
  end else
    Result := True;

function IsAutoSuggestDropdownVisible: Boolean;
  FoundAndVisible: Integer;
  FoundAndVisible := 0;
  EnumThreadWindows(GetCurrentThreadId, @EnumThreadWindowsProc,
  Result := FoundAndVisible > 0;

This works fine in my program compiled with Delphi 2010 and running on Windows 8.1 (your mileage may vary).

Now to the other problem mentioned above:
In the old blog post I published a TEdit_SetAutocomplete function that activates autocomplete for a TEdit control. This function works fine as as long as you don’t try to call it in the form’s constructor. If you do, it does nothing. The reason is that the TEdit’s handle gets destroyed and recreated after the form’s constructor was called, which results in autocomplete being turned off again. One option would have been to put the function call into the form’s OnShow handler, but I am no fan of distributing code that in my opinion belongs into the constructor to these event handlers, so I wanted a different solution.

It turned out that I already had one in my dzlib.u_dzVclUtils unit: TWinControl_ActivateDropFiles returns a TObject that hooks the TWinControl’s WindowProc and handles the WM_NCCREATE and WM_NCDESTROY messages. I refactored that class a bit to create a generic TWindowProcHook ancestor and derived TAutoCompleteActivator from it. Its WmNcCreate method now looks like this:

procedure TAutoCompleteActivator.WmNcCreate;

procedure TAutoCompleteActivator.SetAutoComplete;
  TEdit_SetAutocomplete(FCtrl as TCustomEdit, FSource, FType);

So every time the window handle gets created anew, it activates autocomplete for it again.

The full code can be found in my dzlib library on SourceForge. It’s in the u_dzVclUtils unit.

Sabotaged by Windows Update

 Delphi, Windows  Kommentare deaktiviert
Aug 152014

Microsoft released a Windows Update this week that caused quite a problem for Delphi developers still using Delphi 2006 to 2010. When starting a second instance of the IDE they now get the error

Cannot create file C:\Users\Admin\AppData\Local\Temp\EditorLineEnds.ttr

The update in question is a security update for all supported Windows versions and has the number KB2982791. It prevents the file EditorLineEnds.ttr to be created/overwritten because that file is a Truetype font and changing it while it is active is apparently a security risk.

Unfortunately this prevents a meaningful use of these Delphi versions. So what can we do?

There is this question on StackOverflow from which I got the above information. As far as I know there are the following workarounds:

  1. Uninstall the Windows update KB2982791, which might not be such a good idea. After all it’s a security update. Daniel Magin blogged about this.
  2. Use Andreas Hausladen’s IdeFixpack (Delphi 2007 version, beware that version 4.4 does not work under Windows 8, version 4.3 seems to work), (for later Delphi versions). Note that the editor option Show Lineends will use a different character if you use this fix because the IDE won’t load the EditorLineEnds.ttr font any more.
  3. Rename the file every time you want to start Delphi. This is what I will be writing more about.

Of course you don’t want to rename the file by hand every time you start Delphi. So either, you use a batch file to do that for you (see Daniel Magin’s post), or you use the program I wrote for this particular task.

It’s called dzEditorLineEndsFix and is a Tray Icon application that uses FindFirstChangeNotification / FindNextChangeNotification (I always wanted to use these API functions but never had an appropriate use case.) to detect when the file is being created and then moves it to its own unique subdirectory under %temp%.

In theory it will clean up after itself, but that might fail because the file(s) are still in use. So once in a while you should have a look into your %temp% folder and delete all subdirectories called ttr* from it.

Sources are available from the dzEditorLineEndsFix page on SourceForge. There is also a precompiled executable if you don’t want to compile it yourself and trust me not to have added a Trojan to it ;-)

Aug 142014

We are using a bar code scanner to scan the serial numbers of all hard disk drives we buy. This is supposed to make it easier and less error prone to put them into an Excel list for tracking their whereabouts (we use quite a lot of drives for storing video data).

Of course, when I bought 4 TB SATA drives for setting up yet another Linux server, I too put these drives in the list. And since I am a lazy bastard™ I borrowed the scanner to scan them. It worked like a charm so I returned the scanner and started building the raid.

I put labels on the drive bays with our internal number, so in the case of a drive failure I could use the list I mentioned to find out which drive to swap out.

One of the drives apparently was defective to start with, so what did I do? I asked mdadm which drive it was (/dev/sdg) and used

ls -l /dev/disk/by-id

to find its serial number.

lrwxrwxrwx 1 root root  9 Aug 14 08:59 ata-ST4000DM000-1F2168_Z301W61Y -> ../../sdg

Then I opened up the list to find the drive’s internal number. To my surprise, none of the serial numbers in the list seemed to match.

It turned out that on my computer, because I use a UK keyboard layout, the scanner swapped Y and Z. So, in the list the drive had the serial number Y301W61Z while in reality it was Z301W61Y.

Fun with computers, not.

Aug 132014

If you ever had to change the motherboard of your computer and wanted to keep the Windows installation on it, you might have encountered the dreaded Blue Screen of Death with an unhelpful error code.

In my case, this was a Windows 7 installation where the on board SATA controller started to misbehave. These problems didn’t show up in Windows but only when I did my weekly backup using CloneZilla. I wonder what would have happened if I had happily continued to use this computer because Windows didn’t warn me?

First I put the hard disk into a different computer, started CloneZilla and made a backup. No errors showed up, so it wasn’t the hard disk but the controller.

Then I threw out the old motherboard and took a new (cheap) one that still supported my old Dual Core processor and RAM. Connected everything and booted the box. I was expecting for it just to work. This is Windows 7, one of the most modern operating systems available, so driver issues should be a thing of the past, right?

Well, not so. Windows 7 crashed and rebooted, crashed and rebooted, crashed and rebooted. After a while I got tired of this ;-) , pressed F8 for the boot menu and disabled automatic reboot on errors. Then I got the BSOD in all it’s glory: Error code 0x7B, meaning “INACCESSIBLE_BOOT_DEVICE”.

In the olden (Windows XP) days this was a symptom of the SATA controller running in AHCI mode and Windows expecting IDE mode or vice versa. Apparently this is still the same with Windows 7 (When will you ever learn, Microsoft?).

Unfortunately the new board’s BIOS did not really allow me to switch the SATA mode (it seemed to allow me, but it didn’t make any difference). So after swearing a lot I turned to Google and found … a lot, most of it not really helpful. Hours (literally!) later, the solution turned out to be the following:

To allow Windows 7 to boot in IDE as well as AHCI mode, I had to enable the following drivers (by setting “Start” to “0″ in the registry, there might be other options to do this):


The first two allow Windows 7 to boot from SATA in IDE mode. The second two allow Windows 7 to boot from SATA in AHCI mode.

So, why isn’t that the default? I have no idea.
(Do I have to point out that Linux booted on the updated box without any problems? Which one is the more user friendly system?)

Aug 062014

Recently I had to debug some JavaScript code that did not work correctly, when loaded into a Chromium Embedded frame in one of my applications. There is built-in support for the Developer Tools in Chrome, which is also available in Chromium Embedded.

After searching the web, I found that the DCEF3 sources already come with a demo on how to show these tools and also show them externally using Google Chrome (which of course must be installed for this to work).

It’s actually quite simple:

The first thing to do is set the port for remote debugging to something else but 0. This must be done before the Chromium Embedded library is being initialized, e.g. in the initialization section of the form that uses it.

  CefRemoteDebuggingPort := 9000;

Then you need a Chromium browser window to display the tools, that is, a second TChromium control which can reside either on the same form or on a different form, or even in a different application (like Google Chrome). I chose to go with the first option because it is the least hassle. My TChromium control was set to alClient, so I just added a TSplitter and another TChromium control, set to alBottom to it and set both to Visible=false by default.

Now, to show the Developer Tools, there is only very little code:

procedure TMyForm.SetDebugToolsEnabled(_Value: Boolean);
  chr_Debug.Visible := _Value;
  spl_Debug.Visible := _Value;
  if _Value then begin
    if not FDevToolLoaded then begin
      FDevToolLoaded := True;

Where chr_Embeeded is the TChromium control that displays the actual content my programs uses and chr_Debug is the TChromium control that shows the Developer Tools.

Much easier than I originally thought, but far from obvious if you don’t know that the Devoloper Tools are just another browser window (which I didn’t).

 Delphi  Kommentare deaktiviert
Jul 262014

In the olden days[tm] there was a project for maintaining a file which created human readable conditional defines from the VERxx conditional defines of the Delphi compilers. Since it seems to have vanished from the face of the Internet[tm], I have just added a new page to the Delphi Wiki which you can just copy to a file and use. It allows you to do things like this:

{$include ''}
{$IFDEF Delphi6up}
{$WARN unsafe_type off}
{$WARN unsafe_code off}
{$WARN unsafe_cast off}

(This turns the annoying dotNET warnings off that are just so unnecessary for native code.)

For a more comprehensive version of such a file, see from Project JEDI.

Jul 232014

I have got a form that usually displays outputs from various sources, each of which has a frame for its own purpose. Now, if an error occurs with any of theses sources, I want to display that error message on the bottom of the form, just above the panel that contains the action buttons. It looks like this:

    P2  **********************************
        *      *          *              *
        *  F1  *   F2     *      F3      *
        *      *          *              *
        *                                *
        *            F4                  *
    L1  *                                *
    P1  *         buttons go here        *

F1, F2, F3, F4 are the output frames for four of the sources, there can be many of various sizes.

My current solution is two panels and a label:
P2 is client aligned and contains all the frames
L1 is bottom aligned and normally invisible
P1 is bottom aligned

If an error occurs, I set the label’s caption and make it visible.

That works fine, if the error messages are short and fit within the window. Unfortunately, that’s not always the case. If the messages are longer, I would like to automatically word wrap them and increase the label’s hight.

I was prepared to start using Canvas.TextExtend etc. to write code for all of that, but it turned out there is a very simple solution:

Set the label’s WordWrap property to true and make sure that its AutoSize property is also true. That way the VCL will automatically take care of both, the word wrapping and increasing the label’s height if necessary.

(I think TLabel.WordWrap was introduce with Delphi 2007, but it might be even older.)

Adding fields to a TDataset in code

 Delphi  Kommentare deaktiviert
Jul 122014

The Delphi IDE allows you to add fields to a TDataset (descendant e.g. TTable, TQuery, TAdoTable etc.) by right clicking on the component and selecting “Add Field” or “New Field”. For a particular project I didn’t want to do that because I kept changing the query for which I want to add the fields. But since there was one calculated field I had to add fields to the dataset otherwise the OnCalcFields event wouldn’t be called. So I ended up adding the fields in code.

Basically that’s easy, you just create a TField descendant (e.g. TStringField,TAutoIncField, TDateTimeField etc.) set the field name and dataset and that’s it. But there are some pitfalls:

  fld: TField;
  ds: TDataset;
  // init Dataset
  // ...
  // add fields
  fld := TWideStringField.Create(ds);
  fld.Name := '';
  fld.FieldName := 'TE_Employee';

While this looks fine, it will not work. You will get the error “Field does not have a dataset” (or similar, I don’t remember the exact error message). The reason is that adding the field to the Dataset’s Fields collection does not automatically tell the field to which dataset it belongs. For that you need to assign the field’s Dataset property.

  fld: TField;
  ds: TDataset;
  // init Dataset
  // ...
  // add fields
  fld := TWideStringField.Create(ds);
  fld.Name := '';
  fld.FieldName := 'TE_Employee';
  fld.Dataset := ds;

If you write it like this, it will seem to work, but you will get an access violation when the dataset is being destroyed. Can you spot why?

I had to trace into the RTL sources to find the problem: The field was added to the Fields collection twice, because setting its Dataset property also adds it to the Fields collection. So, when the field’s collection got freed, the Field was freed twice, resulting in the AV.

So the correct and working code is this:

  fld: TField;
  ds: TDataset;
  // init Dataset
  // ...
  // add fields
  fld := TWideStringField.Create(ds);
  fld.Name := '';
  fld.FieldName := 'TE_Employee';
  fld.Dataset := ds; // this automatically adds the field to the Dataset's Fields collection.

You might be wondering about the line

  fld.Name := '';

I set the name of all components created in code to an empty string to avoid name collisions with any existing components or even a different instance of the component created by the same code. “A component with the name Edit1 already exists.” has bitten me too often.

Since I also used a TDbGrid to display the dataset, I also added Columns to the DBGrid to set the caption and column width. And since I am lazy (as any good programmer should be), I moved most of that code into a (sub-) procedure to make the code more readable (actually I did it so I had less to type, but the result is the same):

  TheDataset: TDataset;
  TheGrid: TDbGrid;

procedure TMyForm.InitDbGrid;

  procedure AddField(_fld: TField; const _Fieldname: string; const _Caption: string; _Width: Integer);
    Col: TColumn;
    _fld.FieldName := _Fieldname;
    _fld.ReadOnly := True;
    _fld.Dataset := TheDataset;
    Col := TheGrid.Columns.Add;
    Col.Expanded := False;
    Col.FieldName := _Fieldname;
    Col.Title.Caption := _Caption;
    Col.Width := _Width;

  AddField(TAutoIncField.Create(nil), 'SeNr', _('Number'), 50);
  AddField(TDateTimeField.Create(nil), 'TeArbeitstag', _('Date'), 70);
  AddField(TWideStringField.Create(nil), 'SeVon', _('Start'), 40);
  AddField(TWideStringField.Create(nil), 'SeBis', _('End'), 40);
  fld := TWideStringField.Create(nil);
  fld.FieldKind := fkCalculated;
  AddField(fld, 'Stunden', _('Hours'), 50);
  AddField(TWideStringField.Create(nil), 'PROJ_IDENT', _('Project'), 50);
  AddField(TWideStringField.Create(nil), 'SSchluessel', _('Activity'), 50);
  AddField(TWideStringField.Create(nil), 'SeBeschreibung', _('Description'), 200);

And just to show why this code is actually useful, here are the ResizeGridColumns method and TheDatasetCalcFields and FormResize events.

procedure TMyForm.ResizeGridColumns;
  cnt: Integer;
  TotalWidth: Integer;
  i: Integer;
  TotalWidth := 0;
  cnt := TheGrid.Columns.Count;
  for i := 0 to cnt - 2 do begin
    TotalWidth := TotalWidth + TheGrid.Columns[i].Width;
  TheGrid.Columns[cnt - 1].Width := TheGrid.ClientWidth - TotalWidth - 50;

procedure TMyForm.FormResize(Sender: TObject);

procedure TMyForm.TheDatasetCalcFields(Dataset: TDataSet);
  Von: TdzNullableTime;
  Bis: TdzNullableTime;
  Dataset.FieldByName('Stunden').Value := (Bis - Von).ToHourStr(2);

(TdzNullableTime is an extended record type from my dzlib library which is available from sourceforge if you are interested. It is declared in u_dzNullableTime.pas.

GORM experimental release

 Delphi  Kommentare deaktiviert
Jul 052014

GORM is an editor for .po files that was originally written by Lars Dybdahl and to which I have been contributing quite a few features in recent years. Since Lars is too busy to do a release and currently even the original download doesn’t seem to work, I have compiled the current sources and provide a download here:

In addition to the features described on the Gorm homepage this new version can do the following:

  • Edit the po file header.
  • Auto translate, using Google translate (not sure whether it is still available) or Microsoft Translator. Both need an application key that is not part of Gorm.
  • Auto translate from a local translation repository, which is an MS Access database, one per language, that can be shared by multiple developers
  • Auto translate using translation memory, that is a po file that is automatically generated.
  • Load and save translations to be ignored from a ignore.po file.
  • In addition to English, I provide it with German localization, that, of course, is created with Gorm itself.

The sources are available from the dxgettext repository on sourceforge.
Of course I like Gorm much better than PoEdit and other alternatives. If there are any bugs, that’s probably my fault.