Delphi Programming Tips & Tricks

If you are not big fan of new Delphi IDE (light or dark ones) themes you are out of luck. They are default look and old Windows styled IDE is no longer officially supported.



In previous versions there was checkbox for enabling or disabling IDE themes. In Rio that checkbox is gone and you can only choose between default Light or Dark themes or use custom VCL Style.

But all is not lost. 

You can still disable themes by editing appropriate registry values.

Head to following registry key

Computer\HKEY_CURRENT_USER\Software\Embarcadero\BDS\20.0\Theme

and change following key-value entry:

Key: Enabled
Value: 0

If you wish to enable themes again just change Value back to 1.

There are two (OK, three) features I have been eagerly waiting for in Delphi.
The ability to have multiple class helpers (aka extension methods) in scopeInline variables and (3.) type inference While I will have to wait some more for the former, Delphi Rio introduced the latter, making me a very happy camper.

But it is not all perfect. Type inference does not work on reference counted classes. Or rather, it does work, but it breaks reference counting.

For example, this inline variable declaration:
var Ref := TInterfacedObject.Create; will be translated by the compiler into:
var Ref: TInterfacedObject := TInterfacedObject.Create;
In the above code, the compiler correctly infers the type - TInterfacedObject, but by doing so, it stores a reference counted object in an object reference. And as we all know, this kind of code breaks the reference counting mechanism. The famous "Don't mix objects and interfaces" rule.

To properly initialize reference counting, you have to expl…

Every once in a while, every developer encounters random bugs that happen only in production and cannot be reproduced at will. If you cannot reproduce it, you can hardly fix it. In such situations, recording exceptions with various error loggers can help us find the culprit and fix the error. However, sometimes the information collected simply does not contain enough data to do so.

This post is inspired by the following Stack Overflow question How to know the exact line number that produce an exception where the logger has recorded an exception and its call stack.

Argument out of range At address: $002CDD4B (Generics.Collections.TListHelper.CheckItemRange(Integer) + 62) Call stack: MyApp $00BB153D Grijjy.Errorreporting.backtrace(Pointer*, Integer) + 8 MyApp $00BB1427 Grijjy.Errorreporting.TgoExceptionReporter.GlobalGetExceptionStackInfo(TExceptionRecord*) + 74 MyApp $001C4D83 Sysutils.Exception.RaisingException(TExceptionRecord*) + 38 MyApp $001E903D Sysutils.RaiseExceptObject(TExcep…

Variations of the above question get asked on a daily basis and there is an increasing number of bug reports that state basically the same thing. Android applications compiled with older Delphi versions work, and simply recompiling them with Rio produces a non-functional application.
Is Delphi Rio broken? NO. So what happened? First of all, mobile development regardless of the toolset is a fast moving target. New versions of mobile operating systems are released on a yearly basis, introducing new features and breaking old behaviors. Applications submitted to both the App Store and the Play Store must satisfy some minimal requirements defined by their respective owners. While Apple has always been pushing for faster adoption of newer iOS versions, forcing developers to stay current and compile their applications using newer SDK versions, as of recently Google has started doing the same.

Just like there is a minimum requirement for submitted iOS applications to use minimum iOS 11 SDK, G…

First, forgive me if some of my thoughts seem a bit contradictory or confusing. My brain is still steaming... and I am not sure what to think...

Please, no...

What took you so long...

Nooooo....

But before, I start rationalizing...
ARC IS NOT BROKEN, IT JUST NEEDS SOME POLISHING... I have been saying for a long time that the dual memory management model is not good in the long term and there should be only one memory management system, but by removing ARC in Linux compiler (10.3) and future plans to remove it from mobile compilers, I am afraid that Embarcadero have opted for the wrong one.

Yes, ARC in Delphi has some issues, but those issues are fixable. Manual memory management is an obsolete technology. It has some niche use cases, but for general-purpose programming, you don't want to waste time on memory management. You want to focus on the real functionality of your code.

To be fair, every memory management model has its strong and weak sides. Every one is more fit for some purp…

It is common knowledge that exceptions raised in some piece of Delphi code can be caught and handled with try...except blocks.
No matter what. try // here goes some horrible or not so horrible code // that can raise the most horrible exceptions except // no matter how horrible exceptions are // you will always land here where you can handle them, // eat them up and pretend they never happened, // or do something and re-raise them // YOU ARE IN CONTROL end; For example:
type TFoo = class(TObject) public procedure Foo; virtual; end; procedure TFoo.Foo; begin end; var Foo: TFoo; begin Foo := nil; try // calling a virtual method on nil reference raises an Access Violation exception Foo.Foo; except Log.d('CAUGHT'); end; end; Capturing and handling exceptions within try...except blocks is one of the cornerstones of Delphi coding practices. Millions of lines of code depend on that exception trap, from which ther…