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
;
  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.

unit uShapeBase;

interface

uses
  Classes, SysUtils;

type
  ENotSupported = class(Exception);

type
  TAbstractShape = class
  public
    procedure Accept(Visitor: IInterface); virtual;
  end;

  IAbstractShapeVisitor = interface
    ['{7ED85A22-564A-4F23-AF32-37D29FD3C623}']
    procedure VisitAbstractShape(Instance: TAbstractShape);
  end;

  { we avoid ref-counting here }
  TShapeVisitor = class(TInterfacedPersistent)
  public
    procedure Visit(Instance: TAbstractShape);
  end;

type
  TShapeRectangle = class(TAbstractShape)
  private
    FX0: Double;
    FX1: Double;
    FY0: Double;
    FY1: Double;
  public
    procedure Accept(Visitor: IInterface); override;
    property X0: Double read FX0 write FX0;
    property X1: Double read FX1 write FX1;
    property Y0: Double read FY0 write FY0;
    property Y1: Double read FY1 write FY1;
  end;

  IShapeRectangleVisitor = interface
    ['{6F521E71-5DB8-4ECE-B453-60F9A3B8BE22}']
    procedure VisitShapeRectangle(Instance: TShapeRectangle);
  end;

type
  TShapeCircle = class(TAbstractShape)
  private
    FCenterX: Double;
    FCenterY: Double;
    FRadius: Double;
  public
    procedure Accept(Visitor: IInterface); override;
    property CenterX: Double read FCenterX write FCenterX;
    property CenterY: Double read FCenterY write FCenterY;
    property Radius: Double read FRadius write FRadius;
  end;

  IShapeCircleVisitor = interface
    ['{27D7DCD3-952A-4879-8667-E86023612BFB}']
    procedure VisitShapeCircle(Instance: TShapeCircle);
  end;

implementation

procedure TShapeVisitor.Visit(Instance: TAbstractShape);
begin
  Instance.Accept(Self);
end;

procedure TShapeCircle.Accept(Visitor: TShapeVisitor);
var
  myVisitor: IShapeCircleVisitor;
begin
  if Supports(Visitor, IShapeCircleVisitor, myVisitor) then
    myVisitor.VisitShapeCircle(Self)
  else
    inherited;
end;

procedure TShapeRectangle.Accept(Visitor: IInterface);
var
  myVisitor: IShapeRectangleVisitor;
begin
  if Supports(Visitor, IShapeRectangleVisitor, myVisitor) then
    myVisitor.VisitShapeRectangle(Self)
  else
    inherited;
end;

procedure TAbstractShape.Accept(Visitor: IInterface);
var
  myVisitor: IAbstractShapeVisitor;
begin
  if Supports(Visitor, IAbstractShapeVisitor, myVisitor) then
    myVisitor.VisitAbstractShape(Self)
  else
    raise ENotSupported.Create('Visitor doesn''t support ' + ClassName);
end;

end.

As clean and elegant the visitor pattern might look in the first place, it nonetheless has its disadvantages. Say, we want to add a new shape TShapeTriangle. We have to do it inside the same unit the other shapes are declared. As the shapes reference the visitor and the visitor references the shapes we have to put all shape classes together with the visitor into the same unit. Although this might work in some smaller scenarios, it definitely doesn’t in most of the real ones. Probably this is one of the reasons why the Visitor Pattern is not as famous as it should be.

Can we find a solution? Yes, we can!

Lets examine why there is such a close coupling between all the shapes and the visitor: The shapes use the visitor’s method corresponding to their own class and the visitor has to know about all the shapes it has to handle. How can we break this up?

The answer are interfaces! Instead of declaring a visitor capable of handling every defined shape, we declare an interface for each shape that only handles that specific shape.

unit uShapeBase;

interface

uses
  Classes;

type
  TAbstractShape = class
  public
    procedure Accept(Visitor: IInterface); virtual; abstract;
  end;

  { we avoid ref-counting here }
  TShapeVisitor = class(TInterfacedPersistent)
  public
    procedure Visit(Instance: TAbstractShape);
  end;

type
  TShapeRectangle = class(TAbstractShape)
  private
    FX0: Double;
    FX1: Double;
    FY0: Double;
    FY1: Double;
  public
    procedure Accept(Visitor: IInterface); override;
    property X0: Double read FX0 write FX0;
    property X1: Double read FX1 write FX1;
    property Y0: Double read FY0 write FY0;
    property Y1: Double read FY1 write FY1;
  end;

  IShapeRectangleVisitor = interface
    ['{6F521E71-5DB8-4ECE-B453-60F9A3B8BE22}']
    procedure VisitShapeRectangle(Instance: TShapeRectangle);
  end;

type
  TShapeCircle = class(TAbstractShape)
  private
    FCenterX: Double;
    FCenterY: Double;
    FRadius: Double;
  public
    procedure Accept(Visitor: IInterface); override;
    property CenterX: Double read FCenterX write FCenterX;
    property CenterY: Double read FCenterY write FCenterY;
    property Radius: Double read FRadius write FRadius;
  end;

  IShapeCircleVisitor = interface
    ['{27D7DCD3-952A-4879-8667-E86023612BFB}']
    procedure VisitShapeCircle(Instance: TShapeCircle);
  end;

implementation

uses
  SysUtils;

procedure TShapeVisitor.Visit(Instance: TAbstractShape);
begin
  Instance.Accept(Self);
end;

procedure TShapeCircle.Accept(Visitor: TShapeVisitor);
begin
  (Visitor as IShapeCircleVisitor).VisitShapeCircle(Self);
end;

procedure TShapeRectangle.Accept(Visitor: TShapeVisitor);
begin
  (Visitor as IShapeRectangleVisitor).VisitShapeRectangle(Self);
end;

end.

The common answer to this question is No. Once I was even confrontated with the question “Does anybody use it in real code at all?”.

Well, I do – and here I’m going to explain the why and the how. Actually there are different hows and at the end I will introduce a real elegant how…

Some basics: the Visitor Pattern is used to decouple an operation from the class it operates on and thus allows to create new operations without changing the class.

Let me give you an example: Assume we have a shape class providing the necessary properties to define the shape completely. To draw the shape onto a TCanvas we can introduce a Draw method with a Canvas as parameter. Easy done and easily extended to other shapes. We normally would introduce a TAbstractShape with an abstract Draw method ond override this in the derived classes.

Next task will be to store the shapes somehow into an inifile and read it back. The classical approach would be to introduce two methods LoadFromFile and SaveToFile each with a TCustomInifile parameter probably accompanied by a section name. I’m sure we’ve all done that before.

Requirements change: the drawing should be done with OpenGL and instead of inifiles we use XML now – but the other behaviour has to remain for compatibility reasons. I know, there are OpenGL wrappers that emulate a TCanvas and so are XML wrappers emulating a TCustomInifile, but honestly – such an approach is just crap, isn’t it? We have to introduce some overloaded methods with an OpenGL context for drawing and an XMLDocument for reading and writing to get this done properly. Oh, I just heard someone mentioning Direct3D…

We are actually following a pattern here: introduce an abstract method in the abstract ancestor and implement the specific behaviour in the derived classes. As a side effect we have to use a bunch of units in the abstract class that normally wouldn’t belong there. This can be really awkward when you need the classes, but don’t use the additional functionality, like drawing to OpenGL or writing to XML. Although a perfect valid object-oriented approach, it doesn’t contribute to the modularity of the application.

Here the Visitor Pattern steps in. Its goal is to move the operations from the class (in our case TAbstractShape and descendants) to different visitor classes. So there will be one for drawing to a TCanvas, one for the OpenGL output, two classes for reading and writing inifiles and two for reading and writing XML files.

Beleive it or not, but ranting and shouting will not change anything about the upcoming release. I suggest to calm down and start talking decently with each other.

Obviously the people at Embarcadero have something to explain and just missed the point to do it properly in advance. That might have been the wrong way, but honestly, we are all human and talking about bad news is nothing we are keen to do.

So be generous. Imagine you were in their position. Let DavidI and Mike Rozlog take a breath, wait what they have to say and then decide on the information you get.

Staying with Delphi or going away is no decision that has to be done today or tomorrow. It should neither be done during a heated situation like we have now.

After all we are still developers. We are used to tackle a problem with logic instead of speculating and ranting. I am not aware of any bug that has been fixed by shouting at it.

There is something going wrong, no question. Lets start a debugging session and find out what it is and how to fix it.

I don’t want to start a new flame war about garbage collection (and even when – hey, this is my blog!), but I for myself I’m glad that Delphi doesn’t offer such a feature. We are always tempted, aren’t we?

Not that I don’t have any memory leaks in my programs. Not that I don’t use memory already freed. But with the right tools you can actually spot those errors and solve them. Doing so I often find some other error lurking in my code, just waiting to pop up like a jack-in-the-box. If there were no more such leak hunting, I would know less about my code than I do now.

Delphi doesn’t lack garbage collection – Delphi doesn’t need one.

take an enumerator, mix it with a class helper and pour it over an invokeable custom variant

There it is again. What is he just talking about?

Well, it took me a while to find that thing, as it isn’t mentioned very often. But it turned out to be exactly what I needed. So I dived into the sources and figured out what TInvokeableCustomVariant is all about and how to use it. And even the help was in this case, um,  helpful: RAD Studio Help

It turned out that you can use such variants just like classes with properties and methods. Realizing this it sprang directly to my mind: if our enumerator can return such a variant instead of that semi-usefull record index, we can access the record fields like properties:

data.First_Name

That was the kind of code I was looking for!

As the class helper seemed to be able to cope with a little bit more, I made it responsible for returning the appropriate variant. The changes were made quickly: the enumerator’s Current property had to be a Variant and the class helper got an additional property CurrentRec also of type Variant, which is used by the enumerator’s GetCurrent method.

You need a couple of things to make your own TInvokeableVariantType descendant work. Obviously we need that descendant:

type
  TVarDataRecordType = class(TInvokeableVariantType)
  public
    procedure Clear(var V: TVarData); override;
    procedure Copy(var Dest: TVarData; const Source: TVarData; const Indirect: Boolean); override;
    function GetProperty(var Dest: TVarData; const V: TVarData; const Name: string): Boolean; override;
    function SetProperty(const V: TVarData; const Name: string; const Value: TVarData): Boolean; override;
  end;

We will only have one instance of that class, so we need a record type for storing the variant data:

type
  TVarDataRecordData = packed record
    VType: TVarType;
    Reserved1, Reserved2, Reserved3: Word;
    DataSet: TDataSet;
    Reserved4: LongInt;
  end;

This is a simplified form of the TVarData record declared in system.pas and as we only have to store a reference to the dataset it can be kept as simple as possible.

At last we need a global variable holding that instance of TVarDataRecordType, a function returning the VarType of that instance and another function creating a Variant of that type.

var
  VarDataRecordType: TVarDataRecordType = nil;

function VarDataRecord: TVarType;
begin
  result := VarDataRecordType.VarType;
end;

function VarDataRecordCreate(ADataSet: TDataSet): Variant;
begin
  VarClear(result);
  TVarDataRecordData(result).VType := VarDataRecord;
  TVarDataRecordData(result).DataSet := ADataSet;
end;

The Clear and Copy methods of TVarDataRecordType are pretty simple and just call predefined methods from TCustomVariantType. GetProperty and SetProperty is where the work is done:

function TVarDataRecordType.GetProperty(var Dest: TVarData; const V: TVarData; const Name: string): Boolean;
var
  fld: TField;
begin
  { Find a field with the property's name. If there is one, return its current value. }
  fld := TVarDataRecordData(V).DataSet.FindField(Name);
  result := (fld <> nil);
  if result then
    Variant(dest) := fld.Value;
end;

function TVarDataRecordType.SetProperty(const V: TVarData; const Name: string; const Value: TVarData): Boolean;
var
  fld: TField;
begin
  { Find a field with the property's name. If there is one, set its value. }
  fld := TVarDataRecordData(V).DataSet.FindField(Name);
  result := (fld <> nil);
  if result then begin
    { Well, we have to be in Edit mode to do this, don't we? }
    TVarDataRecordData(V).DataSet.Edit;
    fld.Value := Variant(Value);
  end;
end;

The only thing left to do is the implementation of GetCurrentRec from the class helper:

function TDataSetHelper.GetCurrentRec: Variant;
begin
  Result := VarDataRecordCreate(Self);
end;

That’s it! Now we can write code like:

    for Employee in QuEmployee do begin
      S := Trim(Format('%s %s', [Employee.First_Name, Employee.Last_Name]));
      if Employee.Hire_Date < EncodeDate(1991, 1, 1) then
        S := '*' + S;
      MemOutput.Lines.Add(S);
    end;

or

  for Employee in QuEmployee do begin
    s := Employee.First_Name;
    Employee.First_Name := Employee.Last_Name;
    Employee.Last_Name := s;
  end;

Magic, isn’t it?

You can download the complete sources from CodeCentral: 25386