Uwe Raabe

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

Also there is a begin missing before the if.

I suggest reading some basics about Pascal/Delphi syntax.

33 minutes ago, Lainkes said:

But once you disable the panel, nothing can be changed.

Well, you have to enable all parent controls of the PageControl to let the user change tabs.

In most of the cases disabling a whole form is not what you actually need. Often it boils down to disable individual components unless you can group some with TPanel or TTabSheet. There is no common approach to that as it usually depends on your UI design - which we cannot see.

In that case you should use the Enabled property of each TabSheet.

51 minutes ago, jesu said:

There should be an option to do always a clean compilation.

Isn't that what Build is for (in contrast to Compile)?

AFAIK, these Internal Errors happens because the compiler doesn't clean up properly. I doubt that this can be fixed by just adding an option to do so. 

That error implies that the underlying field is not existing, probably because the dataset is not open. I would expect that the line 

DTP_STAT_HAND_GRIF_VOL_DOSSIER_OPVR_DATE.DataSource.Edit;

I added to the code would cause an error first, but perhaps you just missed to copy that line into your code.

Anyway, besides checking for Field <> nil, the question is: Why would you want to set that value when the dataset is not open?

It may be better to directly change the underlying data field instead of the control:

procedure Tfrm_Page_Control.DBCheckBox44Click(Sender: TObject);
begin
  DTP_STAT_HAND_GRIF_VOL_DOSSIER_OPVR_DATE.DataSource.Edit;
  if TDBCheckBox(sender).Checked then
    begin
      DTP_STAT_HAND_GRIF_VOL_DOSSIER_OPVR_DATE.Field.AsDateTime := Now;
      DTP_STAT_HAND_GRIF_VOL_DOSSIER_OPVR_DATE.Visible := True;
    end
  else
    begin
      DTP_STAT_HAND_GRIF_VOL_DOSSIER_OPVR_DATE.Field.Clear;
      DTP_STAT_HAND_GRIF_VOL_DOSSIER_OPVR_DATE.Visible := False;
    end;
end;

The error message is pretty clear: Set the ShowCheckBox property of the DateTimePicker to True. 

You don't even have to set the Date property to NULL. It should be sufficient to uncheck the Checkbox or set the Checked property to False. That will write a NULL value to the data field instead of 30/12/1899. 

8 hours ago, Ian Branch said:

It would be nice to have, say a checkbox, that made the Default used instead of Groups.

Good idea! I just created a feature request for that. Cannot promise when it will be implemented, though.

21 minutes ago, VilleK said:

I have multiple Delphi installs on this computer

I also have several Delphi versions on my system, but each if them has only one and an appropriate evaluator in that registry key.

14 minutes ago, Davide Angeli said:

For me no longer works the block selection mode: combination CTRL+O+C doesn't work properly. 

Please file a bug report.