Andreas Hausladen has released his latest DevExtensions and IDEFixPack for Delphi 10.2, just the latest release of fixes for things that Embarcadero should have fixed before pushing the “It’s Ready” button.
My most recent posts have prompted a bit of discussion, and it seems some concern, regarding the implementation of Boolean values in Delphi. The concern at least I think is unwarranted, as long as you avoid explicitly comparing a Boolean value to the True constant and allow the compiler to logically evaluate the Boolean itself. But in the follow up investigations of one commenter (thank you Arthur), a further occurrence of the alternate -1 identity of True has been identified: Variants.
It has been observed that the Delphi documentation states that the constants True and False have the values 1 and 0 respectively, not the -1 and 0 that the default string conversions apply. This does actually make sense but also lays a trap for the unwary.
Jaap Van Goor was asking on FaceBook about some seemingly strange behaviour when obtaining string representations of Booleans using the Delphi RTL, which led me to revisit some familiar (and some not so familiar) old Delphi ground and take a look at the area involved in further detail.
With the lack of any easily available information from Embarcadero, in yesterday’s post I had to speculate as to the cost that might be involved with the new Delphi for Linux. According to comments it seems that I was being overly generous by suggesting that only a Pro Edition of Delphi would be required (so much for people who think I go out of my way to criticize). Unfortunately this does now appear to have been confirmed in the latest “amnesty” email from Embarcadero.
It has been difficult to avoid the fuss being made about the “new” Linux support in Delphi. It’s almost as if they didn’t have a Linux offering more than 15 years ago. I refer of course to Kylix, which failed in no small part due to the quality and the cost of the tool, for a platform where “free” was the more usual expectation and open source means being able to fix your own tools instead of waiting for the vendor to deign to offer a maintenance release. So what better chance does a Delphi with Linux support stand this time around ? Let’s see…
The recently sign-posted potential acquisition of Embarcadero by Idera has now been officially confirmed by a press release from Idera, as reported by The Register.
Yesterday I posted about an issue with type checking in Delphi (and other Pascal) compilers. As mentioned in that post, range checking is fundamentally flawed as a supposed solution to the problem for reasons that are explored further in this post.
A post came up in recent days on the NZ DUG mailing list, about a problem with the LoadXMLData() function on Android. The problem subsequently was found to also exist on Win32. And indeed, the cause was found to go back at least as far as Delphi 2006. So why did it only come up now ?
To address some odd concerns about differences between DUnit and Smoketest, I thought it would be useful to demonstrate how it is entirely within the gift of a Smoketest user to create their own “comfort” layer, to make using Smoketest more similar to the DUnit framework if they wish (though why in that case they wouldn’t simply use DUnit, I can’t quite fathom. But still).