GExperts 1.3.15 experimental twm 2019-11-23 released

 Delphi, GExperts  Comments Off on GExperts 1.3.15 experimental twm 2019-11-23 released
Nov 232019

I just released GExperts 1.3.15 for all supported Delphi versions.

There have again been various bug fixes and the following notable changes:

  • There is now a start menu entry for a new stand alone version of the GExperts Code Formatter. Note that it not only has a GUI for selecting a single file to format and show the settings dialog, but can also be called with a list of files to be formatted. So, you could for example drag a group of files onto the executable to format them all. I plan to expand that command line interface in the future to allow formatting all files in a project or in a directory and its subdirectories.
  • Talking about the code formatter: Many more bugs have been fixed. A while ago I was actually thinking I got them all, but unfortunately that turned out to be a delusion. ­čśë
  • The GoTo Line Number dialog enhancer has been removed and replaced with a Go To expert with the same functionality but its own dialog, which has a setting to replace the Search -> Go to Line Number menu entry. If you have any suggestions on further improving that expert, please file a feature request.
  • Bugfix for the PE Information expert: It should now display all exported class names.
  • Many changes to the Uses Clause Manager expert (most of them contributed by Peter Panettone)
    • Bugfixes for the Identifier tab. It wrongly found some identifiers that just weren’t exported from that unit
    • It now highlights any units it will add.
    • It can now parse map files generated by the Win64 compiler, not just those from the Win32 compiler
    • It now shows an error message if it cannot use the map file and resorts to the dpr file.
    • The filter on the Identfier tab now has two modes:
      • Match anywhere
      • Match at start
    • There is now a status bar that shows the full file name of the currently selected unit. A popup menu allows to
      • Copy that file name to the clipboard
      • Copy that file to the clipboard (like pressing Ctrl+C on the file name in the Windows File Explorer)
      • Open the file’s location in the Windows File Explorer
    • The library path for Delphi XE and later was wrong, so the VCL/RTL tab was always empty.
  • There was a bug with the Clipboard History expert: It still hooked the clipboard even if it was disabled. In addition it could kill the IDE when it added new entries to the (possibly invisible) list view. Under some strange conditions setting the text of a memo apparently can fail with an EInvalidOperation exception. This exception was not caught and since it happened deep inside a chain of event handlers, it caused an Access Violation somewhere which then silently killed the IDE. That one was quite difficult to track down.
  • Improvement to the Backup Project expert: A new dialog shows any files it cannot find and it only shows each file once, not every time it does not find it. This was particularly annoying with include files.
  • And last, but not least: The GExperts version for Delphi 10.3 is now compiled with the latest and greatest Delphi 10.3 update 3 release. Let’s hope this fixed some bugs and hasn’t introduced any new ones. (Unfortunately RSP-25645 “Creating sub components with IOTAFormEditor.CreateComponent raises access violation” still hasn’t been fixed, so replacing e.g. TTable with TSqlTable still does not work.)

The new version is available for download on the GExperts download page.

 Posted by on 2019-11-23 at 19:09

dzBdsLauncher 1.0.2 released

 Delphi, dzBdsLauncher  Comments Off on dzBdsLauncher 1.0.2 released
Nov 232019

dzBdsLauncher tries to solve the problem of accidentally opening a Delphi project with the wrong Delphi version. The latest version 1.0.2 now also detects .DPROJ file from Delphi 10.3.3. See the dzBdsLauncher page for details.

 Posted by on 2019-11-23 at 16:01

No new GExperts release yet for Delphi 10.3.3

 Delphi, GExperts  Comments Off on No new GExperts release yet for Delphi 10.3.3
Nov 212019

Edit: There is now a new release.

Before you ask: No, there is no new GExperts release yet for Delphi 10.3.3. I haven’t even downloaded it yet. I might get to it this weekend.

In the meantime you can get the sources and compile your own DLL with the new Delphi version. I don’t expect any problems (but I have been wrong before).

 Posted by on 2019-11-21 at 18:13

If you compiled your own GExperts clear the Uses Clause Manager cache

 Delphi, GExperts  Comments Off on If you compiled your own GExperts clear the Uses Clause Manager cache
Nov 192019

This is only relevant, if you have recently compiled your own GExperts DLL and you use the Uses Clause Manager’s Identifier tab:

There were several bugs in the unit parsing code that have been fixed. But you won’t see the effect, because the buggy results from before that have been cached. In order to get the benefit of these bugfixes, you must clear the Uses Clause Manager’s cache.

To do that,

  1. Go to GExperts -> Configuration
  2. On the Experts tab, enter “uses” and press Alt+C
  3. Press the “Clear Cache” button

Yes, I know, that I should make a new release soon, but I keep finding old and sometimes new bugs and then there are people who submit patches. It’s difficult to determine when to make a release. But hey, you have got the source code and the compiler, so why not compile your own DLL?

 Posted by on 2019-11-19 at 17:48

Creating an array of controls in Delphi

 Delphi  Comments Off on Creating an array of controls in Delphi
Nov 172019

One frequently asked question that still gets asked today goes like this: “How do I create an array of [component] and fill it with existing [component] instances from the form?” Where [component] usually is TLabel, TCheckbox or TEdit.

I’m going to outline some solutions here.

Let’s start by defining some parameters:

  1. We have got a (VCL) form
  2. On that form there are several controls of the same type. Let’s make them CheckBoxes.
  3. We want to do something with all these controls
  4. In order to make this easier, we want to create an array that contains all these controls

So, this is the form:

The form declaratin looks like this:

  TForm1 = class(TForm)
    grp_1: TGroupBox;
    chk_1: TCheckBox;
    chk_2: TCheckBox;
    chk_3: TCheckBox;
    grp_2: TGroupBox;
    chk_4: TCheckBox;
    chk_5: TCheckBox;
    chk_6: TCheckBox;
    b_OK: TButton;
    b_Cancel: TButton;

As you can see, it contains six CheckBoxes grouped in two GroupBoxes.
Now, for some reason, we want to disable all those CheckBoxes.

Of course we could do it like this:

  chk_1.Enabled := False;
  chk_2.Enabled := False;
  chk_3.Enabled := False;
  chk_4.Enabled := False;
  chk_5.Enabled := False;
  chk_6.Enabled := False;

And for just 6 CheckBoxes we probably would. But lets assume there are 30 and we don’t only want to disable them all but also sometimes enable or check or uncheckm them all. That starts to get a bit tedious, so wouldn’t it be great if we could just create an array of TCheckbox and fill it with those pesky things? We could then just write:

for chk in CheckBoxArr do begin
  chk.Enabled := false;

But how do we get this array? If you ever programmed in Visual Basic, you know the concept of control arrays, which you get by “simply” setting an Index property of the controls. They would then all have the same name and you could access them individually by TheCheckBox[i]. While that looks nice at first glance, just consider setting these indexes correctly for 30 CheckBoxes using the (crappy) property editor that VB had. I hated it. But I deviate …

We want a function which we can pass a TForm parameter that returns a TCheckBoxArray:

  TCheckBoxArray = array of TCheckBox;

function AllCheckboxes(_frm: TForm): TCheckBoxArray;

If you look closely at the form declaration above you will notice that all CheckBoxes follow a common naming pattern: They all start with ‘chk_’ followed by a number. So we could use FindComponent to get them:

function GetAllCheckboxes(_frm: TForm): TCheckBoxArray;
  i: Integer;
  cmp: TComponent;
  SetLength(Result, _frm.ComponentCount);
  i := 1;
    cmp := _frm.FindComponent('chk_' + IntToStr(i));
    if cmp <> nil then begin
      Result[i - 1] := cmp as TCheckBox;
  until cmp = nil;
  SetLength(Result, i - 1);

But if you think about it this is quite a bit of work, because you must make sure that your CheckBoxes all conform to that name pattern and for the above code to work, there must not be any gaps in the numbering. We usually want those CheckBoxes to have meaningful names rather than numbers, so it’s chk_Green, chk_Blue, chk_LightOn rather than chk_1, chk_2 etc. Also, what if you accidentally add another control that conforms to the name pattern but is not a CheckBox?

So FindComponent is out. What alternatives are there?

There is the Component array of the form, that contains every component on the form whose Owner is the form (this is usually the case for all components on a form when the form has been created using the form designer). So we enumerate all components and check whether they are CheckBoxes:

function GetAllCheckboxes(_frm: TForm): TCheckBoxArray;
  i: Integer;
  cmp: TComponent;
  cnt: Integer;
  SetLength(Result, _frm.ComponentCount);
  cnt := 0;

  for i := 0 to _frm.ComponentCount - 1 do begin
    cmp := _frm.Components[i];
    if cmp is TCheckBox then begin
      Result[cnt] := TCheckBox(cmp);
  SetLength(Result, cnt);

Much better. We don’t need any naming pattern and we only get CheckBoxes.

I mentioned above, that the form’s Components[] property contains all components placed on the form using the form designer. But components can also be created in code and there you can pass any other control as the Owner:

  chk := TCheckbox.Create(grp_1);
  chk.Name := '';
  chk.Parent := grp_1;
  chk.Top := 8;
  chk.Left := 8;
  chk.Caption := 'CheckBox created in code.';

The function will not find such a CheckBox because by passing grp_1 to its constructor we add it the Components[] property of the GroupBox rather than the form. That’s perfectly OK. We also clear the name, which would prevent it from being found by FindComponent too. But if you write code like this, you probably know what you are doing and won’t have read this article up to here.

I could stop now, but there is another use case: What if we want to get an array of only those CheckBoxes in one of the GroupBoxes? We could pass that GroupBox as a second parameter to the function and check that the Parent property of the CheckBoxes matches the GroupBox. But there is a simpler way: Each WinControl (that is: Control that itself can contain other controls, which includes GroupBoxes, Panels etc. and of course Forms or Frames) has got a Controls[] property that contains those controls. So we make a simple change to the function:

function GetAllCheckboxes(_Parent: TWinControl): TCheckBoxArray;
  i: Integer;
  ctrl: TControl;
  cnt: Integer;
  SetLength(Result, _Parent.ControlCount);
  cnt := 0;
  for i := 0 to _Parent.ControlCount - 1 do begin
    ctrl := _Parent.Controls[i];
    if ctrl is TCheckBox then begin
      Result[cnt] := TCheckBox(ctrl);
  SetLength(Result, cnt);

// [...]
  CheckBoxes := GetAllCheckboxes(grp_1);

This will return all CheckBoxes placed on the GroupBox grp_1.

But note that …

  CheckBoxes := GetAllCheckboxes(Form1);

… will now return an empty array! None of the CheckBoxes have been placed on the form itself, so they will not be in the form’s Controls[] property.

If you haven’t been bored out of your skull by now and want to discuss this article, you can do so here in this post in the international DelphiPraxis forum.

 Posted by on 2019-11-17 at 12:52

dzPrepBuild for Delphi 1.3.3 released

 Delphi, dzPrepBuild  Comments Off on dzPrepBuild for Delphi 1.3.3 released
Nov 022019

I just released version 1.3.3 of dzPrepBuild

The reason for this release was that I wanted to allow automatically updating the ProductVersion when the FileVersion changes. In order to do that, the tool now supports two additional placeholders that an be used in any version string: {MajorVer} and {MinorVer} which, as you might have guessed, resolve to the major and minor version number.


[Version Info Keys]
FileDescription=This is a Testproject for dzPrepBuild
LegalCopyright=Copyright 2002-{ThisYear} by Thomas Mueller

I also added {ProjectName} which resolves into the name of the Delphi project and is used in the example above for the InternalName and OriginalFilename entries.

While working on this enhancement unfortunately I also found a major bug that was introduced by a patch I accepted nearly years ago. It added support for private and special build flags but used the wrong names for these entries in the .dof, .bdsproj and .dproj files which resulted in –ReadDof, -ReadBdsProj and -ReadDproj failing. This is now also fixed. I never noticed this problem because I don’t use the built in Delphi version information any more. All my projects have an external [projectname]_version.ini file for maintaining the version information.

And since I was at it, I moved the project from SourceForge to OSDN. The new version can be downloaded from there.

 Posted by on 2019-11-02 at 14:55

PascalMagick – MagickDistortImage in Delphi

 Delphi  Comments Off on PascalMagick – MagickDistortImage in Delphi
Oct 222019

Playing around with ImageMagick I found that somebody already wrote a Pascal/Delphi import unit for it called PascalMagick. Unfortunately it has been integrated into freepascal which means Delphi support no longer has any priority.

So, the first thing to do was getting it to compile with Delphi.
It requires the ctypes unit from freepascal which did not compile because of an {$if …} that was terminated with an ${endif} rather than ${ifend} (line 107, newer versions fo Delphi won’t complain about this any more).

Then I opened one of the examples. There is a DPR file with an associated DPROJ file, but unfortunately that file was not a Delphi project file but some XML stuff. I renamed the LPR file (Lazarus Project) to DPR and it loaded into Delphi 2007.

Compiling worked too, but when I started it, I immediately got a System Exception with some cryptic error message. Half an hour later I knew the cause: The DLL could not be loaded, because there is an {$IFDEF Windows} around the MagickExport and WandExport constants (ImagageMagick.pas line 45). Delphi does not by default define this symbol. So I added it and the DLL still could not be found. WTF? Turned out that the DLL name was wrong. It’s now CORE_RL_MagickWand_.dll rather than CORE_RL_Wand_.dll. After that change the example program actually worked.

But I did not want to do the simple stuff but was interested in writing code that does what ‘magick -distort Perspective’ does. And I could not find anything in those units and include files that looked promising. Google finally turned up the MagickDistortImage function which is simply missing from import unit. So I added it:

  TMagickDistortImage = function(wand: PMagickWand; Method: DistortMethod; NumOfArgs: Integer;
        arguments: PDouble; bestfit: MagickBooleanType): MagickBooleanType; cdecl;

    MagickDistortImage: TMagickDistortImage;

  MagickDistortImage := GetProcAddress('MagickDistortImage');

But which values can be passed to the Method parameter? Again, it took me a while to find that enum declaration in C, so I converted it to Delphi:

  DistortMethod = (
    AffineDistortion, AffineProjectionDistortion, ScaleRotateTranslateDistortion,
    PerspectiveDistortion, PerspectiveProjectionDistortion,
    BilinearDistortion = BilinearForwardDistortion,
    BilinearReverseDistortion, PolynomialDistortion, ArcDistortion, PolarDistortion,
    DePolarDistortion, Cylinder2PlaneDistortion, Plane2CylinderDistortion, BarrelDistortion,
    BarrelInverseDistortion, ShepardsDistortion, ResizeDistortion, SentinelDistortion);

That’s how far I have come by now. I’ll put this here in case somebody else is as desparately looking for these declarations as I was for the last few hours.

 Posted by on 2019-10-22 at 16:00

efg’s Computer Lab and Reference Library is being restructured

 Delphi  Comments Off on efg’s Computer Lab and Reference Library is being restructured
Oct 212019

If you have done graphics processing in Delphi, you know efg’s computer lab which contained lots of great documentation and source code for that purpose. Unfortunately today on you can read the following:

This site will be reorganized in the near future.

Prior to July 2019, this site contained 180+ pages on a variety of technical topics.
Links below are to copies on the Wayback Machine.

And since I am afraid that even those links will go away in the near future, I want to preserve them here:

Computer Lab on Wayback Machine (last snapshot from 2019-04-29)
The Computer Lab contains Lab Reports and Technical Notes on topics including, image processing, color science, computer graphics, mathematics, fractals & chaos, science & engineering. Most projects involve programming and include complete Delphi source code.

Reference Library on Wayback Machine (last snapshot from 2019-05-02)
The Reference Library contains two major sections, Delphi and Technical, each of which is a compendium of information from a wide variety of Internet resources.

The Delphi section is divided into a number of subsections and contains a large number of Delphi programming examples and code fragments. The Delphi Reference Library is mostly about technical topics (other than databases, except for the ADO subsection). The Algorithms, Graphics, Printing, and Math pages are the most popular.

The Technical section contains a large number of links to technical information. The Algorithms, Color, and Image Processing Reference Library pages are the most popular.

 Posted by on 2019-10-21 at 11:15

Several bugs regarding the GExperts Uses Clause Manager fixed

 Delphi, GExperts  Comments Off on Several bugs regarding the GExperts Uses Clause Manager fixed
Oct 192019

A few months ago I added the “Identifiers” tab to the GExperts Uses Clause Manager. It allows you to search for a unit that exports a given identifier. It works a bit like the “Find Unit” refactoring in the IDE since Delphi 2005.

That feature starts a background thread that parses all units in the search path to get a list of identifiers these units export. It works well with Delphi 2007 but recently I discovered that in Delphi 10.3.2 it finds “FreeAndNil” in various units which I am sure don’t export it:

So something must have been wrong with the parsing code.

It turned out that there were several bugs in that code, all related to language features added to Delphi later than Delphi 2007 (You may remember that I stated several times that I still do most of my work with Delphi 2007 so that version is the one with which GExperts has been tested extensively.).

These bugs have now been fixed and “FreeAndNil” only gets me the expected short list of units:

The changes have been committed to the svn repository (revisions #2807 and #2808), so if you want a DLL without this bug, you can compile your own.

 Posted by on 2019-10-19 at 20:20