Delphi Programming Tips & Tricks

RAD Studio update 10.3.2 has just been released, packed with new features and improvements; some big, some small. Big features Delphi macOS 64-bit C++17 for Windows 64-bit C++ LSP Code Insight Improvements Delphi Linux Client Application Support (recently released for 10.3.1, too) Smaller features RAD Server Wizards and Deployment Improvements Enhanced Firebase Android Support Enhancements and Improvements IDE Runtime Library Performance VCL Quality iOS C++17 Quality FireMonkey FireDAC & Database Web Clients You can find the full list with additional details at http://docwiki.embarcadero.com/RADStudio/Rio/en/10.3_Rio_-_Release_2 For Delphi developers targeting Windows, there are no big features to be thrilled about. But, 10.3.2 brings many smaller fixes and improvements making this update quite worthwhile. If nothing else, a faster IDE alone justifies updating sooner, rather than later. But don't take my word for it... just go and see for your...

New Delphi roadmap is live: https://community.idera.com/developer-tools/b/blog/posts/rad-studio-roadmap-may-2019 https://community.idera.com/developer-tools/b/blog/posts/may-2019-rad-studio-roadmap-commentary-from-product-management Important highlights 10.3.2 update will bring 64bit macOS support - mid 2019. 10.4 will add 64bit Android support - late 2019. Android developers on active subscription should keep an eye for 10.4 beta that will start this summer and will come with permission for beta testers to upload 64bit applications on Google Play Store. Also important notice for all mobile developers from 10.4 memory management will be unified across all platforms, which means ARC compilers will be gone.

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 scope Inline 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 count...

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(T...

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 1...

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 ...