In that case, I'm fine with your fix. Thanks for the clarifications.

--
best regards,
Anthony

On 1/23/2013 18:24, Petr Pchelko wrote:
Sorry, my message came out of order.

Anthony wrote:
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.
1. Yes.
2. Yes.
3. The print-dialog is natively application-modal, so I think there is no way 
to activate any Java Frame.

With best regards. Petr.

On Jan 23, 2013, at 6:12 PM, Anthony Petrov wrote:

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.

Reply via email to