Uwe Raabe

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

Try Ctrl-Shift-K-T

It made use of canusbdrv.dll and a Delphi wrapper (see attachment). This was sometimes around 2008, so most likely that interface may have changed since then. uCanUsbDll.pas

It just looks like the easiest to implement, but most of the time it turns out to be the hardest to get it done right. Another approach is to wrap the code into some TThread.ForceQueue construct. F.i. a loop calling Applicaton.ProcessMessages can be refactored like this: procedure DoAllTheThings; begin DoSomething; while DoWeNeedToWait do Application.ProcessMessages; DoWhatEverIsNecessary; end; Refactored: procedure DoAllTheThings; begin DoSomething; DoTheRest; end; procedure DoTheRest; begin if DoWeNeedToWait then TThread.ForceQueue(nil, DoTheRest) else DoWhatEverIsNecessary; end; All the code is still executed in the main thread, but there is no loop blocking anything.

That is just like Application.ProcessMessages works: It processes the messages in the queue. If one of those messages calls Application.ProcessMessages in a loop, the outer Application.ProcessMessages will only get control back when that inner loop ends and the event call returns. IMHO, you can safely remove the frivolous in your last statement.

Although it is not written explicitly in the docs I assume the Logical operators are used as if they were Bitwise operators when the condition above is not met and no corresponding Bitwise operators are declared. Nevertheless could you achieve the same using Bitwise operators in the first place.

The first patch for the just released RAD Studio 12.1 Athens is available: RAD Studio 12.1 Athens Patch 1 Available