Leaderboard

Always call inherited in destructor. I would also add always call inherited in constructor, but if you miss to call constructor that does something, you will know soon enough. If you don't call destructor, you may have leaks which can be much harder to detect later on. This is extremely low level optimization and it makes sense only in some code that will be called a lot, but even then think four times before you write it as changes in class declaration - using different ancestor can break such code badly. I have this kind of optimization in 3 places in my code in my smart pointer, weak and lazy reference implementations. Inherited is there, it is just commented out and there is additional comment explaining why it is there. If anything breaks in TObject, I have only one file to change. But even now, while I am writing this I feel extremely uneasy about that code. So don't do write such code, unless you really have good reason, and don't write it even then.

Form 652. That's a pretty extended hello world collection!

New branch: https://github.com/fschetterer/DDevExtensions/tree/RemoveDMPixelsPerInch Makes it easier to share code with older versions of Delphi. Although it works fine here it could use some testing before I add a pull request.

There are posted workarounds: https://quality.embarcadero.com/browse/RSP-35365

Hello World, I just had a pleasant surprise - when I build a certain x64 project of mine, the executable is noticeably smaller under Delphi 11 Alexandria (6.5 MB) than under Delphi 10.4.2 Sydney (7.3 MB). Embarcadero must have done some serious optimizations. (Edit) the project is compiled with {$WEAKLINKRTTI ON}.

Not really. It is the most lightweight list class that can be used there as dynamic arrays don't have capacity which prevents excessive memory reallocations when growing array. Question is, whether the whole algorithm could be implemented in a different way, but that is another story (I am not saying that it can be better as I haven't done any analysis)

Having a fast SSD doesn't hurt, nor does it hurt to have source and output on different drives, but I wish I could get a CPU that had a core that could be clocked really high, since the compilers mostly are single core intensive.

Hi delphi fans, I'm never sure how much attention is paid to the 'upvotes' on issues in quality portal... Anyways, as there has been considerable effort in getting LSP working and improving that by the Emb team, one feature I'd really like to see the IDE provide is a 'rad' experience from the code editor with auto completion of anonymous method signatures, etc. https://quality.embarcadero.com/browse/RSP-27293 and https://quality.embarcadero.com/browse/RSP-24310 to summarize, as an example: type TMyfunction = reference to procedure (const AArg:string); begin var func : TMyfunction := /* press ctrl+space which completes the following: */ procedure (const AArg:string) begin end; end; There can be many different ways in which the context of the type can be known based on the cursor position when ctrl+space is pressed... If you have some time and think it would also be valuable, please upvote... I don't know if the moderators should consider a separate forum section for these types of requests. regards, Conrad

I can imagine the bug reports when some day TObject.Destroy actually gets some code and no one will remembers this oversight.

Is there anyone using any Delphi version in its initial release state? (🤡Nice try, but even D7 is widely used with at least one update...)

Yes. And I've reported this issue some weeks ago as RSP-35049. The black text is caused by a bug in Vcl.Menus.pas; procedure DoThemedDrawText(): The parameter "Selected" is completely ignored in that code, but should be used to select to correct theme element details. Feel free to vote for it 😉. But even if this will be (hopefully) fixed in some Delphi 11.1 update I'm still looking for a workaround without using a full copy of Vcl.Menus.pas. Something like patching Vcl.Menus at runtime (using Delphi Detours? Or code from Andreas Hausladen's VCLFixPack?) to replace DoThemedDrawText() with a fixed version (see RSP-35049 for the required changes). Any help appreciated.

At the moment I've resolved in this way the bad painting of DbGrid: procedure TForm1.DbGridDrawColumnCell(Sender: TObject; const Rect: TRect; DataCol: Integer; Column: TColumn; State: TGridDrawState); var LDbGrid: TDbGrid; begin LDbGrid := Sender as TDbGrid; //Resolve bad painting of selected cell in Windows 11 if not StyleServices.Enabled or (StyleServices.IsSystemStyle) then begin if ((gdSelected in State) and (gdFocused in State)) or ((gdSelected in State) and (dgRowSelect in LDbGrid.Options) and LDbGrid.Focused) then LDbGrid.Canvas.Brush.Color := clHighlight; LDbGrid.DefaultDrawColumnCell(Rect, DataCol, Column, State); end; end;

Most likely this: https://quality.embarcadero.com/browse/RSP-30870

I am very happy about noticeable changes in the compiler. It means they really still care. It's just not my main concern to save one or two megabytes here or there. But I do understand folks that really need it, hence the "broader audience" part in my post... some really need small executables. There is a whole Non-VCL movement out there, that denies themselves the VCL for reasons of exe sizes (among other reasons, I am sure). But, they might not profit from these changes...

But you would be in "Delphi Heaven", not "DLL Hell".

16 colors ought to be enough for anybody? 🙂

x86 PyScripter Delphi 10.4: 11,975 KB PyScripter Delphi 11: 10,326 K 14% reduction!!

Same here. PyScripter Delphi 10.4: 17,302 KB PyScripter Delphi 11: 15,523 KB 10% reduction, not bad. Any idea where this is coming from (generics?) Probably the first Delphi version that produces smaller executables that its predecessor.