Uwe Raabe

Well, the FormatFloat implementation has the E15 hardcoded and even documented:

Well, FormatFloat acts as expected; for var I := 1 to 10 do Writeln(FormatFloat('', I/10)); for var I := 1 to 10 do Writeln(FormatFloat('', I*Power10(1, 14))); Output:

Have you tried with AxisValueFormat being empty?

At least that is how I read the license:

When you create a new test project and add one of the units for testing, the project won't compile unless all dependent units can be found. So you need to add the search paths accordingly. There is nothing wrong with having dependencies in the first place. It just makes picking only one unit from the project into another one a bit difficult. Nevertheless, it is always worth thinking about minimizing dependencies, but not only because of simpler testing. The not seems appropriate, but the term project to be tested should be changed to test project.

It depends on the actual sources. I have had projects that just needed a compile with the new version and target, while others lasted several months.

That could even be simplified to: for var btn in [Button1, Button2, Button3, Button4, button5] do btn.Enabled := not btn.Enabled;

First of all, keeping the default names for the buttons has never been best practice. While suggesting to have descriptive names for the buttons, this nevertheless is another way to iterate over any group of buttons: for var btn in [Button1, Button2, Button3, Button4, Button5] do btn.Enabled := True; And, no, you can't write [Button1..Button5] here.

The order of units with initialization code are better retrieved by the C=ICODE entries instead of the C=CODE ones.

Looks like it comes from GExpert.

AFAIK; the initialization order of units follows the order of the ICODE (Initialization Code-Segment) segments in the Detailed map of segments in the map file.

IMHO using inline variables and with together looks somewhat strange.

Sydney is 10.4!

You may have hard time to find something like that, because IMHO your formatting is not consistent: After then the begin is in the next line, but after else it is not. It probably boils down to having to write your own formatter.

Which APIs are you looking for?

The corresponding function is Ceil.

The FinalBuilder Action allows to specify a manifest, but it is not (yet) capable to build a new one from scratch. Seems you need to create one by yourself. Thankfully there is an article showing how to do it: https://www.finalbuilder.com/resources/blogs/windows-manifest-files

Can you try to replace the ctNone with ctAPPLICATION_JSON?

The Custom Body content doesn't look very JSON like. Try adding the brackets.

I didn't say the file exists. When a unit is neither provided as source nor as a compiled DCU, it can still be provided inside a DCP file, which is the case for the unit ImageCollectionEditor. It is contained inside dclwinx.dcp and thus can be used in other design packages. I cannot give a link or attach that file because it is not listed under the Redist folder of Delphi.

dclwinx.dcp is located in lib\win32\release in the Delphi folder and the corresponding design package (dclwinx280.bpl for Delphi 11) is located in the bin folder. You won't find anything on the web for it, neither the package nor the unit, because Embarcadero doesn't provide any information for it.

The package is part of the Delphi installation and the unit is included in the package. There is no source.

Try unit Imagecollectioneditorthe in the dclwinx package.

This Editor is for TImageList, not for TVirtualImageList. AFAIK, the editor for TVirtualImageList is not shipped as source.

He already mentioned before: As I already own a license for HTML Components there is a good chance that it may be included as an extension to the Unit Dependency Analyzer in MMX.