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.
Because the IDE uses this on-line content, potentially any code could be executed inside the IDE (apart from that page being loaded over http, so any man-in-the-middle could abuse this, but I digress). This imposes a security risk as many developers run the IDE from accounts having more rights than the average user.
I think the reason forward declaration of classes and interfaces is possible because they both are reference types, so referring does not impose copying.
Anyway, the trick is this:
You can’t have forward declarations for record types. Define both Implicit operators in the second type
The reason is that when using Delphi, the TOpenDialog and TSaveDialog will use the classic Open and Save Dialogs on Windows < Vista and fall-forward to the new Common Item Dialogs handled by TFileOpenDialog and TFileSaveDialog (both will not fall backward).
When you have your COM initialisation done wrong, your application appears to hang. Amidst the plethora of threads started by the COM subsystem, these two dead-lock:
The Wiert Corner - irregular stream of stuff 