Leaderboard

Cloud is just someone else's computer and those fail, too.

There's always delphibasics.co.uk and of course there is the offline help in chm format. Still, I would be really embarrassed if that was my company. In particular I would try my best to communicate to my customers that I am working on the issue as hard as possible.

Which opens a new can of worms...

So it's working as expected?

As you likely noticed, Delphi 11 officially does not support Windows XP anymore. You can make your application compatible with XP again by simple set. In Project Options|Building|Delphi Compiler|Linking set "Set OS Version fields in PE Headers" and "Set SubSystem Version fields in PE Headers" to "5.1". Unless your application uses System.Threading.pas (TTask etc) you should run it under Windows XP with no problems. But if so, then you have to tweak this unit. Threading objects actually use in their internals new TThread.GetTickCount64 method, which is hardwired to Windows API GetTickCount64 which is not available in Windows XP API. Take this unit from "source\rtl\common" folder in Delphi 11 installation. Declare new local function in the beginning of implementation section of this unit like this: function _GetTickCount64: UInt64; begin if TOSVersion.Major<6 then Result := TThread.GetTickCount else Result := TThread.GetTickCount64; end; and replace all occurrences of TThread.GetTickCount64 calls with _GetTickCount64. For Win32 applications then copy this modified unit to \lib\win32\debug and \lib\win32\release folders in Delphi 11 installation and rename original System.Threading.dcu to e.g. _System.Threading.dcu. Then build your project which uses System.Threading with Debug and Release configuration. New System.Threading.dcu should be created in mentioned folders. After this you should remove modified System.Threading.pas from these folders to prevent its recurrent compilation. Now your Delphi 11 Win32 applications should run under Windows XP with no External Exception crash.

My main TUrlHandler.Execute functions start with: if (Client.AuthUserName <> '') then begin to check for authentication, but the server does the main authentication in the onCheckPassword event which returns false for failure, but does not clear AuthUserName. So there may be a bug for POST. Sorry, don't have time to test it this week. Angus

I can assure they do know.

Imagine not being able to get your company's website up and running again after more than a week? What an absolute joke. I guess I'll go and find my old Delphi 6 printed language guide to look up the info I can't find online rn.

I may be wrong, but I think the underlying reason is: Font.Size and Font.PixelsPerInch do not respect per-monitor scaling This has been discussed a lot and font scaling is now re-evaluated. I proposed some changes for the VCL that can even be rolled out as a hotfix (i.e. no interface breaking changes), although not really a perfect solution, which requires TFont.PixelsPerInch moved to published. These changes do work, at least for the test cases we currently have. Unfortunately it cannot be used when compiled with packages. The easiest workaround for the moment is to use ParentFont = True as much as possible. TForm.Font is currently handled quite well and that can be adopted with this setting. Of course one loses some design variance.

https://community.idera.com/developer-tools/b/blog/posts/august-2019-delphi-android-beta-plans-august-roadmap-update It was planned for mid-2020. But it is late.

Don't tell me - but this the almighty excuse brought up by the decision makers almost every time some issue like this is brought up - "but what about existing code" - like for that dreaded "directly passing result of ctor call to interface parameter issue" - what about existing code? Well existing code is most likely suffering from a defect. The stupidity of the Delphi compiler in almost every aspect and the unwillingness to change anything significant on that is making me furious!