A-Shell Network Post New Topic  Post A Reply
my profile | directory login | search | faq | forum home

  next oldest topic   next newest topic
» A-Shell Network » Printing - Windows » COPIES not honored when using PROMPT:

 - UBBFriend: Email this page to someone!    
Author Topic: COPIES not honored when using PROMPT:
John A
Senior Developer
Member # 1429

Icon 1 posted      Profile for John A     Send New Private Message       Edit/Delete Post   Reply With Quote 
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 <TELNET:4627> 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:
code:
DEVICE=AUXLOC:clrtic

ATE PQI file (clrtic.pqi):
code:
DEVICE = PROMPT:  ;(or printer name)
PASSTHROUGH = ON
FORMFEED = OFF
DATATYPE = RAW

ATE Version: 6.4.1555.1
A-Shell Version: 6.4.1554.1
xcall SPOOL switches: 0x100006

Thanks,
John Andreasen

From: Arkansas | Registered: Aug 2016  |  IP: Logged | Report this post to a Moderator
Jack McGregor
Administrator
Member # 1

Icon 1 posted      Profile for Jack McGregor     Send New Private Message       Edit/Delete Post   Reply With Quote 
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 <Prompt>, 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.
From: Woodland Hills, CA | Registered: Jun 2001  |  IP: Logged | Report this post to a Moderator
Jack McGregor
Administrator
Member # 1

Icon 1 posted      Profile for Jack McGregor     Send New Private Message       Edit/Delete Post   Reply With Quote 
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

From: Woodland Hills, CA | Registered: Jun 2001  |  IP: Logged | Report this post to a Moderator
Jack McGregor
Administrator
Member # 1

Icon 1 posted      Profile for Jack McGregor     Send New Private Message       Edit/Delete Post   Reply With Quote 
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.

From: Woodland Hills, CA | Registered: Jun 2001  |  IP: Logged | Report this post to a Moderator
John A
Senior Developer
Member # 1429

Icon 1 posted      Profile for John A     Send New Private Message       Edit/Delete Post   Reply With Quote 
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.) [Smile]

John Andreasen

From: Arkansas | Registered: Aug 2016  |  IP: Logged | Report this post to a Moderator
   

Quick Reply
Message:

HTML is not enabled.
UBB Code™ is enabled.

Instant Graemlins
   


Post New Topic  Post A Reply Close Topic   Feature Topic   Move Topic   Delete Topic next oldest topic   next newest topic
 - Printer-friendly view of this topic
Hop To:


Contact Us | Visit our main website at www.microsabio.com

Powered by UBB.classic™ 6.7.3