Hi,

When printing through the ATE client, I am noticing that if using PROMPT: in the ATE config file, the copies value specified to xcall SPOOL appears to be ignored. When the ATE PQI file DEVICE line is set to spool to the printer directly, it works as expected. I see the system trace Generating 2 copies manually = 26708484 when printing direct to the printer, but not when using PROMPT:. I know that one could force the desired behavior by setting PRTCOPIES=ON, but was wondering if you would consider (or even could) update the value in the copies field of the Windows printer selection dialog, or at least cause the dialog to be displayed for each copy?

Server-side PQI file:
ATE PQI file (clrtic.pqi):
ATE Version: 6.4.1555.1
A-Shell Version: 6.4.1554.1
xcall SPOOL switches: 0x100006

Thanks,
John Andreasen

That seems like a bug. Interestingly, if you change your server-side PQI to just contain DEVICE=AUX: and rely on the Settings > Connection Properties Printer tab to be set to , then the requested # of copies does in fact show up in the printer selection dialog. But it seems that the copies information is getting cleared in the process of loading the client-side PQI file.

That explanation wasn't quite right. It was more related to which printer driver resources had been accessed previously, and that depended on a number of factors (printer init options, APEX, etc.) The problem seems to be purely client-side, but is not limited to ATE either - you could duplicate the same problem under local A-Shell/Windows. It also happened, for a slightly different reason, if the specified printer wasn't found.

I've posted a ash-6.4.1555.4-w32-upd.zip which I think fixes it.
Notes: ash64notes.txt

One more point, which may not be that useful but is possibly interesting and certainly relevant nonetheless:

If you add PRTCOPIES = ON to the server-side PQI file, it will generate the copies in the process of sending the file to the client via the AUXLOC: protocol. In other words, with /COPIES:2 it will actually send two copies of the file the client. In that case, even though the client may think it is printing one copy, the result on the printer would be two copies.

That would probably only be useful in a printing situation where:

1) the application feels it is essential that multiple copies get printed,

2) the user isn't going to get any dialogs in which the copies value could be changed, and

3) there is some doubt about whether the printer driver and/or client is capable of generating copies properly.

Very interesting. Sorry for the delayed response. The above version definitely seems to produce the desired behavior. Perhaps PRTCOPIES=ON is worth considering, but I guess we'll see if there any issues without it first.

Thanks and have a great weekend (what is left of it.)

John Andreasen