Leaderboard

A word of warning to those (I'm counting 50 since yesterday) that downloaded this version: If your resources contains bitmaps that were created by older versions of Delphi (or rather applications built with older versions of Delphi) then the resource editor might corrupt them on save. It appears that a bug was introduced in TBitmap between Delphi 2009 and 10.2. Here's the short version: The format of a windows bitmap is basically 1) Header, 2) Color table, 3) Pixel data. For bitmaps with PixelFormat>pf8bit the color table is optional. The Header specifies the number of colors in the color table (the TBitmapInfoHeader.biClrUsed field). Older versions of Delphi sometimes saved bitmaps in pf24bit/pf32bit format with a color table and the corresponding value in the biClrUsed field. This was unnecessary but harmless and perfectly legal according to the bitmap specs. Here's an example of what such a bitmap might look like: [File header] [Bitmap header, biClrUsed=16, biBitCount=32] [Pixel data] These bitmaps can be read by newer versions of Delphi, but when the bitmaps are written again they become corrupt. Delphi keeps the value in the biClrUsed field but fails to write the corresponding color table. The result is that the pixel data ends up at the wrong file offset. Here's an example of a corrupt bitmap: [File header] [Bitmap header, biClrUsed=16, biBitCount=32] [Pixel data] The reason why this is a problem for the resource editor is that it is built with Delphi 10.2. I have a fix for the problem but I'm not ready to release a new version with the fix. Here's the fix btw: // Fix for bug in TBitmap. // Saving bitmap with PixelFormat>pf8bit with biClrUsed>0 fails to save the color table // leading to a corrupt bitmap. type TBitmapColorTableBugFixer = class helper for TBitmap type TBitmapImageCracker = class(TBitmapImage); public function FixColorTable: boolean; end; function TBitmapColorTableBugFixer.FixColorTable: boolean; begin if (TBitmapImageCracker(FImage).FDIB.dsBmih.biBitCount > 8) and (TBitmapImageCracker(FImage).FDIB.dsBmih.biClrUsed <> 0) then begin TBitmapImageCracker(FImage).FDIB.dsBmih.biClrUsed := 0; Result := True; end else Result := False; end; The problem appears to be the same one reported here: Setting TBitmap.PixelFormat can lead to later image corruption or EReadError

CrossVCL 1.07 just released. New build contains bunch of fixes and improvements. Start building macOS and Linux VCL apps with Embarcadero Delphi and CrossVcl. We are working on Toolbar 2000 and TBX support. Work in progress still. Look at screenshots from macOS and Linux. And video - https://youtu.be/E34-3S05_IE History at: https://crossvcl.com/history.html More Info: https://crossvcl.com

Utf8Decode existed as an RTL function in older versions (I just checked Delphi 6: It's in system.pas, line 17659). Only in Unicode aware Delphi versions was it marked as deprecated. The gnugettext.Utf8Decode function has already been enclosed in {$ifdef unicode} ... {$endif} since it was introduced in 2012.

Don't forget to clear the Windows icon cache after you have made an icon change, to be sure that you are seeing what your users will see on first installing your application. Your search engine will find many ways to do this, some of them better than others...

Not sure, I don't use dbx all all, and I couldn't think of any recent operations of me to the IDE that might case the change of that file. I disabled the .bpl file as suggested by Thomas and the problem seems to have been solved. Thanks.

To be an answer to topic subject. I find https://forums.sqlteam.com to be a good SQL Server specific question forum.

System.Generics.Collections does not cause that much of a code bloat since the refactorings in XE7 - however it still causes more than it should but that is the limitation of the compiler. I did some tests with Rapid.Generics and while they are optimized for some scenarios it was not a stellar improvement over System.Generics.Collections in 10.3. And while I was doing benchmarks of those and Spring4D collections I saw that isolated benchmarks are often very much affected by certain CPU specifics - on different CPUs depending on their (non documented) behavior of the branch predictor and of course in a microbenchmark chances are high that all code fits into at least L2 cache.