Why Actions never made it into Firemonkey

A couple of years back I went to se Pawel Glowacki present Firemonkey for the Norwegian Delphi community in Oslo.

Use the force luke!

During that meetup two good questions were asked by the audience. The first question was from Halvard Vassbotn, which i seem to recall asked about threading and “what is the point of a 3d spreadsheet”, and the second question was from me – asking if fire monkey supported messages. I already suspected that Firemonkey had no fallback mechanism for messages like Kylix had, but it was a serious question since the majority of Delphi applications rely on (or use) messages as a part of their architecture.

One of the benefits of Delphi over other languages is the introduction of Actions and Action-lists. Using actions to isolate code that can be connected to menu items, buttons and options is a great time saver. And more importantly, to be able to isolate testing of action enable states (should a button be enabled right now?) is really a game changer for RAD development. But for some morbid reason this has been omitted from Firemonkey, leaving people to write “somecomponent.enabled:=true” and “somecomponent.enabled:=False” all over their code. The entire point of actions was to get rid of this old-school problem. To this day C# or Visual Basic has nothing like it – and now Delphi/Firemonkey is taking a step backwards.

Interestingly enough, Pavel changed the subject faster than a weasel  – and ridiculed the question instead. Something which surprised me a lot, since he is supposed to be a professional representative of Embarcadero. And thanks for the keychain Pavel 😉 Everyone else got a t-shirt and a mug.. And you wonder why I make compilers [sic].

Either way, the reason Actions are not supported by Firemonkey because they are based on messages. Which is silly really because a simple callback system hooking into the application idle-time could have solved it. Making Firemonkey much richer in the process.