A tip for using Firemonkey and VCL on different Embarcadero C++ projects

I use Embarcadero C++ for a lot of work. Sometimes Firemonkey is the right framework to use and sometimes VCL is. I have a lot of C++ files that contain classes that are equally useful for both frameworks.

 Instead of having

 #include <fmx.h>


 #include <vcl.h>

at the tops of the files, for all *.cpp files that can be applied equally in either framework, I use the following line:

#include “EmbarcaderoComponentLibrary.h”

The file EmbarcaderoComponentLibrary.h resides in every project I create and is edited once at the start of the project design. It contains the following lines (along with a load of comment statement which I don’t reproduce):


//Set these for each project requirements

#define ROGER_USE_VCL 1

#define ROGER_USE_FMX 0





#include <vcl.h>



 #include <fmx.h>






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.

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.