PrintDialog not closable on x64 systems

rbuser

Hi,

we have got a problem with the print dialog.

Our 32 bit application allows the user to call the default ReportBuilder
print dialog in order to the select the printer.

The following code is used:

ppViewer.Report.ShowPrintDialog := True;
ppViewer.Print;

On 32 bit Windows system the print dialog works OK.

However if the same application .EXE file is used on 64 bit Windows
systems there is a problem:

When the user clicks the "Properties" button next to the printer
selection combo box, the properties window of the selected printer shows
up. After the user leaves this properties window, the print dialog
becomes unclosable.
Neither the OK button, nor the Cancel button, nor the close button in
the upper right corner of the window work anymore. The other controls
still work, but the dialog will not close and the only way to exit the
application is to kill the process.

Best Regards,

David Bakker
AdvanTex Software GmbH & Co. KG

nicocizik

Hi David,

This is not a known issue nor am I able to recreate it with a simple
test on my 64 bit machine.

Which version of ReportBuilder and Delphi are you using? Does this
occur with every printer you select the Properties option with?

Are you able to recreate this with a minimal example using only RB and
Delphi components? If so, please send this example to
support@digital-metaphors.com in .zip format and I'll take a look at it
for you.

rbuser

Hi Nico,

thanks for your answer.

Unfortunately I cannot reproduce the error. In a test application
everything works OK.

When debugging our real application, it gets stuck in the unit
ppPrintr.pas at the line
"function ppDocumentProperties; external winspl name"

This function call doesn't seem to be finished when the printer
properties window is closed. The execution of the procedure
TppCustomPrinter.ShowPropertiesDialog
does not continue.

We are using Delphi® XE Version 15.0.3953.35171 with ReportBuilder
14.04. It occurs with every printer.


Best regards,

nicocizik

Hi David,

Unfortunately unless we are able to recreate this problem here on our
machines, there is little chance we will be able to track it down.

My suggestion would be to try to simplify your application's print
process as much as possible. Comment out all print related code
including event handlers that fire during printing. If the print dialog
functions correctly when you do this, periodically begin adding the
features/code back to isolate the problem.

rbuser

Hi Nico,

I just did some more investigation on this topic for David. We still cannot
reproduce this with a small demo application, but we found out that the
print dialog is closable again after changing the following line on
TppCustomPrinter.ShowPropertiesDialog:

Result := (ppDocumentProperties(lForm.Handle, PrinterHandle,
PrinterInfo.Device, lPDevMode, lPDevMode, DM_IN_BUFFER or DM_IN_PROMPT or
DM_OUT_BUFFER) = IDOK);

was changed to

Result := (ppDocumentProperties(0, PrinterHandle, PrinterInfo.Device,
lPDevMode, lPDevMode, DM_IN_BUFFER or DM_IN_PROMPT or DM_OUT_BUFFER) =
IDOK);

So the only thing we changed is leaving out the handle of the active form
(your printer dialog). Of course this cannot be the solution, but I just
wanted to let you know, perhaps you have heard anything like this before?

Best Regards,

Christian Schröder

nicocizik

Hi Christian,

Unfortunately we have not heard of anything like this before.

The DocumentProperties routine is part of the Windows API and is
functioning correctly as far as we can tell. The issue is likely
elsewhere in the application. I would suggest running your application
through a memory manager to see if there are any memory leaks or bad
object references. The fact that this does not occur with a simple
example leads me to believe there is some code being used in your main
application (by your or ReportBuilder) causing the problem. The goal is
to find this code.

I still must insist that you try simplifying your main application to a
point that it is working, then try adding features/code/report
components back so you can isolate the problem.