On 1/23/2013 6:09 PM, Petr Pchelko wrote:
Hello, Anthony, Artem.
I have verified that the printing dialog is created via [NSPrintPanel
runModalWithPageInfo:info] and page dialog is created via [NSPageLayout
runModalWithPrintInfo:info].
The documentation states that both methods display the dialogs
application-modally, so I suppose there is no way to bring other Java windows
on top of them.
OK, in this case the fix will help somtimes and will do no harm in other
cases :) Approved.
Thanks,
Artem
With best regards. Petr.
On Jan 23, 2013, at 5:14 PM, Anthony Petrov wrote:
Hi Petr,
The checkBlocking() should actually bring the blocker window to top. In your
case the blocker is the native print dialog. I'd suggest to look at how the
dialog is created in the printing code in JDK, and make sure they show the
dialog modally (using the native modality support on OS X). In this case the OS
will not allow one to Alt-Tab out of the print dialog to another window of the
same app until the dialog is closed.
Alternatively, if using the native modality is not an option, then we have to
somehow get a reference to the native NSWindow/NSPanel instance associated with
the native print dialog, and bring it to top in the checkBlocking() method.
--
best regards,
Anthony
On 1/23/2013 11:50, Petr Pchelko wrote:
Hello, AWT Team.
Please review the fix for the issue:
http://bugs.sun.com/view_bug.do?bug_id=8005997
The fix is available at:
http://cr.openjdk.java.net/~pchelko/8005997/webrev.00/
This is a very simple fix, we just should not show the blocker if it is a
PrintingDialog. The dialog will be shown by the native system.
With best regards. Petr.
