Hi Phil,
I implemented your suggested changes in the class WPrinterJob now. I
also created a simple test for showing a print dialog after register the
custom PrintService on the PrintServiceLookup class and setting it to
the PrinterJob using setPrintService().
http://reinharts.dyndns.org/6870661/webrev.01/
According to the manual test. I did found different implementations
where sometimes the instructions where just printed to the console and
others where a applet was used. Could you point me out a existing test
where it is done the way you want it to be?
Cheers
Patrick
On 06/18/2013 11:35 PM, Phil Race wrote:
Yes, the driverDoes* fields should be reset, even though
I am not sure we need them any more because I think
that ever since XP drivers always do their own collation.
But some of this code was written when win9x/win nt was supported.
@run main/manual=yesno
Can be used to write a manual test for dialogs.
The test then generally has to have a window with instructions in it,
and the tester has to tell the harness if it passed based on
understanding
and following the instructions.
-phil.
On 6/18/2013 2:04 PM, Patrick Reinhart wrote:
Hi Phil,
I will do the suggested changes and check the dialog and enhance my
test accordingly.
Do you think that the fields driverDoesMultipleCopies and
driverDoesCollation should be reset on setPrintService() as follows,
because the actual native settings will be obsolete in that case anyway?
@@ -587,11 +586,11 @@
public void setPrintService(PrintService service)
throws PrinterException {
super.setPrintService(service);
- if (service instanceof StreamPrintService) {
+ driverDoesMultipleCopies = false;
+ driverDoesCollation = false;
+ if (!(service instanceof Win32PrintService)) {
return;
}
- driverDoesMultipleCopies = false;
- driverDoesCollation = false;
setNativePrintService(service.getName());
}
At last could you give me a hint, how you do a test for dialogs with
Jtreg?
Cheers
Patrick
Am 17.06.13 23:51, schrieb Phil Race:
The superclass does check that the service will (claims to) support
printable/pageable.
I've looked at what we did in the implementation when it comes to
print which
is that for such a custom service we implicitly head it off to the
javax.print API
so it probably could work.
But the dialog code probably does need to be tweaked to always invoke
the cross-platform dialog in this case. Right now its bailing from
native
only if it sees a StreamPrintService.
So line 560 and maybe line 590 should be
if (!(service instanceof Win32PrintService)) ...
pageDialog() needs similar treatment.
Try those and see if you get sensible behaviour when showing the
dialog.
-phil.
