Uwe Raabe

3 hours ago, thomedy said:

I CANNOT get the version info to include into the exe

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

34 minutes ago, sp0987 said:

If it's really about the interface section

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

23 minutes ago, Rafal.B said:

there is no reason to expect any improvement?

At least not short term.

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

15 minutes ago, sp0987 said:

to use our DateTime (not the real OS DateTime) for testing purposes without the need to change the machine's OS time.

This little utility always worked pretty well for me: RunAsDate

19 minutes ago, sp0987 said:

We need to modify all sysutils date time functions

What are you trying to achieve with this?

16 hours ago, Anders Melander said:

I'm guessing the compiler options used to compile your sysutils copy might also have importance. Maybe someone else knows that.

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.

37 minutes ago, RayTmsk said:

Reference at first assign and hard copy while changing.

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.

25 minutes ago, ULIK said:

This makes me wonder why none of that vendors have already reported this to Embarcadero.

Perhaps they aren't working with standard actions either?

6 minutes ago, PeterPanettone said:

Please VOTE & SHARE.

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

3 minutes ago, John R. said:

Embarcadero employees and/or Delphi enthusiasts are free to use that video, should they care to file a report.

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.

9 minutes ago, PeterPanettone said:

This shows that the Embarcadero team does not conduct real-world tests. It seems they do their tests with empty environments.

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.

5 minutes ago, tgbs said:

We have a problem when double-clicking on the TActionlist. There are only a few actions, but the image list (TVirtualImageList) is large

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

45 minutes ago, fastbike said:

Do you remember what was required ?

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

26 minutes ago, ErikT said:

Often, the only feasible way around using an Application.ProcessMessages call is to use multiple threads.

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

Quote

• For a logical operator and a bitwise operator using the same symbol, the logical operator is used only when the operands are booleans. Since the type of record for this record operator is not a boolean, a logical operator will only be used when the other operand is a boolean.

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