The fix looks good to me.
Thanks,
Alexandr.
On 11/12/2015 12:05 PM, Rajeev Chamyal wrote:
Hello Alexander,
At all other places we call firePropertyChange(IS_CLOSED_PROPERTY,
Boolean.FALSE,Boolean.TRUE); before calling dispose. Which will result in
unselecting and closing the frame.
If API user is extending the InternalFrameUI classes then they have to care of
selection/deselection themselves.
I have tested the fix with all look and feels on Windows and Ubuntu and on MAC
with Aqua LAF as well.
Regards,
Rajeev Chamyal
-----Original Message-----
From: Alexander Scherbatiy
Sent: 06 November 2015 19:41
To: Rajeev Chamyal
Cc: Sergey Bylokhov; swing-dev@openjdk.java.net
Subject: Re: Review request for JDK-6288609 JInternalFrame.setDefaultCloseOperation()
interferes with "close" behavior
On 10/29/2015 10:41 AM, Rajeev Chamyal wrote:
Hello All,
Please review the following fix for Jdk9:
*Bug*:https://bugs.openjdk.java.net/browse/JDK-6288609
*Webrev*:http://cr.openjdk.java.net/~rchamyal/6288609/webrev.00/
<http://cr.openjdk.java.net/%7Erchamyal/6288609/webrev.00/>
*Issue*: On disposing the Top level JInternalFrame focus is not
shifting to the JInternalFrame below it.
*Cause*: Dispose method is changing the selection of currently closing
frame and then it calls the DefaultDeskTopManager:closeFrame which
finds the JInternalFrame below the closing frame based on selection of
the closing frame and then shifts the focus to frame below it.
Since selection is already changed by dispose method
DefaultDeskTopManager:closeFrame is unable to find reference to
previous frame.
*Fix*: Removed the selection change code from Dispose method.
Are there any cases that the JInternalFrame is still selected after the
IS_CLOSED_PROPERTY is fired in the dispose() method so it is still necessary to
set the selection to false?
Thanks,
Alexandr.
Regards,
Rajeev Chamyal
