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
