Looks good.
Jennifer
On 9/26/2013 1:59 PM, Patrick Reinhart wrote:
Hi Jennifer,
See http://reinharts.dyndns.org/6870661/webrev.03/ for the changed
version:
1) the manual test will pass either on "print" or "cancel" (the test
description was changed accordingly
2) all tests and helper classes have been moved to "
test/java/awt/print/PrinterJob/CustomPrintService"
Cheers Patrick
On 09/26/2013 10:41 PM, Jennifer Godinez wrote:
Hi Patrick,
See inline comments.
On 9/26/13 12:20 PM, Patrick Reinhart wrote:
1) What would be the correct subdirectory for those Tests?
You can create a new directory like
test/java/awt/print/PrinterJob/CustomPrintService
2) The manual tests checks that the correct print dialog is shown.
Unfortunately I did not found a manual test for a non applet test.
In that case, you can just use an automated test.
Jennifer
Cheers Patrick
On 09/26/2013 07:19 PM, Jennifer Godinez wrote:
Hi Patrick,
Fix looks fine but can you send me a new webrev with the corrected
typo and move the regression tests to a new subdirectory? Also, the
manual test is reporting failure for "cancel" which I think should not
be the case. You may look at other manual tests on how they do this.
On the other hand, since you already have an automated test, you have
the option of not including the manual.
Jennifer
On 9/23/2013 1:15 PM, Patrick Reinhart wrote:
Hi Jennifer,
Did you had the time to look into it jet?
Cheers Patrick
Am 16.09.13 22:19, schrieb Patrick Reinhart:
Hi Phil,
Thanks for the quick response, seems I need some more practice in
English ;-)
Cheers Patrick
Am 16.09.13 18:59, schrieb Phil Race:
It looks OK to me although the test has typoes.
Marings => Margins
Appearence -> Appearance
Jennifer : can you review too - then test and commit - with typoes
fixed.
-phil.
On 9/15/2013 2:43 AM, Patrick Reinhart wrote:
Hi,
I need a sponsor and reviewer for my fix at
http://reinharts.dyndns.org/6870661/webrev.02
Problem description:
When setting a custom implemented PrintService on a PrinterJob
under Windows, a exception is thrown.
If the custom implementation extends a StreamPrintService,
everything works fine.
Fix description:
I changed the behaviour for the windows specific part being used
only for instances of Win32PrintService.
So all non Win32PrintService print services will behave as
non-native.
I also included a small regression test to prove my fix.
Thanks
Patrick
