The Art of Delphi Programming

Back from Delphi Developer Days (Kudos to Marco and Cary) and after cleaning up the mess in my inbox I would like to share some thought I had during one of the sessions named “Delphi: Today and Tomorrow”.

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? Continue reading “On Upgrading Delphi”

In Delphi’s TThread class there is Synchronize to call a method in the context of the GUI thread. This is necessary in case, for example, you want to update a progressbar or a status label in a form, because the VCL is not thread safe. While Synchronize is a blocking method (i.e. the thread code continues when the GUI thread has finished the method call), recent versions of Delphi introduced a non-blocking Queue method.

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. Continue reading “Synchronize and Queue with Parameters”

The interface approach introduced in Part 2 of this series and extended in Part 3 did cover most of our needs. But there is nothing that can’t be done better with the right tools.
Continue reading “The Visitor Pattern – Part 4”

In Part 2 of this series we learned about a more flexible implementation of the Visitor Pattern than the traditional approach. But we can do better.
Continue reading “The Visitor Pattern – Part 3”

In Part 1 of this series we learned about the benefits of the Visitor Pattern and saw a basic approach according to the GoF description.

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!
Continue reading “The Visitor Pattern – Part 2”