I've noticed that too. I didn't point this out though, because you're
also checking the MODAL_EXCLUDED flag in your modallyBlocked(), so I
thought it was OK. But if you can pull this check to the Java code
before even calling modallyBLocked(), then I guess the "setEnabled" name
would make more sense.
--
best regards,
Anthony
On 4/27/2012 10:02 PM, Leonid Romanov wrote:
I've looked at 7124395 and the fixes you did for FX and it looks like we need setEnabled method for AWTWindow. I'll redo my fix accordingly.
On 27.04.2012, at 21:39, Anthony Petrov wrote:
Hi Leonid,
I was thinking of implementing a similar mechanism in order to fix 7124395.
Please see the Comments section in that bug for some additional details.
Regarding the fix itself:
1. Even though you return NO from canBecomeMain/KeyWindow, the OS will still
bring the window to front of the z-order when you click it. In FX we handle
this by always returning YES from canBecome* methods, however, the
windowDidBecomeKey: sends a special FOCUS_DISABLED event if the window is
blocked. In that case the upper level code re-stacks windows so that the
blocker window always appears on the top of the z-order. Have you verified if
this works fine for AWT apps with your fix?
2. Also, we just don't send mouse events for blocked windows from native code
to Java. Is this handled somewhere else for modally blocked windows in lwawt?
--
best regards,
Anthony
On 4/27/2012 6:11 PM, Leonid Romanov wrote:
Hi,
Please review a fix for 7124376: [macosx] Modal dialog lost focus. One can easily reproduce this
bug by launching SwingSet2, choosing JOptionPane demo and then clicking "Show Message
Dialog" button. Now, click on the "SwingSet2" window title bar and you'll see the
window rapidly gaining and loosing focus.
Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124376
webrev: http://cr.openjdk.java.net/~leonidr/7124376/webrev.00/
Thanks,
Leonid.
