Uwe Raabe

You can as well simply scroll the form as needed, but the need to scroll was exactly the complaint.

Indeed, but they still reside in the interface section and thus may need some units being used in the interface section instead of the implementation section.

Another option could be calling SetLocaleOverride with the desired value. It just has to be done quite early as long as no resources are being loaded.

You can add a registry entry under HKEY_CURRENT_USER\SOFTWARE\Embarcadero\Locales for that. Of course that only works at application start, so no change at runtime possible. One tool supporting changing languages at runtime is Korzh Localizer.

IMHO, having local procedures/functions using outer-scope local variables is often a hint for having a separate class for this functionality. I wish we were able to declare something like a local class type inside a method, just as we can declare a simple record type. In the moment I work around that limitation by nested classes unless I want it hidden from the interface, which forces me to make it a regular private class.

Scaling forms is always problematic. We can see this every day with applications (not only Delphi ones) when used in a mixed DPI environment. Although I don't actually suggest to use it, there is an option to switch the form designer using a special PPI. The drawback is that it is used for all forms and not only for the large ones. Naively thinking that scaling the form display could easily be done by drawing onto a bitmap and simply display that downscaled, but that would imply that the whole user interaction has to be made with a bitmap instead of real controls. The effort to implement that with all its edge cases is way more than one would expect.

One reason can be a missing {$R *.res} in the dpr file.

It must also be compiled with the same settings as the original unit. Hence my hint to the BuildRTL projects.

At least not short term.

Looks similar to this report: https://quality.embarcadero.com/browse/RSP-42714

This little utility always worked pretty well for me: RunAsDate

What are you trying to achieve with this?

The source\rtl folder contains projects to build the RTL for different platforms.

I cannot reproduce here with project and steps from the QP issue. Looks like it is caused by something in your system.

That is true for strings, but nor for dynamic arrays.

Seems someone already filed a report 8 years ago: https://quality.embarcadero.com/browse/RSP-13448

Edit the internal build configuration and add __BuilderGUI to Conditions.

Perhaps they aren't working with standard actions either?

The new QP doesn't support voting and I cannot see a benefit in sharing this.

I am happily taking that task for you. Can you just list the installed packages accountable for that number of standard actions? I'm not sure if I was able to identify all of them.

That is probably true, but it isn't wrong in the first place. As real-worlds tend to differ significantly between users, it would be tedious and most likely incomplete what Embarcadero can do about simulating these scenarios and test every and all IDE functionality with it. Usually these real-world problems show up in beta tests, where a bunch of developers test in their own environment, but obviously in this case they didn't. This can be caused by people with multiple libraries installed registering a lot of standard actions just not using standard actions. That is the point where QP reports from normal users come into play. Without anyone complaining about an issue via the official channel there is no trigger to analyze the problem and fix it. I suggest to file a QP report about the visual delay and a separate report about the search/filter box. The request for a busy indicator would be moot when the performance problem is be fixed, which I would favor over that indicator.

There are several QP entries about that. It has been fixed in Delphi 12. It is one of the driving issues for me for moving to D12.

I still suggest to file a QP report if it doesn't exist yet. Embarcadero will never see this delay as long as they only test with their standard actions. Without such a QP report nothing will change.

Is anyone aware of a QP entry for that?

You can find some hints in the release notes for 11.2: 11 Alexandria - Release 2