With the common-place of High DPI it is surprising the IDE hasn’t gotten more love in this respect.
The VCL can do it (Dalija Prasnikar knows an awful lot about Delphi High DPI), but the IDE can’t yet (it is *****^H^H^H^H^H very irritating that you need to login to see quality portal reports though apart from Google not being able to index them: the main reason I don’t file bug reports any more – QC is no alternative as it it is more or less defunct – but I digress).
With Delphi turning 20 years old this week, hopefully Embarcadero comes out with official steps to make recent versions of Delphi XE* High DPI aware.
Unit testing has been here for a long time, and so has Unit Testing in Delphi. Below a summary of historic links together with some notes on how the state of affairs changed over the years.
Charlie Calvert
I’ll start with one of the first large Delphi Unit Testing articles was a paper by Charlie Calvert summarizing the state of the art on Delphi Unit Testing in 2004. It is present in the wayback machine as DUnit Talk and on his elvenware.com site.
The idea is that you solve a task and learn from that, or learn by seeing how others have solved tasks or draft tasks.
So in a sense it is similar to the Rosetta stone: it has different languages phrasing the same tasks.
There are already a whole bunch of languages on RosettaCode (of which a few are in the categories below), and you can even suggest or add your own languages.
When you want to solve tasks, be sure to look at the list unimplemented tasks by language that leads to automatic reports by language (for instance two of the languages I use most often: C# and Delphi).
Uwe Raabe was the first one to suggest that it might just be so that Castalia got acquired by Embarcadero. In the thread rumoured Usertility might as well been, or that Jacob Thurman might be responsible for IDE stability.
So today
Uwe Raabe confirmed it (in a private post) by pointing to an article on dbta.com (database trends and applications, go figure!),
Marco Cantù posted on this in his blog confirmed it too, causing a nice thread on IDE stability (we all need that as we depend on it; 3rd parties can provide and libraries, only Embarcadero and Andy can fix bugs) and ToolsAPI exposure (especially on the language parser side).
Speaking of which: a nice post on open array parameters, where you can pass an element which gets interpreted as an array. None of the parsers get this right, but the compiler does.
One of the features that bites me over and over again is the ZEROBASEDSTRINGS that got introduced in Delphi XE3 and is by default ON in mobile compilers and OFF in Desktop compilers.
Back then, Mark Edington showed a small example of the effects:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
The XE3 RTL source code has been refactored to be string index base agnostic. In most cases this is done by utilizing string helper functions which are always zero based.
When it is necessary to traverse a string, the Char[] property is often used to access the individual characters without concern for the current state of the compiler with respect to zero based strings.
In addition, the “Low” and “High” standard functions can now be passed a string variable to provide further flexibility as needed.
When zero based strings are enabled, Low(string) will return 0, otherwise it will return 1. Likewise, High() returns a bounds adjusted length variation.
The problem is the non-existent forward compatibility of the other compilers (Delphi XE2 and lower).
So if you have library code that needs to work in Delphi versions, you cannot use the High and Low to make the code ZEROBASEDSTRINGS neutral.
Many Delphi developers regularly skip many Delphi versions, so these are still popular:
Delphi XE1 and XE2 (the last 2 compilers before Delphi really started to support mobile)
Delphi 2007 (the last non-Unicode Delphi compiler)
Delphi 7 (the last non-Galileo IDE)
The result is that library code is full of conditionan IF/IFDEF blocks like these:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters