RFR: 8334509: Cancelling PageDialog does not return the same PageFormat object [v2]
Alexey Ivanov
aivanov at openjdk.org
Wed Jun 19 10:46:13 UTC 2024
On Wed, 19 Jun 2024 08:30:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:
>> On cancelling PageDialog, same PageFormat object should be returned which stopped working after [JDK-8307160](https://bugs.openjdk.org/browse/JDK-8307160).
>> Fix is made to reinstate "doIt" flag removed in JDK-8307160 so that correct value is returned from PageDialog.show action..
>> An automated printing testcase is created since the issue was caught by manual test and so having another manual test run the risk of not being executed during CI testing..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>
> Test fix
Changes requested by aivanov (Reviewer).
src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp line 694:
> 692: ::GlobalUnlock(setup.hDevMode);
> 693: }
> 694: doIt = JNI_TRUE;
Another option would be to return `JNI_TRUE` here and to return `JNI_FALSE` in the end of the function.
src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp line 697:
> 695: }
> 696:
> 697: AwtDialog::CheckUninstallModalHook();
I wonder why the block of code at lines 697–709 is not needed if `JNI_FALSE` is returned as a result of an error condition.
No, it is not directly connected to the bug you're fixing, yet it doesn't look right to me.
test/jdk/java/awt/print/PrinterJob/PageDialogCancelTest.java line 57:
> 55: robot.waitForIdle();
> 56: robot.delay(500);
> 57: });
These key presses are sent to whatever window has focus… before the Page Dialog is shown and after it's hidden. Is pressing `VK_ESCAPE` not enough? Pressing Esc is the same as clicking Cancel button.
test/jdk/java/awt/print/PrinterJob/PageDialogCancelTest.java line 60:
> 58: t1.start();
> 59: PageFormat newFormat = pj.pageDialog(oldFormat);
> 60: if (!newFormat.equals(oldFormat)) {
You should interrupt the `t1` thread after `pj.pageDialog` returns to stop robot from sending `keyPress` and `keyRelease` after the dialog is hidden. You can even use `Thread.sleep` instead of `Robot.delay` so that interrupting the thread throws `InterruptedException` and its handler just exits. (`Robot.delay` catches `InterruptedException` and then restores the interrupted flag.)
I wonder if any AWT event is sent when the Page Dialog is shown on the screen, an event is more reliable and key presses won't be sent to an arbitrary window in the system.
-------------
PR Review: https://git.openjdk.org/jdk/pull/19786#pullrequestreview-2127813477
PR Review Comment: https://git.openjdk.org/jdk/pull/19786#discussion_r1645895912
PR Review Comment: https://git.openjdk.org/jdk/pull/19786#discussion_r1645900131
PR Review Comment: https://git.openjdk.org/jdk/pull/19786#discussion_r1645886899
PR Review Comment: https://git.openjdk.org/jdk/pull/19786#discussion_r1645894197
More information about the client-libs-dev
mailing list