Embarcadero FireDAC – Great Video

Embarcadero are pretty good about training webinars. These are a great way to get more out of their products. Invariably the live seminars appear on youtube after the event (although watching them on youtube means you don’t get the chance to ask questions in the live Q & A sessions at the end of the webinar).

 Here’s a link to one such particularly good webinar recording on using FireDAC, presented by Cary Jenson. Take a look !

FireDAC in Depth – by Cary Jenson


Naming Advice – A Rule

Consider this:

If you have to write a comment in your code is it because you haven’t named your variables or functions well? I very very many cases the answer is yes.

Here’s a simple example

Consider the case of a control system for a passenger lift in a tower block. You have some digital inputs in a class called DigitalInputs and this has a series of functions to get the values of the inputs wired to input pins on your hardware. Lets suppose your software wants to check if the doors of the lift are safely closed (if they are the software may then start to move the lift to a different floor).

If the door is closed limit switch is wired to pin 16 for example your code might be:

if (DigitalInputs.Pin16IsActive()) {
// … your code to start the lift moving goes here

At a later date you may think this is not particularly well written so you choose to add a comment:

if (DigitalInputs.Pin16IsActive()) /* check the door is closed */ {
// … your code to start the lift moving goes here

This is clearer than the first sample. But a much better improvement is not to add the comment but instead to rename the member function Pin16IsActive() in class DigitalInputs to a better name, for example LiftCabDoorIsClosed(). The code then becomes much more readable (without comments)

if (DigitalInputs.LiftCabDoorIsClosed()) {
// … your code to start the lift moving goes here

The big bonus is that now, everywhere this function is called throughout the code, it is clear what is being checked.

Naming rule: If you have to write a comment in your code think to yourself “is it because a variable or function is badly named?”

Embarcadero Road Map for 2017/2018

Embarcadero have just updated their published road map

As usual C++ development follows hot on the heels of the latest Delphi enhancements and, as usual, you feel “as soon as we have that, it will be really good product” !

There are lots of exciting things to come, take a look:


Embarcadero In London

PawelGlowackiInLondonJust back from the Embarcadero presentation in London, at which the principal speaker was Pawel Glowacki. The photograph shows Pawel in a characteristically friendly mood and also the venue’s bar menu! A very interesting day highlighting recent innovations in the latest Tokyo 10.2 release of RAD studio.

Small but significant improvements in the IDE (including the first tastings of “Quick Edit” of component properties (currently just VCL but FireMonkey promised for the future) were followed by an introduction complete with demonstration to AppTethering. This powerful (yet easy to implement and use) technology is also available with the new Linux Delphi compiler which was also covered in some depth.

The presentation also included the FireMonkey for Linux desktop third party application that has been developed by one of the key designers behind the original FireMonkey development. I was not the only one in the audience who was curious as to why this branch in the “Embarcadero RAD studio does everything” tree was being developed by a third party company.

The fairly intensive morning was concluded with an introduction to the power of RAD Server (previously known as Enterprise Mobility Services) including an example showing how it can be used to run specifically developed RAD server *.bpl packages.

Stephen Ball was also on hand to provide up to date information on the latest version of InterBase (InterBase 2017).

The drive behind the day was provided by the UK Embarcadero software reseller, GreyMatter. It is great to meet other enthusiastic Delphi and C++ developers and to pick up tips and development methodology from Embarcadero experts.

The First Thought Counts !

What is the difference between a good software engineer and a weaker software engineer?

Answer: When you give a weak software engineer a new job the first question they ask themselves is “how am I going to design this?” where as the good software engineer asks themselves “how am I going to test the code?”

Be aware that “job” could mean developing a new class to represent a simple concept or it could mean developing a complete database management system for a large corporation.

Working With Embarcadero C++ Tokyo

The latest version of Embarcadero C++ is Tokyo 10.2. I have installed this and all went smoothly. There are some cosmetic improvements to the menu structure over previous versions.

 The main push with this version has been the Delphi support for Linux server code development.

This move is a welcome one for many designing / building server client software systems.

 But targeting of Linux from within a C++ code base is not yet available (it soon will be !).

 What us C++ programmers do have is support for the high level CLANG compiler optimisation -O3 and also improvements to the CLANG compiler linker operation.

You can download a free C++ Builder trial here.


Embarcadero C++ Tokyo – now released!

Embarcadero C++ Tokyo

It has arrived! You can see a full list of features here


 or a summary of what’s new, here.


You can download a free Delphi trial here.


 You can download a free C++ Builder trial here.


I am going to download and install my copy this weekend……


Embarcadero C++ Tokyo

A new version of Embarcadero’s flag ship product, RAD Studio is soon coming out. It will be called Tokyo and as usual can be purchased complete, just Delphi or just C++. One of the key Embarcadero staff, Pawel Glowacki, is on the road now publicising the new features, including the support for Linux servers. Pawel’s presentation in Prague

I will have more to say about this release when it becomes available to the public, so watch this space.

Problem solving

I have “lost” a lot of time recently getting to the bottom of a particular problem with my code. The code in question was written using Embarcadero C++ and used the FireDAC database interface to read and write to MS Access tables. The bug was in the way I was configuring the FireDAC system, but this is of little importance to what I want to talk about; my advice here applies to any problem solving (it’s not even specifically tied to programming).

 To solve a problem try to apply the following principles.

 1) Understand the problem. Make sure you dig below the symptoms to focus on the actual problem. Often this is much more difficult to do than you would first think. Many of the following points are actually ways to help achieve this.

 2) Isolate the problem ( narrow it down ) to as small and simple case as is possible. Strip away any code that might influence what is going on to home in on the “guilty” feature. In many cases doing this suddenly creates a “working” version. If it doesn’t then you can end up with a small segment which contains the problem and which is easy to analyse and easy to modify and test.

3) Design tests which will yield more information. Before you run a test consider what you are trying to prove and what different sets of results you might get. Know what each set of results will imply or disprove. Be ready for “unexpected” results.

 4) Read the manuals! Make sure you really understand what you read. It is surprisingly hard to write concise and accurate yet easy to understand technical manuals. Get to know your manuals and how well they are written. Manuals that are good should be read very carefully. Manuals that are less suspect need to be read with a “detectives mind” so that you really understand what is going on.

 5) Take a step back. Is there something unrelated to your line of enquiry going on? (Some might argue that this is a restatement of item 1).

 6) Sleep on it! I don’t pretend to be a psychiatrist but there is no doubt that good ideas for problem solving happen overnight. An early night is a much more valuable approach than working through into the small hours.

 7) Don’t work under pressure. If you have a deadline approaching remind yourself that you won’t get results any quicker any other way than working slowly, methodically and systematically. If you have a boss applying pressure then keep him/her up to date with what you are doing to work through the issue and explain that this will yield a result and that patience is required. Be careful not to create your own stress. Go for a walk up a hill (or whatever you do to relax as long as it is away from your computer screen) and come back to the problem refreshed.

 8) Believe in yourself but be aware that some problems are tricky and take time to solve.

 9) Don’t be afraid to ask for help. If you have a colleague talk the problem through with them. Just the act of explaining a particular challenge can make you think of a new way of looking at it or a new possible cause.



Welcome to my [Roger’s] blog where I plan to share useful snippets of programming advice along with other tips that will help fellow programmer’s to design and write good code.

 There will be a bias towards C++ since that is my language of choice. But many principles will apply to programming in general.

 I am a member of the Embarcadero C++ Most Valued Professional scheme.