Why is Creative Reporting Tools Printer Setup Dialog so slow under RDP?

questions
1

I have a multi-dll, legacy, Clarion 11 application where the Creating Reporting Tools report viewer opens the Printer Setup Dialog rather slowly when running in an RDP session.

My first thought was that it was calling PrinterDialogA with the report structure parameter instead of PrinterDialog that does not take a report structure. I replaced the CRT report viewer on one report with the extremely simple report viewer code from the Clarion 11 Help topic, “PREVIEW (set report output to metafiles)”. I added a printer setup button and an option to the preview window to indicate which variation of the printer setup dialog to use - PrinterDialog or PrinterDialogA – and what to pass as the second parameter to either of those procedures – nothing or 0,1, or 2.

The little test preview window can call anyone of the eight variations of the PrinterDialogX procedures without any kind of delay under RDP. What could CRT be doing that causes the printer setup dialog to open so slowly under RDP?

2

I haven’t used CRT in over 20 years, so I can’t help with that. But if there is a process where it’s deleting existing WMF temp files, maybe that could be the bottleneck.

3

Maybe @lodestar knows what’s up.

4

This is from within the preview?

Does the setting here make any difference?

image

5

Larry does a stack of property settings before calling PrinterDialog() which could be slowing things down but it’s been that way long before I took over the product.
CRT-PrinterDialogCall

6

No. Turning on the “Use ‘Setup’ style PRINTERDIALOG()” made no difference. That is the first thing I tried before I put in the print preview code from the online help and then added a way to try all eight variations of PRINTERDIALOG / PRINTERDIALOGA.

7

Larry, that is most helpful. I put those statements into my test program and while no one single property assignment takes too long, when they are all processed together it makes the printerdialog take about 10 seconds to open on my computer. I do not know how long it takes to open on customer’s computers.

I am not sure why those properties even need to be copied from the REPORT structure. It’s not like any of those were set by me at runtime nor could they be set at design time.

8

I’m reluctant to change the existing source since it’s been in use for so long but I’ll see if there’s anything I can do, such as an option, to skip these property calls.

I’d say the reason would be if any specifics were set prior to calling preview so that they wouldn’t be ignored.

This might take some time due to other demands at the moment but it’s on my list.

9

No problem, I understand. Besides, when I’m looking at speed issues of printing over RDP, the time to open the PrinterDialog is nothing compared to what it takes to get larger reports from the server down to the customer’s workstation when they have slower Internet connections at work than people have at home!

10

It’s not Larry that you’re replying to but Lee :slight_smile:

A few years back Larry Teames, owner of Creative PC Solutions - the
creator of Creative Reporting Tools, decided he wanted to prepare for
retirement and lots of fishing. To that end we collaborated about the
future of CRT (Creative Reporting Tools) and I adopted the report
centric products to continue their support and future enhancements.

If you’re wondering about how things have been handled… the last 3
years of tech support and all install builds for C7, C8 and, now, C9
have been handled by the new man behind the curtain, namely ME!

…and the ME referred to above is Lee White.
The quote comes from a Clarion Third-Party newsgroup post of August 2013

11

Curious if you coded that to 1st test if the Property needs change then how much time does that take? If none need changing is it still slow?

I would code it like this with the Property Compare and Set in one procedure:

  SetPrinterProp(PROPPRINT:frompage,-1)
  SetPrinterProp(PROPPRINT:topage,  -1)
  SetPrinterProp(PROPPRINT:device,  SrcReportName)
  SetPrinterProp(PROPPRINT:port,    SrcReportName)
  ...
  SetPrinterProp(PROPPRINT:collate, SrcReportName)
  SetPrinterProp(PROPPRINT:copies,  NbrOfCopies)

SetPrinterProp PROCEDURE(LONG PropPrint:Eqt, REPORT SrcReport)
    CODE
    SetPrinterProp(PropPrint:Eqt,SrcReport{PropPrint:Eqt})   !Call STRING version
  
SetPrinterProp PROCEDURE(LONG PropPrint:Eqt, STRING PropValue)
    CODE
    IF PRINTER{PropPrint:Eqt} <> PropValue THEN 
       PRINTER{PropPrint:Eqt} =  PropValue
    END

If this code was faster it seems likely to work the same as the current code setting the same values.

I did run into a slowness opening a Report when a Network Printer was used. I noticed it because it was being Opened to measure 1 String then closed. This was done 100’s to 1000’s of times. Changing to Open it Once made a big difference.

12

Carl,
I was thinking the same thing, property assignments sometime mean a lot more than just assigning one value to another. So, I tried code like the following and instead of taking 10 seconds it took 14 to 15 seconds to open the printer dialog:

IF PRINTER{PROPPRINT:FromPage}    <> pRpt{PROPPRINT:FromPage}    THEN PRINTER{PROPPRINT:FromPage}    = -1                          END
IF PRINTER{PROPPRINT:toPage}      <> pRpt{PROPPRINT:toPage}      THEN PRINTER{PROPPRINT:toPage}      = -1                          END
IF PRINTER{PROPPRINT:Device}      <> pRpt{PROPPRINT:Device}      THEN PRINTER{PROPPRINT:Device}      = pRpt{PROPPRINT:Device}      END
IF PRINTER{PROPPRINT:Port}        <> pRpt{PROPPRINT:Port}        THEN PRINTER{PROPPRINT:Port}        = pRpt{PROPPRINT:Port}        END 
IF PRINTER{PROPPRINT:PaperBin}	  <> pRpt{PROPPRINT:PaperBin}    THEN PRINTER{PROPPRINT:PaperBin}	 = pRpt{PROPPRINT:PaperBin}    END	        
IF PRINTER{PROPPRINT:Resolution}  <> pRpt{PROPPRINT:Resolution}  THEN PRINTER{PROPPRINT:Resolution}	 = pRpt{PROPPRINT:Resolution}  END				
IF PRINTER{PROPPRINT:Color}		  <> pRpt{PROPPRINT:Color}	   	 THEN PRINTER{PROPPRINT:Color}		 = pRpt{PROPPRINT:Color}	   END
IF PRINTER{PROPPRINT:Duplex}	  <> pRpt{PROPPRINT:Duplex}	     THEN PRINTER{PROPPRINT:Duplex}		 = pRpt{PROPPRINT:Duplex} 	   END	
IF PRINTER{PROPPRINT:YResolution} <> pRpt{PROPPRINT:YResolution} THEN PRINTER{PROPPRINT:YResolution} = pRpt{PROPPRINT:YResolution} END
IF PRINTER{PROPPRINT:FontMode}	  <> pRpt{PROPPRINT:FontMode}    THEN PRINTER{PROPPRINT:FontMode}	 = pRpt{PROPPRINT:FontMode}    END
IF PRINTER{PROPPRINT:Collate}	  <> pRpt{PROPPRINT:Collate}	 THEN PRINTER{PROPPRINT:Collate}	 = pRpt{PROPPRINT:Collate} 	   END ! pRpt is prop empty	
IF PRINTER{PROPPRINT:Copies}	  <> pRpt{PROPPRINT:Copies}	     THEN PRINTER{PROPPRINT:Copies}		 = pRpt{PROPPRINT:Copies} 	   END
13

When I posted about the lag in opening the PrinterDialog with a Remote Connection I should have mentioned that I was connecting to a production Azure Windows 2019 Datacenter server. I have since retested under a development Azure Windows 2016 Datacenter server and there is no delay in opening the PrinterDialog. On 2016 my connection properties are set to redirect printers, but only the pseudo printer drivers are redirected, like “Fax”, “Microsoft Print to PDF”, and “Microsoft XPS Document Writer”. On 2016 all of the properties in the Group Policy editor for printer redirection say “Not configured”. On 2019, I have not been able to get to the group policy editor.

1 Like