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.

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!

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 on 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 , 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.

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.

DataSnap in the Cloud (PDF)

The slides from the presentation. I omitted those slides serving transition effects only.

FishFacts (Project)

The modified FishFacts project. The console application project is called FishFactsServer.  It contains the changes to make it work with SQL Database in Azure as well as the patched Data.DBXMSSQLMetaDataReader.pas (XE2) to make it work with SQL (Azure) Database.

Azure Cloud Service

The Azure Cloud Services Project. You have to copy the FishFactsServer.exe into the WorkerRole folder after compilation and before making the package.

DbDemos SQL Script

SQL Script for DbDemos Database. Executing this script in SQL Managment Studio will create and populate the complete dbdemos database in a format suitable for SQL (Azure) Database.

As the database behind SQL Azure is just SQL Server 2008 R2, there should be a possibility to access that thing with the dbExpress driver for MSSQL that ships with Delphi Enterprise, Ultimate and Architect.

What should I say, the first attempt just failed!

Although I have been aware that SQL Azure won’t work with Windows Authentication, simply changing the host name and giving the user credentials didn’t work out of the box.

Googling didn’t reveal much, but a post from da-soft pushed me into the right direction:

• You have to use “tcp:” prefix in Server parameter. This is because only TCP/IP protocol is supported by SQL Azure.
• You have to use “@server” suffix in User_Name parameter. This is probably because the farm has a lot of users from other SQL Azure accounts.

A sample host name looks like: tcp:a1b2c3d4e5.database.windows.net where a1b2c3d4e5 is your Azure host.

The corresponding user name should then look like: <user>@a1b2c3d4e5

Don’t forget to disable OSAuthentication!

Worth to mention that despite stated otherwise in the blog post, it is indeed possible to use plain dbExpress with SQL Azure.

These regression tests are vital to any serious software development. What would your customers say when they get a new version breaking their day to day work? Well, at least I can’t afford that – and be it just that I’m not keen to fix those problems at a customer under high pressure. So I have regression tests.

Writing those tests for a long standing program can be quite time consuming, but you have to start somewhere. In this case it came out that my application takes an input file and produces an output file from that. So I asked my customers to send me plenty of their input files. The amount of files I got was – well, let’s say unexpected.

I took each file and produced the corresponding output file as a reference. The regression tests also take each input file, produce the output file and compares it with the reference file. If anything is different the test fails and I have to take a look why it fails. Sometimes the fail is intended and I have to update the reference file.

The big challenge was to write the unit tests for all these input files (> 1000). My first attempt was to put a loop into a test case that iterates over all files. That worked but had a major drawback: when one file failed, the complete test failed at that file and the remaining files were not checked at all.

Writing one test case for each file looked far less comfortable, so I wrote a little extension to DUnit that dynamically creates test cases for each file found in a given folder.

The extension introduces two new classes: TFileTestCase derived from TTestCase and TFolderTestSuite derived from TTestSuite.

To make use of these you derive a test case from TFileTestCase and implement any test methods as published just as you do for a normal test case. The current file for the test case can be taken from the new property TestFileName.

The critical part is to override the class method Suite, which returns an ITestSuite interface. Here you create an instance of TFolderTestSuite with some appropriate parameters. The required first parameter for TestClass can simply be given with self, which in a class method gives the current class type.

Here is the code for the extension unit:

unit TestFrameworkExt;

interface

uses
  TestFramework;

type
  TFileTestCaseClass = class of TFileTestCase;
  TFileTestCase = class(TTestCase)
  private
    FTestFileName: string;
  public
    constructor Create(const AMethodName, ATestFileName: string); reintroduce; overload; virtual;
    function GetName: string; override;
    property TestFileName: string read FTestFileName;
  end;

  TFolderTestSuite = class(TTestSuite)
  private
    FBaseFolder: string;
    FFileMask: string;
    FRecursive: Boolean;
  protected
    procedure AddMethodTests(TestClass: TTestCaseClass; const NameOfMethod: string); overload; virtual;
    procedure ProcessFile(Suite: ITestSuite; TestClass: TFileTestCaseClass; const NameOfMethod, FileName: string); virtual;
    procedure ProcessFolder(Suite: ITestSuite; TestClass: TFileTestCaseClass; const NameOfMethod, Path, FileMask: string;
        Recursive: Boolean); overload; virtual;
    procedure ProcessBaseFolder(Suite: ITestSuite; TestClass: TFileTestCaseClass; const NameOfMethod: string); virtual;
  public
    constructor Create(TestClass: TFileTestCaseClass; const ABaseFolder, AFileMask: string; ARecursive: Boolean); overload;
    procedure AddTests(testClass: TTestCaseClass); override;
    property BaseFolder: string read FBaseFolder;
    property FileMask: string read FFileMask;
    property Recursive: Boolean read FRecursive;
  end;

implementation

uses
  Types, IOUtils;

constructor TFolderTestSuite.Create(TestClass: TFileTestCaseClass; const ABaseFolder, AFileMask: string; ARecursive:
    Boolean);
begin
  FBaseFolder := ABaseFolder;
  FFileMask := AFileMask;
  FRecursive := ARecursive;
  inherited Create(TestClass);
end;

procedure TFolderTestSuite.AddMethodTests(TestClass: TTestCaseClass; const NameOfMethod: string);
var
  suite: ITestSuite;
begin
  if TestClass.InheritsFrom(TFileTestCase) then begin
    suite := TTestSuite.Create(NameOfMethod);
    AddSuite(suite);
    ProcessBaseFolder(suite, TFileTestCaseClass(TestClass), NameOfMethod);
  end
  else begin
    AddTest(TestClass.Create(NameOfMethod));
  end;
end;

procedure TFolderTestSuite.AddTests(testClass: TTestCaseClass);
var
  MethodIter     :  Integer;
  NameOfMethod   :  string;
  MethodEnumerator:  TMethodEnumerator;
begin
  { call on the method enumerator to get the names of the test
    cases in the testClass }
  MethodEnumerator := nil;
  try
    MethodEnumerator := TMethodEnumerator.Create(testClass);
    { make sure we add each test case  to the list of tests }
    for MethodIter := 0 to MethodEnumerator.Methodcount-1 do begin
      NameOfMethod := MethodEnumerator.nameOfMethod[MethodIter];
      AddMethodTests(testClass, NameOfMethod);
    end;
  finally
    MethodEnumerator.free;
  end;
end;

procedure TFolderTestSuite.ProcessBaseFolder(Suite: ITestSuite; TestClass: TFileTestCaseClass; const NameOfMethod:
    string);
begin
  ProcessFolder(Suite, TestClass, NameOfMethod, BaseFolder, FileMask, Recursive);
end;

procedure TFolderTestSuite.ProcessFile(Suite: ITestSuite; TestClass: TFileTestCaseClass; const NameOfMethod, FileName:
    string);
begin
  suite.AddTest(TestClass.Create(NameOfMethod, FileName));
end;

procedure TFolderTestSuite.ProcessFolder(Suite: ITestSuite; TestClass: TFileTestCaseClass; const NameOfMethod, Path,
    FileMask: string; Recursive: Boolean);
var
  list: TStringDynArray;
  S: string;
  tmp: ITestSuite;
begin
  list := TDirectory.GetFiles(Path, FileMask);
  for S in list do
    ProcessFile(suite, TestClass, NameOfMethod, S);
  if Recursive then begin
    list := TDirectory.GetDirectories(path);
    for S in list do begin
      tmp := TTestSuite.Create(TPath.GetFileName(S));
      suite.AddSuite(tmp);
      ProcessFolder(tmp, TestClass, NameOfMethod, S, FileMask, true);
    end;
  end;
end;

constructor TFileTestCase.Create(const AMethodName, ATestFileName: string);
begin
  FTestFileName := ATestFileName;
  inherited Create(AMethodName);
end;

function TFileTestCase.GetName: string;
begin
  result := TPath.GetFileNameWithoutExtension(TestFileName);
end;

end.

The drawback was that since Windows Vista this was no way to go when you wanted to use the new Vista style dialogs. This was an even more nuisance as the new dialogs already come with a preview ability – so why not use it directly?

Googling a bit reveiled that others have to fight with the same problem, but no one seemed to have bitten the bullet to make a nice Delphi wrapper around the usual hurdles encountered when programming directly against the operating system. Looks like it was my turn to volunteer and here are the results. A simple implementation of a preview handler the Delphi way can be written in 45 lines:

unit MyPreviewHandler;

interface

uses
  PreviewHandler, Classes, Controls, StdCtrls;

const
  CLASS_MyPreviewHandler: TGUID = '{64644512-C345-469F-B5FB-EB351E20129D}';

type
  TMyPreviewHandler = class(TFilePreviewHandler)
  private
    FTextLabel: TLabel;
  public
    constructor Create(AParent: TWinControl); override;
    procedure DoPreview(const FilePath: string); override;
    property TextLabel: TLabel read FTextLabel;
  end;

implementation

uses
  SysUtils;

constructor TMyPreviewHandler.Create(AParent: TWinControl);
begin
  inherited;
  FTextLabel := TLabel.Create(AParent);
  FTextLabel.Parent := AParent;
  FTextLabel.AutoSize := false;
  FTextLabel.Align := alClient;
  FTextLabel.Alignment := taCenter;
  FTextLabel.Layout := tlCenter;
  FTextLabel.WordWrap := true;
end;

procedure TMyPreviewHandler.DoPreview(const FilePath: string);
begin
  TextLabel.Caption := GetPackageDescription(PWideChar(FilePath));
end;

initialization
  TMyPreviewHandler.Register(CLASS_MyPreviewHandler, 'bplfile', 'BPL Binary Preview Handler', '.bpl');
end.

This is all that must be done to display the description of a BPL file in the preview pane, whereas most of the work is actually setting up a TLabel do display it nicely.

Overriding DoPreview is obiligatory as the inherited declaration is abstract. If you refuse to override it, you actually don’t want to write your own preview handler, so stop reading further and mind your own business.

The overridden constructor Create is the place to establish the needed controls for the preview and connect it to the passed parent. You can easily place a derived TFrame instance onto the parent control, which allows the use of the visual form designer for your preview. Be aware that the constructor has to be declared as override.

Overriding the Unload method is optional in case you have to clear the preview and/or free some resources. It just didn’t make sense in this example, unless you want to clear the label caption. (and it would have increased the line count to 51)

Don’t forget to register your preview handler in the initialization part of the unit using a fresh GUID. (Pre-emptive comment: No, class constructors are not the way to go here)

Of course the compiled DLL has to be registered with regsvr32. Make sure to run it as Administrator.

OK, I admit that the overall benefit of this preview handler is somewhat limited, but it does serve well as an example. I also admit that I suppressed the project file, which in turn is quite simple.

library MyPreviewHandlerLib;

uses
  ComServ,
  PreviewHandler in 'PreviewHandler.pas' {PreviewHandler: CoClass},
  MyPreviewHandler in 'MyPreviewHandler.pas';

exports
  DllGetClassObject,
  DllCanUnloadNow,
  DllRegisterServer,
  DllUnregisterServer,
  DllInstall;

{$R *.RES}

begin
end.

I tried to get rid of the {PreviewHandler: CoClass} entry in the uses clause, but the IDE insisted to put it in again. So, be it…

The real work (as usual) is done under the hood in unit PreviewHandler.pas, which I will explain shortly in the following.

The interface section declares a base class TPreviewHandler and two derived classes TStreamPreviewHandler and TFilePreviewHandler.

type
  TPreviewHandler = class abstract
  public
    constructor Create(AParent: TWinControl); virtual;
    class function GetComClass: TComClass; virtual; abstract;
    class procedure Register(const AClassID: TGUID; const AName, ADescription, AFileExtension: string);
    procedure Unload; virtual;
  end;

  TStreamPreviewHandler = class abstract(TPreviewHandler)
  public
    procedure DoPreview(Stream: TStream); virtual; abstract;
    class function GetComClass: TComClass; override; final;
  end;

  TFilePreviewHandler = class abstract(TPreviewHandler)
  public
    procedure DoPreview(const FilePath: String); virtual; abstract;
    class function GetComClass: TComClass; override; final;
  end;

Microsoft recommends to implement the stream based preview handler as it will also work for previews, say, inside a zip file, but there are cases when a file based preview handler is just a bit more handy. You would have difficulties to implement the sample preview handler from above on a stream with the same simplicity. There is indeed a third possibility to implement a preview handler based on an IShellItem, but let’s say I left the implementation as an exercise.

You may have noticed that TPreviewHandler is derived from TObject instead of TComObject, which actually was my first approach. I decided to separate the COM stuff from the preview implementation to get a lean inheritance and small base classes not cluttered with methods you better shouldn’t know about. The actual COM class is retrieved from the virtual class function GetComClass, which is overriden in both of the derived preview handler classes. The declaration of the derived function as final ensures that no one can override this function in a descendant class. This is necessary because the underlying factory assumes that the COM class descends from a specific private class (I’m open for suggestions on that). If you are going to implement your own COM classes you should better implement your own complete preview handler framework at all. For anyone else, just ignore the GetComClass function.

The implementing COM classes resemble the file/stream structure of the preview handler classes, just because they have to implement either IInitializeWithFile or IInitializeWithStream. The base class TComPreviewHandler is responsible for most of the internal stuff and the implementation is mostly straight forward. The mapping to the Delphi type TWinControl properties is made with a class helper just to bundle all that stuff (and to make it harder to port it to older Delphi versions).

The TComPreviewHandlerFactory class is responsible for updating the various registry entries needed to make Windows aware of the preview handler. It also takes care of doing the right things to use a 32-bit handler in a 64-bit environment. The code to check for this situation is taken from www.delphidabbler.com and I expanded it a little bit so that it hopefully will also work with the upcoming 64-bit Delphi compiler.

As a gimmick you get a TStream implementation that maps to an IStream interface with the TIStreamAdapter class. The other way round is already available in Delphi, but it didn’t fit in here very well.

The sources for Delphi XE can be downloaded here: PreviewHandler.zip

Some of the attendants mentioned they were still working with older Delphi versions and even if the newer versions were laying around they refused to make the step migrating their applications to the current Delphi XE. One argument from a fellow developer working still with Delphi 2007 actually alerted myself as he rated the step from Delphi 2007 to Delphi 2009 a very big one regarding the Unicode migration, but the step from Delphi 2010 to Delphi XE seems rather small, which makes himself unsure wether to make the migration to Delphi XE now or wait for the next version to come.

Honestly, I don’t get that. There already is a large step from Delphi 2007 to Delphi XE. Why making it even larger? What about “divide and conquer”? Do you really expect the migration to XE2 being easier than that to XE?

The big step, at least for some of us, may indeed be from Delphi 2007 to Delphi 2009. For myself it was merely waiting for the third party libraries to keep up or to replace some of them with those currently supported (OK, that has been some work). The steps to Delphi 2010 and Delphi XE were simply opening the project, compile and start using the new features.

Since migrating to Delphi 2009 I have been able to make use of all the new and exciting features that made it into the product since then. My code and my coding has improved a lot. I learned a whole bunch of new technologies and new techniques that makes my programming life easier. Staying with Delphi 2007 would have been a huge loss of time. Time to work with new technologies and gain experience.

When Delphi XE2 will be delivered I can concentrate on what is new in that version. I am eager to make my applications compile for the Mac (remembers me that I have to buy one before). I can’t even imagine to bother with Unicode, Generics and Anonymous Methods at that time.

IMHO not keeping up with the current Delphi is similar to not using version control, only the other way round. While using version control allows you to revert to a previous version of your application easily, staying up-to-date with your Delphi version allows you to create the future versions of your applications much easier.

The drawback of using Synchronize is that it is very cumbersome to handle parameters during such a call. The standard solution is to use fields in the TThread descendant holding the parameters during Synchronize, but this won’t work properly with Queue. As Queue is non-blocking there might be multiple calls to Queue waiting to be processed, which often cannot share the same field. Worse, using Queue access to these fields have to be thread safe, too. The queuing thread may just set this field for the next call to Queue while a previous Queue call is executed in the main thread just using this field. As this problem doesn’t exist with Synchronize, switching from Synchronize to Queue just has to be done more careful.

One way to deal with parameters for Synchronize is the use of Anonymous Methods. There is an overloaded version of Synchronize and Queue taking a TThreadProcedure as parameter:

TThreadMethod = procedure of object;
TThreadProcedure = reference to procedure;

procedure Queue(AMethod: TThreadMethod); overload;
procedure Synchronize(AMethod: TThreadMethod); overload;
procedure Queue(AThreadProc: TThreadProcedure); overload;
procedure Synchronize(AThreadProc: TThreadProcedure); overload;

A simple example for a parametrized call to Synchronize could be like this:

type
  TMyProgressEvent = procedure(PercentComplete: Integer) of object;

  TMyThread = class(TThread)
  private
    FOnMyProgress: TMyProgressEvent;
  protected
    procedure CallMyProgress(PercentComplete: Integer);
    procedure Execute; override;
  public
    property OnMyProgress: TMyProgressEvent
      read FOnMyProgress
      write FOnMyProgress;
  end;

procedure TMyThread.CallMyProgress(PercentComplete: Integer);
begin
  if GetCurrentThreadId = MainThreadID then begin
    if Assigned(FOnMyProgress) then
      FOnMyProgress(PercentComplete);
  end
  else begin
    Synchronize(
      procedure
      begin
        CallMyProgress(PercentComplete);
      end);
  end;
end;

procedure TMyThread.Execute;
var
  I: Integer;
begin
  for I := 0 to 100 do begin
    CallMyProgress(I);
    Sleep(10);
  end;
end;

The magic is that the Anonymous Method captures the value of the PercentComplete variable. Thus it will be totally safe to use Queue instead of Synchronize here.

I’m using a little trick here to ensure that the critical code is called inside the GUI thread without having a separate method. The ID of the GUI thread is stored in MainThreadID, so I just check if the result of the function GetCurrentThreadID matches this value and call Synchronize otherwise.

One note using Queue: when the thread is freed, all pending Queue calls are removed. So if your code depends on all these calls being handled in the GUI thread you have to make sure that the thread instance lives at least that long.

Writing the additional interfaces was easy done with the help of a customized code template, so that has never been a pain. The only thing that bothered me over time was that I could only apply the Visitor Pattern to classes I have control of. I just wasn’t able to visit, say, all the components of a TForm in a descent fashion (i.e. not queueing if component is something then <typecast>).

While digging through the new features of Delphi 2010 I discovered a solution which is as clean, lean, flexible and elegant as it could be. A little RTTI and some decent naming convention did the trick. Here is the code:

unit uVisitor;

interface

type
  TVisitor = class
  public
    procedure Visit(Instance: TObject); virtual;
  end;

implementation

uses
  Rtti;

procedure TVisitor.Visit(Instance: TObject);
var
  context: TRttiContext;
  currentClass: TClass;
  params: TArray<TRttiParameter>;
  paramType: TRttiType;
  selfMethod: TRttiMethod;
  S: string;
begin
  context := TRttiContext.Create;
  currentClass := Instance.ClassType;
  repeat
    S := currentClass.ClassName;
    Delete(S, 1, 1); // remove "T"
    for selfMethod in context.GetType(self.ClassType).GetMethods('Visit' + S) do begin
      params := selfMethod.GetParameters;
      if (Length(params) = 1) then begin
        paramType := params[0].ParamType;
        if ParamType.IsInstance and (ParamType.AsInstance.MetaclassType = currentClass)then begin
          selfMethod.Invoke(Self, [Instance]);
          Exit;
        end;
      end;
    end;
    currentClass := currentClass.ClassParent;
  until currentClass = nil;
end;

end.

And here is a visitor capable of handling some VCL controls on a form together with an example of its usage:

type
  TMyVisitor = class(TVisitor)
  public
    procedure VisitButton(Instance: TButton);
    procedure VisitLabel(Instance: TLabel);
    procedure VisitEdit(Instance: TEdit);
    procedure VisitMemo(Instance: TMemo);
  end;

procedure TMyVisitor.VisitButton(Instance: TButton);
begin
  Instance.Caption := 'a button';
end;

procedure TMyVisitor.VisitEdit(Instance: TEdit);
begin
  Instance.Text := 'an edit';
end;

procedure TMyVisitor.VisitLabel(Instance: TLabel);
begin
  Instance.Caption := 'a label';
end;

procedure TMyVisitor.VisitMemo(Instance: TMemo);
begin
  Instance.Lines.Clear;
  Instance.Lines.Add('a memo');
end;

procedure TForm40.Button1Click(Sender: TObject);
var
  I: Integer;
  visitor: TMyVisitor;
begin
  visitor := TMyVisitor.Create;
  try
    for I := 0 to ComponentCount - 1 do
      visitor.Visit(Components[I]);
  finally
    visitor.Free;
  end;
end;

If you need to visit some class, just introduce a new method with a suitable name and signature and you are done. No new interfaces, no fiddling around with classes. It just works right out of the box.

I’m still visualizing some possible scenarios where this approach can be useful, too. Stay tuned.