It is used inside the TAppliation.Idle to fire the (undocumented) TApplication.DoActionIdle method. When the value is zero or less, then each Idle call will result in an DoActionIdle call in turn calling TCustomForm.UpdateActions for any visible form.
In theory, the OnUpdate method for each action can even be called multiple times (because multiple controls on visible forms can point to it), but the real culprit is that TApplication.Idle as it can be called from these places:
TApplication.DoApplicationIdle
TApplication.HandleMessage (in a loop from TApplication.Run)
TCustomActionMenuBar.ProcessMenuLoop (in a loop)
TCustomRibbon.DisplayKeyTips (in a loop)
The last three (especially HandleMessage) can be disastrous as they can be called a lot (for instance when moving the mouse), and more often than not, the OnUpdate event handlers aren’t exactly CPU friendly.
A while ago I bumped into an application where the OnUpdate event handler for one action was called half a million time in under 5 minutes.
This clearly indicated a huge problem (besides using a full CPU core slowing down the application) as apparently something was broadcasting Windows Messages like crazy.
Investigating and Solving the message flood is on the back-log with a reasonably high priority, but the highest priority issue was fixing the high CPU usage in the first place.
Apparently more users suffer from this, as there is a Vcl.Forms.TApplication.ActionUpdateDelay property which TApplication.Idle uses to call the Windows API function SetTimer to rate-limit the TApplication.DoActionIdle call tree. Luckily SetTimer does have documentation on the unit of ActionUpdateDelay: it’s milliseconds.
I’ve set it to 10 as that updating the actions ~100 times a second is fast enough for this application.
If when setting up Continuous Integration (CI) with Delphi and you get errors like E2202"Required package 'rtl' not found" or F1027"Unit not found: 'System.pas'", then something is wrong with your library path on the CI server.
Before going into the details of why, the quick solution is to set either of these environment variables in your build script
put your resources in a text RC file that can be compiled through a resource compiler
add these to your Delphi project via the project manager, so it generated RcCompile elements which instructs the build process to run the resource compiler first:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
An elaborate wrapper around the Define column is jedi.inc which is used in many projects (both open source and closed source) to distinguish between various Delphi versions, libraries and platforms at compile time (URL: github.com/project-jedi/jedi/blob/master/jedi.inc)
The Project Options in the Delphi IDE has a few option (like the Search Path) each with an ellipsis button (the one on the right having only three dots ... in the image below) to pop-up a dialog.
Recently when printing the 3rd time and up, you get this error in many Delphi programs and the Delphi IDE:
Printer is not currently printing.
In the past this only occurred when you used a TPrinter and forgot to call BeginDoc.
But now it always occurs after reusing the same TPrinter instance for the 3rd time and up. Since the Delphi Galileo based IDEs (8 and higher; likely older ones as well: the source code printing hasn’t changed in a long time). The error actually occurs twice: after starting a source code print job, but also after cancelling the same failed source code print job.
The pattern there is using the Printer() function which has been the way the (un)official code examples have shown for ages (Delphi 2007 Printers.Printer Function [WayBack]; earlier examples like Delphi 7 [WayBack] usually in PDF files).
Like in the Delphi 7 “5-32 Developer’s Guide” page example:
procedure TForm1.Button1Click(Sender: TObject);
var
r: TRect;
i: Integer;
begin
with Printer do
begin
r := Rect(200,200,(Pagewidth - 200),(PageHeight - 200));
BeginDoc;
Canvas.Brush.Style := bsClear;
for i := 0 to Memo1.Lines.Count do
Canvas.TextOut(200,200 + (i * Canvas.TextHeight(Memo1.Lines.Strings[i])),
Memo1.Lines.Strings[i]);
Canvas.Brush.Color := clBlack;
Canvas.FrameRect(r);
EndDoc;
end;
end;
(Yes, that’s back in the D7 days when examples were still using with and not using try/finally statements for resource cleanup).
Actual cause and permanent fix
The printing problems are caused by various recent Windows updates part of MS16-098:
After you apply this security update and you print multiple documents in succession, the first two documents may print successfully. However, the third and subsequent documents may not print.
To resolve this issue, install update 3187022. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
3187022 Print functionality is broken after any of the MS16-098 security updates are installed
This article describes printing issues that occur after any of the security updates that are described in Microsoft Security Bulletin MS16-098 are installed in Windows. You can fix these issues by installing the update that is described in this article. Before you install this update, check out the Prerequisites section.
This update applies to the following operating systems:
Windows Server 2012 R2
Windows 8.1
Windows RT 8.1
Windows Server 2012
Windows Server 2008 R2 Service Pack 1 (SP1)
Windows 7 SP1
Windows Server 2008 Service Pack 2 (SP2)
Windows Vista SP2
No solution for Windows 10 yet…
Until you install the fix: workarounds
For your own code (Thanks Remy Lebau for your answer), add this code for your BeginDoc call:
MyPrinter.Copies := MyPrinter.Copies;
You might want to keep including this in your code as you’re never sure when the end-users apply which Windows update.
For the Delphi IDE either:
Press the “Setup…” button in the “Print Selection” dialog when printing source code, then “OK” in the “Print Setup” dialog:
Print Selection dialog
“Print Setup” dialog.
Uninstall the security updated marked in blue (Security Update for Microsoft Windows (KB3177725):
Delphi Component/Tool vendors have to support a truckload of Delphi and C++ Builder versions which can be a pain: they have to work around problems in Delphi and C++ Builder versions that have long been abandoned by Borland/CodeGear/Embarcadero/Idera/…
This means that sometimes the Delphi Component/Tool vendors have to work around stuff in a way normal applications vendors would never do.
Recently I learned that sometimes this can be a painful thing: keeping DFM files in binary state.
I’m not kidding about either the DFM file format nor about supporting old versions:
That’s why TeeChart still has most DFM files stored as binary files (again the ‘most’ word).
For version control and searching this is a pain, so normal application developers (the ones not using Delphi XE5 Update 1 for Android work) should run convert.exe with the -t (target=text) switch on DFM binary files.
A while ago, StackOverflow user Kobus Smit did some brilliant editorial work that – due to current state of StackOverflow – sort of fired backwards: his question got marked as duplicate before he could post his excellent answer. After that answer was posted, the oh-so pride SO-demi gods never took any energy to revisit to see which answers were best.
His simple question:
How can my Delphi app easily write to the Windows Event Log?What is the difference between TEventLogger and ReportEvent? How do I use the ReportEvent function?
Which somehow should be encompassed by this Delphi 5 question (apparently that 15+ year old Delphi version is still considered current by the SO demi-gods).
The answer summarises and extends existing answers spread out over StackOverflow and adds an EventLog git repository wrapping the ReportEventandRegisterEventSource (which somehow is always a pain: Delphi services for instance often forget that).
Lesson learned when doing editorial work:
prepare both the answer and question in markdown off-line
ensure you mention in the question that the answer is meant as collection of “best of” answers found elsewhere
post the question and answer in rapid succession
cross your fingers for the StackOverflow demi-gods being in a good mood
Recently I bumped into a thing that I’d long forgotten: the Delphi compiler treats searching for include files (any files used with the {$I} or {$include} directive differently:
The compiler first searches the directory where the file that is including resides and then uses the project and IDE search paths.
The IDE only uses the project and IDE search paths.
This means that when you press Ctrl-Enter on the filename to be included you might edit a different file than the compiler will include.
So when a product has multiple include files with the same name in different sub-directories, then you must modify them all.
I’m not sure this is a bug or feature, so Embarcadero is free to put this in either their QA system or documentation system.
The Wiert Corner - irregular stream of stuff 
