Archive for the ‘Delphi’ Category

Making Sure Your App Doesn’t Leak like a Sieve

Sunday, April 19th, 2020

If you have been following the Delphi Roadmap, you know that a Unified Memory model across all supported platforms is coming.  That memory model is Delphi’s standard ownership model coupled with optional interface refcounting.  IOW, it’s completely up to the developer to ensure proper memory management just as it has always been.  Once this is the case, memory management, especially on memory “constrained” mobile devices will be very important.

FastMM4 provides memory leak reporting on shutdown, and since everyone has 80% or better unit test coverage using this feature, they probably don’t need have another tool in their toolbox ;-).  Just in case you don’t I would consider adding DeLeaker to your toolbox.  It does far more than just check for memory leaks, and it does so at run-time!

DeLeaker comes as both an external EXE and a very similar UI integrated into RAD Studio under it’s own menu.  The documentation is well written and tutorials are available to get you up to speed quickly.

One of the things I like most about DeLeaker is the ability for it to monitor resource consumption live.  As you use the application you can see the memory utilization and spot potential leaks as memory consumption grows, confirm them using DeLeaker’s detection and go to the relevant code with a double click.

It also supports taking snapshots as the application runs, and comparing them.  Did I mention it monitors not only memory, but also GDI, handles and other resources?

You might think I have AQTime included with Delphi, and I would ask where?  It hasn’t been provided with Delphi for a number of releases.  I have used AQTime and it’s a great product, but I recently discovered that the standard edition doesn’t even support 64 bit EXEs.  Smartbear seems more focused on it’s new web product portfolio so perhaps choosing a smaller vendor committed to supporting RAD Studio customers would be prudent.  At $599 $799 USD for AQTime Pro compared with $399 USD for Deleaker it’s a good value equation if you don’t need the additional features of AQTime Pro.

I have numerous tools in my toolbox, and I am always looking for new or better ones.  I am now adding DeLeaker to the list.

Happy Birthday Delphi!

Thursday, February 13th, 2020

February 14th is Delphi’s 25th Birthday.  Yes Delphi was introduced on Valentine’s Day, so no wonder I love it!  Anders Hejlsberg must be a proud papa!  Any tool that lasts 25 years in the software business is a great success.

I was a Turbo Pascal fan in school and graduated to using Delphi as my primary dev tool when version 2 shipped.  It was just better than anything else at the time!  VB didn’t have the speed of compiled code and I hated the language, but not quite as much as I hated C/C++.  Pascal was just so much more readable and elegant.

Not a day goes by that I regret not being a member of the M$ herd and dealing with all the churn in their APIs.  Delphi kept moving forward with an eye on backwards compatibility.  It says a lot when you can compile 25 year old source essentially unchanged.  This is one of the reasons I have seen, and helped build many industry leading applications using Delphi.

A lot of things have changed in the development space in the last 25 years, and Delphi has grown up during that time.  It now supports multiple operating systems, has a cross platform UI library, and is reaching for the clouds.  There is little you cannot do today with Object Pascal!

If you think Delphi is an old outdated technology, then think again.  Check out all the #Delphi25th celebrations. Give it a try…you never know it just might be your cup of tea!

IDE Generation of Interface Methods

Sunday, December 29th, 2019

Just a note to myself so I don’t forget, it’s possible to generate the methods for an interface in a new class that implements it, by pressing Ctrl+Space within the new class declaration.  A list of methods will appear, and you can multi-select them, press Enter and the method declarations will be placed in the class definition as public methods.  Using Class Completion (Ctrl+Shift+C) will the generate the implementation method bodies.

Not sure if or where this is documented as it only took 20 years before I came to know it via others on DelphiPraxis.


Saturday, November 30th, 2019

hcOPF was germinated around the time frame of Delphi 7 when I realized that dataset based applications of any complexity really became a maintenance nightmare over time.  I found that data was often stale and inconsistent in a database application because each view was tied to a different dataset.  There was no way to know when the dataset had to be refreshed, so unnecessary refreshes were often performed causing the applications to be very chatty with the database server.  Also the validation logic tended to be implemented in the UI forms and so over time, as the business rules changed, it became difficult to ensure consistent, correct validation.  There was no separation of concerns, UI code was intermixed with business and database logic.  Delphi RAD apps became spaghetti code or big balls of mud. Using objects to model the real world is much more intuitive.

Many developers using Java and other technologies were using ORMs so I started working on one myself and along the way borrowed ideas from other ORMs.  I wanted a framework that provided the encapsulation of data in objects, making applications easier to maintain over time.  Encapsulation has the advantage that to add a new attribute to a business object you only have to modify the class and that attribute becomes available throughout the application, wherever an instance of the class is used.  Contrast that to a dataset based application where you would have to modify practically every form and query/dataset where the new column should appear. Missing places, or not providing validation when editable was easy to do.

In 2009 I released hcOPF as an open source project on SourceForge.  hcOPF is different than modern ORMs that use PODOs.  Such frameworks use Delphi’s newer RTTI to access attributes.  Back when I started the framework the extended RTTI wasn’t available, so I created an ancestor class from which all persistable objects must descend.  To define a business object the framework requires you to create mapping MetaData to describe the object in terms of tables and columns.  An Object can be from a single table or the result of multiple tables joined together.

Without knowing the framework, it can be a little daunting to create object definitions, and even when you know the framework, creating object MetaData can be a tedious error prone affair.  I used the copy/paste/modify approach but that doesn’t take into account the datatype the data access layer uses for a column.  Different DALs can map columns to different field types so this resulted in lots of additional changes needed that were only discovered at run-time. For these reasons I have been working on a Code Generator tool; hcOPFCodeGen.

The code generator will currently scaffold an object definition, but it needs many improvements to support all the permutations in defining an object.  I am still working out all the use cases.  For now, it should help save time by generating a basic definition that can be further customized as needed. I have removed all commercial dependencies.  The code generator now only requires the JVCL and VirtualTreeView.  The code can be found here.

The beauty of Delphi is that it allows you to leverage your code investment with minimal churn.  It’s quite easy to migrate legacy code to later versions of Delphi with small incremental changes.  hcOPF can be used with Delphi 7 to Delphi Rio.  You may encounter some compilation issues because I have not employed a CI server to maintain hcOPF, but I plan to in the near future as time permits.

hcOPF Dialog Validation

Monday, September 30th, 2019

Reminder to self, when presenting a dialog for editing an hcOPF object a generic OK button click or action Execute handler is:

procedure TfrmObjectDialog.btOKClick(Sender: TObject);
  ValidationErrorList: ThcValidationErrorList;
  //switch focus to another TWinControl to ensure the current focused editor
  //updates it's Subject
  SelectNext(ActiveControl as TWinControl,True,True);

  ValidationErrorList := ThcValidationErrorList.Create();
    if hcUIObjectBinder.BoundObject.IsValid(ValidationErrorList) then
      hcUIObjectBinder.BoundObject := nil;
      ModalResult := mrOk;
      MessageDlg(Format('Please Correct the Following Error(s)'#13#10#13#10'%s',

        //focus editor for first invalid attribute
        if (ValidationErrorList.Count > 0) and
         (assigned(ValidationErrorList.Items[0].Attribute)) then

     ModalResult := mrNone;

And for the Cancel button:

procedure TfrmObjectDialog.btCancelClick(Sender: TObject);
  hcUIObjectBinder.BoundObject := nil;
  ModalResult := mrCancel;

or if you are using the VCL you can Inherit or Copy the hcDialog object found in the \Source\UI\VCL folder. I would suggest adding it to the Object Repository to make it easier to do so. There are comments in the unit suggesting how to use either design-time or run-time bindings.

Doubling Down - Fixing Min/Max() for Doubles

Tuesday, September 17th, 2019

Today I discovered that the built-in overload for Min() and Max() double in the Math unit do not always work as expected when you don’t care about a great deal of precision.  If you search on how to compare floating point types there are many StackOverflow answers, none of which have been adopted over the years by the built-in library.  I have come across this issue of the comparison of floating type values more than once, but keep forgetting not to use built-in functions.  I discovered that the code I was using to determine the range of values was failing on

MyX := Max(MinDouble,0);

MyX was not 0 as I expected because the value is used for a measure of distance for which I only cared about 3 decimal places, so I created a new Math unit with functions that return the expected result.  Hopefully this helps someone else or prevents me from falling into the same hole again.  Naturally these methods should also have overloads for the other floating point types.

unit unMath;



function Max(const Value1, Value2 :double) :double;
function Min(const Value1, Value2 :double) :double;


function Max(const Value1, Value2 :double) :double;
  relationship :TValueRelationShip;
  relationship := CompareValue(Value1,Value2);
  if (relationship = GreaterThanValue) then
    Result := Value1
    Result := Value2;

function Min(const Value1, Value2 :double) :double;
  relationship :TValueRelationShip;
  relationship := CompareValue(Value1,Value2);
  if (relationship = LessThanValue) then
    Result := Value1
    Result := Value2;


Adding a New Attribute to hcOPF

Friday, September 13th, 2019

In order to support a client using SQL Server with replication I needed to add GUID support to hcOPF.  This post is a chronicle of my efforts.

If you’re unfamiliar with ThcAttribute you can breathe a sigh of relief.  It’s analagous to a barebones TField implementation which contains two native Delphi scalar fields used to store the original value of the attribute as read from the object store, and the current value as manipulated by the user.  It also contains two booleans to track whether the value of either field is actually NULL.  Using native Delphi fields of the corresponding type to the database field type minimizes the amount of memory required (a variant is 16 bytes), and still provides functionality similar to the Nullable types found in .NET.  If you’re talking to a database,  NULL <> ” or 0 so you need to provide full support for database NULLs.

First I created a new unit, hcGUIDAttribute and created a corresponding class descending from ThcAttribute.  Since a GUID doesn’t have many valid forms (you can’t convert it to a boolean, integer, or float for example) the number of methods that needed to be overridden is quite small.  Perhaps this is not the best example for what needs to be done when implementing a new attribute type, but it may provide some insight into the framework since ThcAttribute is a fundamental building block.

Since a GUID can really only be represented by a string, variant, or a TGUID we only have to override SetAsString, SetVarValue and their symmetric equivalents GetAsString, and GetAsVariant.

There are three abstract virtual methods on ThcAttribute.  All of these methods are declared as abstract because they must access the native Delphi fields used for the storage of values.  Since only descendants of ThcAttribute declare the private storage fields, these methods must be implemented in descendants, and the code is always the same:

SetOrigAsVariant():  This method sets the original value of the attribute as it was loaded from the database (assuming it ever was).  This method is used by the OriginalValue property to populate the native field FOriginalValue.  Since the framework populates the objects from the database, you may wonder why we need an OriginalValue property in the first place.  The answer is, so we can load single objects we know exist, from the datastore by populating it’s values and calling ThcObject.Read().  The framework also needs to be able to set an object’s OriginalValue as it propagates Primary Keys to child objects without knowing the native datatypes involved.

There are also two virtual methods that must be overriden in all descendants, but are not declared as abstract; ResetModified and UndoChanges.  These methods reset change tracking after the database has been updated, or reset the values back to those read from the database respectively,

Then I added code to ThcAbstractFactory.GetParameterValue for GUIDs and ThcAbstractFactory.PopulateAttributes method to populate the attribute from a database TField.  With a few miscellaneous support methods in the hcGUIDUtils unit  to generate new GUIDs and strip/add brackets to GUID strings it was ready.

Unlike most ORM/OPFs hcOPF supports complex PK/FK constaints and of types other than INT.  The SQL Server system I wrote that required GUID support has been running now for 10 years with minimal issues.

FireDAC TFDScript component - Bug or Feature?

Sunday, September 8th, 2019

When switching a project from using the Spring4D ORM to hcOPF I was forced to change the implementation of the CreateDatabase functionality that was so easy to implement using Spring4D.  Now I am using a TFDScript component with multiple scripts which naturally have to match the MetaData definitions used by hcOPF, but cannot be easily derived from that MetaData.

I dropped a FireDAC TFDScript component in my datamodule and added 3 named scripts:

TFDScript with 3 SQL Scripts

TFDScript with 3 SQL Scripts

Then in my CreateDatabase method I added code to execute each script like the following:

  Script := FDScript.SQLScripts.FindScript('CreateDatabaseContent');

Much to my surprise only the first script was executed followed by an AV, so I started tracing into the code only to find that the very first line of code in the ExecuteScript() method calls SQLScripts.Clear!  This means you cannot use the SQLScripts collection for any more than a single SQLScript at a time if you make this method call.  So why then would it be a public method?  Why would it even exist?  Why isn’t there an FDScript.ExecuteScriptByName(’CreateDatabaseContent’) method?

procedure TFDScript.ExecuteScript(const AScript: TStrings);
  SQLScripts.Add.SQL := AScript;
  SQLScriptFileName := '';
  if Status = ssFinishSuccess then

According to my interpretation of the documentation ExecuteAll should execute all scripts in the SQLScripts collection in the order in which they are defined. Using the FireDACMonitor and tracing through the code showed it only executed the first script (index 0).  As a result, my ugly hack to make the component work they way it should (correct me if I am wrong here) is:

  for I := FDScript.SQLScripts.Count -1 downto 0 do

Either I am missing something fundamental, or the TFDScript component is badly broken and/or documented. I have created RSP-26131 in case I haven’t lost my mind, so please vote for it.

hcOPF now supports FireDAC

Saturday, September 7th, 2019

In my last post I talked about how unfortunately Spring4D does not provide change notifications so that developers can easily determine if an object graph has been modified and needs to be persisted.  It was primarily for this reason I decided to change the persistence layer in my latest project to hcOPF.  Obviously, I’m more familiar with this ORM, and I know it’s viable because systems I have authored 10 years ago are still being used without issue.  Even though I am using Delphi Rio 10.3.2, with lots of new language features, I don’t have time to thoroughly investigate and learn other alternatives. Change notifications will allow me to implement data auditing, and the validation & binding framework functionality will ensure any data editing is easily crafted.

Unfortunately, IBX no longer works well with Firebird 3.04 even if you can actually find a version for the latest Delphi editions.  I already ran into issues with UIB supporting larger varchar columns so that was not an option.  Instead, I decided to implement support for FireDAC, in part because it had been requested and because my Spring4D implementation with FireDAC proved to be performant.  The implementation was basically a copy/paste/modify of another DAL layer.  It currently does not support StoredProcs, but queries work. More testing and additional unit tests are needed, but it should allow developers to get started using FireDAC.

I also added support for quoted column names which is a Firebird requirement if you use mixed case names.  I’ve been dogfooding it for about a week now, and ironing out a few issues encountered.  I’m pleased with the performance, as hcOPF seems to be faster than my Spring4D ORM implementation.  If I get time I will try to put together some benchmark comparisons.  My only explanation for this would be Spring’s use of RTTI.

FireDAC was added for Rio and then Tokyo. Projects should be easy to back port to other recent Delphi versions. There is one demo specific to FireDAC in the Demos folder with projects for Rio. That should show you how to get started, and it’s essentially the same for all DALs;  create a datamodule, drop a connection and all the hcOPF components on it, link them, and configure your database connection.

FireDAC DataModule Components

FireDAC DataModule Components for a Firebird Database

Spring4D ORM Change Tracking

Sunday, September 1st, 2019

Spring4D’s ORM uses an instance of an IEntityMap to perform change tracking. The default implementation is essentially a threadsafe wrapper around a Dictionary that uses an entitykey of the classname + ‘$’ + the object Id and the Value portion is an array of member values. If an object instance is present in the EntityMap, IsMapped() returns True.

As objects are mapped from ResultSets, they are added to the the EntityMap capturing their values as read from the database. If you want to see what changes were made to the objects you must call GetChangedMembers() which returns a list of attributes for columns that have changed. In effect Spring4D keeps two copies of the data for a given object: the data in the object instance itself and the EntityMap, which is a reasonably compact version of the data as it was originally read from the database result set.

hcOPF takes a different approach, in that each object instance essentially has 2 identical field variables for each attribute and a boolean field to track Nulls. The advantage of this approach is that you can easily test each attribute to see if it’s NULL or has been changed, in user code without testing all of them. Since the implementation does not use RTTI it is likely faster, and hcOPF Attributes surface change notifications. Of course the trade off is larger object instances.

Change Notifications are a very powerful mechanism for both the framework and developer code. They can be used to trigger attribute level validations, provide GUI feedback of modification status and provide for very granular efficient calculations on attributes. In fact these change notifications are the basis for hcOPF’s ability to save an object graph to the database by simply calling object.Save on the root object.  Some frameworks like mORMot have even implemented database auditing tracking.

Sadly, Change Notifications are something missing from the Spring4D ORM. If you want to know if a an object has been Modified you can of course add a FModified boolean field and set it in each property setter after checking if the value being set differs from the current value. It’s a roll your own state tracking that you would expect the ORM to do for you, and it doesn’t take into account situations where the user modifies an object property and then changes it back either by Undoing the change, or changing it back to the original value.

In developer code, change notifications can dramatically simplify logic to save data when the application allows users to modify numerous root objects with the ability to undo changes. It can become quite difficult to determine what method calls are required to save all changes with Spring4D when you don’t know what has been changed in the first place.