Sunday, November 22, 2020

Delphi Event Bus 2.0 is here

 Hi folks,

I have been involved in the Ekon 24 conference and I held a session: Decoupling your application architecture using Delphi Event Bus. There I presented the 2.0 version of DEB and all the news along with this version:

  • Added new Interface based mechanism to declare and handle events
  • Added channels for simple string-based events
  • DEB available on GetIt 

Interface based mechanism

The new mechanism relies on the fact that an event must be an interface or its descendants:

This new architecture brings a great benefit in terms of memory management, because Interfaces are reference counted in Delphi. 

Breaking changes

  • Differently from the previous versions a subscriber method can only have 1 parameter that is an IInterface or descendants. 
    • You should change every Subscriber method to be compliant with that principle
  • On the same line of the previous one, because events now are interfaces EventBus.Post method can accept only an interface as parameter now
    • You should change every EventBus.Post method and pass it an interface - if you were using object with no interfaces 


A very nice addition is the possibility to subscribe and post simple string-based events:  

Other improvements

  • Improved the internal post mechanism removing the CloneEvent due to the fact events were objects
  • Removed external sources needed because of the point above

How can I get it?

Since the version 1.5 Delphi Event Bus is available in GetIt (the Delphi integrated package manager):

You can also choose to download/copy/fork the library from github:

or downloading directly the release from here:

Hope you find this version full of interesting features for you! 

Enjoy it!!

Monday, July 27, 2020

Delphi tips and tricks: Unknown custom attribute

Hacking, Cyber, Blackandwhite, Crime, Security

RTTI attributes are a Delphi language feature that allows you to add metadata information
to types and type members (comparable to C# attributes or Java annotations, to be clear). 
By attributes, you can add metadata information in a declarative way. An attribute is depicted
by square brackets ([ ]) placed above the element it is used for, the attribute can be queried at runtime by using RTTI techniques and you take appropriate actions when you think they are required.

That is just a short introduction to Delphi RTTI Attributes and because it is not the central topic of this post, you can find more information about it here:

As for every Delphi construct you have to import it: put the unit in the uses section to use a specif class, interface, function and so on... This is not really true for Attributes!

Let's take a look at this code, a simple console application:

As you can see the [MyCustomAttribute] it's not declared anywhere ( and trust me it's not declared in the System.SysUtils unit).
So what happens if we try to build the project? Curious?
We are able to build it with success:


This because the compiler produces a warning and not an error around the situation just described (using Delphi 10.4):

[dcc32 Warning] Project1.dpr(15): W1074 Unknown custom attribute

In some cases, you might write an incorrect attribute name, or not import the unit
containing that attribute and this could have terrible consequences at run-time: at first you could think that the RTTI Attribute is not working, the framework is not working and so on... but the real fact is that we didn't include the right unit or wrote an incorrect name and probably we didn't have a look to warnings. 

How can we be sure to have an error instead of a warning?

Up to Delphi 102, if you used a custom attribute that was not known to the compiler (because you typed it incorrectly or a unit was missing in the uses statement), you'd receive the warning:

Warning: W1025 Unsupported language feature: 'custom attribute'

The only way to turn it into an error was to set the Unsupported language feature to error. You had to go to Project | Options | Delphi Compiler | Hint and warnings | Unsupported Language Feature and set the value to error. From now on, every Unsupported language feature generates a compiler error. but that could have included also other unwanted scenarios.

Starting with 10.3, the same code will trigger a new specific warning as we have seen in the messages of the example project above:

Warning: W1074 Unknown custom attribute

Then now it is easier to turn this warning into an error by using the directive:


If you add the above line in the previous project and try to build it again you will receive this error and the build will fail:

This is a really nice tip to know as it can save you a lot of time around troubleshooting, just because you didn't have a look to warnings after you write an incorrect attribute name, or not import the unit
containing that attribute. I saw so many times developers in forums and OS projects complaining about the behavior of a framework/feature when the real "mistake" was in a missed unit or misspelled name.