FMX for Linux

Embarcadero have announced that those on subscription upgrade with Architect or higher license for Delphi or RAD studio can now install the FMX for Linux package.

 This promises Delphi users the ability to use the Firemonkey framework to write Linux GUI applications and as such is a major new development.

 Again it shows the advantage that Embarcadero have when developing products based on their propriety form of pascal (Delphi = Object Pascal). They don’t have to jump through many hoops to get the compiler targeting different operating systems.

 Even though RAD studio uses versions of open source (clang) C++ compilers (thus theoretically requiring no “original” development) Embarcadero seem reluctant to develop and sell C++ equivalents to their cutting edge Delphi offerings.

 As well as the lack of FMX for Linux using C++ there is also the recent lack of commitment to provide 64 bit C++ support for Android and iOS.

 If you are looking at Windows only applications then Embarcadero C++ (VCL or Firemonkey) is still a sound choice. But, in this day and age, how can you be sure that your application will remain in the “Windows only” category?

 For more information on FMX for Linux search on line for the webinar of 9th July 2019 “Introduction to FmxLinux – Delphi’s FireMonkey for Linux Solution” presented by Jim McKeeth.

Advertisements

Embarcadero Latest Road Map (May 2019)

 The latest road map for Embarcadero RAD Studio, C++ Builder and Delphi is now available at the link below.

 Multi-device Delphi users will be impressed with soon-to-be-with-us options and multi-device C++ users may be less impressed with the failure of the C++ side of multi-device development failing to keep up…..

 It’s an interesting read, here’s the link.

Embarcadero Road Map (May 2019)

 

C++ / Delphi with SurveyMonkey and Twilio

Embarcadero RAD Studio (C++ and/or Delphi) provides a convenient set of tools for interfacing to many third party web based APIs. These tools are known as “Enterprise Connectors”.

 In an effort to publicise these useful technologies Embarcadero are running a series of webinars on some of the more common ones

In May 2019 its the turn of the (disparate) pair: SurveyMonkey and Twilio

Click here for more information

Linux GUI using FireMonkey ?

The FireMonkey framework (commonly abbreviated to FMX) allows cross platform development for Windows, MacOS, iOS and Android from the same code base (either Delphi or C++).

A very common question is “when is FireMonkey for Linux coming?”. Embarcadero are regularly asked this and their reply is always along the lines of “we are keeping an eye on it but at present the market place doesn’t make it worth while”.

Developing general purpose tools for Linux is challenging because there are so many different versions of Linux out there.

However one firm ARE promoting FireMonkey for Linux – using Delphi as the supported language.

Interested parties may like to take a look at FMX for Linux

Stick with one Editor

To many this may be obvious. But it’s amazing how many people use the editor that comes with each of their IDEs with the confusion that arises as a consequence of each editor supporting different “advanced” features and/or short cut keys etc.

The Embarcadero IDE editor is a good one. Having got to learn it “inside out” I now use it for all major program writing. For example when working with Freescale microcontroller C code I use the Embarcadero editor for all code creation and only use the Freescale “Codewarrior” IDE editor for quick fixes whilst in the debugger.

Can you do better than returning a bool?

It’s very common to write functions that do something or check something and then return “ok” or “failed”.

When writing such functions one’s instinct is often to return a bool value. Let’s think of some hardware that monitors a digital input coming from a switch which is active when a valve is open.

We might declare the function as follows:

bool ValveLimitSwitchIsActive(void);

This is a sensible choice, the digital input can only be either active or inactive (any other condition must be a hardware failure) and our function matches this physical reality.

But what about if we want to check if the valve is open? We could declare a function as follows:

bool ValveIsOpen(void);

Great! we can now start to write code that works with the valve, using this function as required. All looks good? Perhaps not. Perhaps we have an operation on our plant which demands that the valve is definitely energised (could be safety critical) as well as being fully open. Perhaps we also want to monitor how long it takes for the valve to actually open. We could generate more functions:

bool ValveIsFullyOpenAndEnergised(void);
bool ValveIsEnergised(void);

but it all gets a bit messy….

How about

enum class TValveState {FullyClosed, Closing, Opening, FullyOpen};
// Opening == energised but not yet reached fully open limit switch

TValveState GetValveState(void);

This is good because all the valve checking is in one place. If the design of the valve interface changes we only have to modify this one function.

This still has good clear legibility at when the function is called; no one can be confused by:

if (GetValveState(void) == FullyClosed) { // do something here }

Because of this form of calling, the same technique is also very useful when dealing with functions that are harder to name in such a way that a bool return value makes sense. Consider a database update. We could have a function

bool UpdateDatabase(…); // returns true if update was successful

We call this using:

if (UpdateDatabase(…)) { // do something here – task }

This works, but if you come back to this code do you know if the task is executed if the update was successful, or if it was unsuccessful? The only way to be sure is to back to the body of the function UpdateDatabase – very bad from a programming maintenance perspective.

A simple improvement would be to write

bool UpdateDatabaseWasSuccessful(…)

but now you have a function name that suggests a status check on the database, it rather hides the fact that an action is actually carried out.

Much better is to use:

enum class TDatabaseUpdateResult {UpdatedOk, FailedToUpdate};

TDatabaseUpdateResult UpdateDatabase(…);

Now the call is fairly concise and very clear:

if (UpdateDatabase(…) == UpdatedOk) { // do something here – task }

Again, if we later decide to return more error information (perhaps different reasons why the update failed) we can simply add extra enum names.

We could even change the enum to a full blown class and return this, if we needed to.

It’s a good technique: use it!

Embarcadero RAD Studio Rio 10.3.1 is here !

Embarcadero have just announced the availability of RAD Studio Rio 10.3.1. This follows (fairly) hot on the heals of Rio 10.3 which was released in Nov 2019

This release has some minor new additions but is basically a bug fix release. You have to uninstall 10.3 and then install 10.3.1 using the same type of installer (either ISO or www) that you originally used for the 10.3 install.

Registered users can use the following download links

RAD Studio Rio

Delphi Rio

C++ Builder Rio

The “Community Edition” (free of charge (subject to restrictions on use) version) is available at

C++ Builder Rio Community Edition

Delphi Rio Community Edition

Where is Android in the World?

Jim McKeith has recently posted a webinar replay called “Get the most out of Android with 10.3 Rio”. It’s worth watching and it’s at.

Get the most out of Android with 10.3 Rio

In the webinar Jim points out that Android is now the most used operating system in the world (in terms of numbers of devices it is installed on). He also points out that Samsung are much more involved in the control and steering of Android then many people realise (most folk just assume Android = Google).

Samsung have the “Dex” scheme (short for “Desktop Experience”) which allows users to quickly and effectively turn their smart phone into a desktop PC. Clearly another attempt at encouraging the world to drop Windows.

What does all this mean to software developers?

The short answer is that any new projects that are likely to be “on going” (and professionally developed software that isn’t aiming to be “on going” is a contradiction in terms) should be designed with a view to migration from one platform to another being a genuine consideration.

How to Design a Good UI?

One could write books on this subject (and people have done so). Of course what is good for one person may not be seen as such by someone else. This is particularly so when designing UIs to be used by people with little or no familiarity with the digital world.

One of the problems is that a good UI is also a moving target.

I used to advocate Windows applications as being easy to use if you just followed the simple rules:

1) Tell the computer what you “thing” you want to do something to, by selecting it (often a single click with the mouse or a click and drag).

2) Right click and pick what you want to do with the pop up menu.

This scheme used to work with all good Windows applications. Sadly this uniform approach has gone and users (particularly those in the “addicted to mobiles” category) seem to be happy with the chaotic “every application has it’s own way” approach.

Thinking and planning the basic approach to your UI design must be sensible. I find that David Millington’s three postings about this subject are a good succinct set of documents to read and consider before starting a new project.

David Millington’s Good UI Design – part 1

David Millington’s Good UI Design – part 2

David Millington’s Good UI Design – part 3

Is C++ a rigorously typed language?

One of the recent Embarcadero “CodeRage 2018” webinars was about some of the features in C++ 17.

This included some talk about the “auto” key word and associated encouragement to use it. I’m less convinced about using this in a carefree manner. When you declare a variable or (in C++ 17) a return value who is the sensible person to choose what type it is? The compiler or you?

It’s a great typing saver when you are declaring an iterator for one of the standard library containers (eg a vector). So use it for this.

But I’m not so sure about using it in cases where some careless modification of code might unintentionally change the type of a variable or return value. I feel (because I am used to it) that the strong rigorous typing enforced by earlier C++ standards (before the introduction of the “auto” keyword) is an advantage of the language not a disadvantage.

So yes, use “auto” but only WITH CARE.