Leaderboard

This is really excellent. It works a treat in XE7. Thank you. I have one very minor suggestion. I wonder if it would be prudent to add a namespace to all your unit names to avoid potential clashes. For instance, one of your units is named Main and I bet there are other packages around that use that name. With a namespace prefix you sidestep any such pitfalls.

For me it is not money. I have later versions than XE7. For me there is no benefit to updating. Nothing released since XE7 has any significant benefit for me. For sure there are some minor things but nothing that really makes it worth the effort. And it is an effort for me because I have a whole bunch of patches that I apply to the RTL to address design flaws primarily in its handling of floating point. That requires bespoke code for each version and I don't currently think it is worth it. Plus I'd have to spend some time working with multiple versions because I need to maintain recent releases of our software. Now, if Emba did something about the very poor performance of the compiler code that dcc64 emits, I would upgrade without hesitation.

It's usually simply money. Delphi updates nowadays cost an arm and a leg and on top of that you also need to upgrade the 3rd party tools and components. (I just bought 3 TeeChart licenses and accounting was having a fit. 😉 ) Others don't want to go through the trouble of updating because they can't see the advantage. And of course, it takes time and there is a certain amount of laziness involved. In my (the company I work for) case it's a mix of all the above. We are now in the process of upgrading to Delphi 10.2 + latest update (the last version that didn't annoy the hell out of me) after staying with Delphi 2007 for a long time due to the Unicode change. And I hope that one of the 10.4 upgrades will fix all those annoying bugs so maybe we will even upgrade to that version. That process proves painful as we still need to keep compatibility to Delphi 2007 with our internal libraries because we will probably never finish upgrading all those internally used tools. There are just too many of them. Oh, and then there are those who - for years - have been phasing out Delphi (because it's so 1990ies and nobody uses it nowadays) and porting their software to a different development platform, so they keep the old Delphi version around to maintain the programs that work until (in some far far way future 😉 ) the new software is actually ready.

In addition to constraining the window's size, you should consider giving the user visual feedback for their attempts to resize. Do this by handling the WM_NCHITTEST message: https://docs.microsoft.com/en-gb/windows/win32/inputdev/wm-nchittest type TForm1 = class(TForm) protected procedure WMNCHitTest(var Message: TWMNCHitTest); message WM_NCHITTEST; end; .... procedure TForm1.WMNCHitTest(var Message: TWMNCHitTest); begin inherited; case Message.Result of HTLEFT,HTRIGHT: Message.Result := HTCAPTION; HTTOPLEFT,HTTOPRIGHT: Message.Result := HTTOP; HTBOTTOMLEFT,HTBOTTOMRIGHT: Message.Result := HTBOTTOM; end; end;

There is also an OnConstrainedResize event.

I never tested it, but if you open the System.StartUpCopy.pas you will see that in Windows, always when your program run, it will try to copy files from ExtractFilePath(ParamStr(0)) + '\StartUp\' to TPath.GetHomePath (in windows it is AppData\Roaming\). So, you can try to put in Deployment remote path: .\StartUp\yourapp\database.sqlite3 And to load the database in runtime you can try to use TPath.GetHomePath + '\yourapp\database.sqlite3'

Delphi equivalent: if JStringToString(intent.getComponent.getClassName).EndsWith('.Queue') then

Print TCriticalSection.InstanceSize and you know if it was fixed or not - spoiler: no, it was not. On Windows that is - on Posix TCriticalSection simply uses System.TMonitor which allocates at least the size of a cache line