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

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.

We had similar problem, except, that we wanted to know, when app finishes processing any long task, and is ready to accept new input. And we wasn't allowed to change the code of the app. Our first attempt was to use SetWindowsHookEx in WH_FOREGROUNDIDLE mode. That was working in most cases, but sometimes we had situations, when the last message in the message queue is actually the one, that causes processing of long task, so our hook was triggering at the beginning of the processing, not the end. Also, this hook will hang until some message will get in to message queue, so some sort of wake up message is required. Finally we decided, that since target app uses runtime packages, we can call VCL for help. Now our test app is using windows hooks only to inject our code (dll compiled with runtime packages) in to target process. Then we create event handler for Application.OnIdle. This approach is much more reliable, something like 95%. If you can change the code of target app, then it will the best approach. P.S. You could avoid all of that, if VCL supported UI Automation

Try to toggle compiler cache on and off: http://docwiki.embarcadero.com/RADStudio/Rio/en/Compiling_and_Running

You of course know, that you can break some cycles by moving parts of uses to implementation section, right?

Try to install Xcode on your Mac. I think, reading the log will be much easier: http://docwiki.embarcadero.com/RADStudio/Rio/en/New_features_and_customer_reported_issues_fixed_in_RAD_Studio_10.3.2

Looks like I can download fresh ISO from torrent, but I need hash sum to be sure, that it is correct file. Can someone post your sum here? MD5 will be enough.

What API are you using? As far, as I know, Acrylic Blur is not documented for classic Win32 apps. And using undocumented API is not a good idea.

You will need to manually call TBindings.Notify because your controls are not observable: http://docwiki.embarcadero.com/RADStudio/Rio/en/Tutorial:_Creating_LiveBindings-Enabled_Components As to why even manual call does not work, it is hard to tell without compilable demo.

Maybe, you should try Bind(srcViewModel.Container,'DataSource',dstDBGrid,'DataSource') ? But in general, this looks suspicious to me. Usually LiveBindings are used to replace data-aware controls, and you are trying to mix them. What do you want to achieve?

Just create global atom and pass it's code to the caller. Or caller can create empty atom, and then check for changes.

ADB over USB has never worked for me in VirtualBox VMs. That is why I always use ADB over WiFi: https://developer.android.com/studio/command-line/adb#wireless