So, let me double check:
1. if I apply your current fix and Alt-Tab out of the print dialog, I'll
get to some other app running on my desktop.
2. When I Alt-Tab back to Java, I'll get to the open print dialog.
3. The Java Frame cannot be activated by any means while the print
dialog is displaying.
Are all the above points true?
--
best regards,
Anthony
On 1/23/2013 18:09, 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.
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.
