Микола Петрівський

I am making assumptions based on what I have read in this topic.

Even if it was fixed, what next? Options dialog? About dialog? There are limits for customization in any program. There is a feature, meant to solve exactly your issue - UI elements being to small, but you do not want to use it. Instead you are trying to use a feature, that is not meant to solve such issues and even not officially supported. And it does not produce the result, you want. So who is guilty in such situation? RAD Studio developers? Really?

FontSize setting is not officially supported. So there will be some issues with it. Probably they have implemented it for some light tweaking for people, who need different font. And you are exceeding the limitations of their implementation.

One of the biggest features of Delphi 11 is HiDPI support. Once you set Windows to 125% scaling, IDE will use that as well. Fonts, icons, buttons - everything will be 25% bigger.

Looks like you need some Microsoft runtime, to make C++ formatting work.

And what next, button sizes? You definitely should try to set windows to 125% or 150% scaling and run it that way a few days. It will free you from the need to manually set fonts and icon sizes in each and every app, that you use.

Yep, with 125% scaling. Windows 7 with 125% scaling automatically enables so called "XP scaling". This means, that OS ignores app manifest, and forces it to scale itself. But RAD Studio manifest does not declare support for scaling, so Studio tries to do whatever it can, even while it does not support this. So you see such results.

Only in Windows 7/8 and older. Since Windows 8.1 you can set different scaling for different screens.

In modern Delphi you can do that like this: TMyRecord = record private FSrcPosition: TPoint; function GetDestination: TPoint; public property SrcPosition: TPoint write FSrcPosition; property DstPosition: TPoint read GetDestination; end;

Standalone web servers is not a common type of projects for Delphi. That is why default memory manager was not tweaked for such load. But full version of FastMM4 has lots of different tweaks specifically for multi-threading, so you can customize it as you wish.

If you only need to display HTML written by yourself, then THtmlViewer might be an option.

Your TСompressor.Create runs in current thread, so you can easily store it as CallerThread. Then, in decompression thread, you can synchronize to CallerThread instead of main GUI thread.

It is almost the same as Assert(value <> nil, 'Value is nil!'); Assert(str <> '', 'String is empty!'); Assert(Value.Num > 0, 'Value.Number <= 0!');

This is, probably, the simplest possible solution, if you limit yourself to "out of the box" solutions. By the way, TClientDataSet can be replaced with TFDMemTable.

I was expecting to see at least built in support for "--help" and "--version". As it is now, it is not much different to FindCmdLineSwitch.