<Swing Dev> Review request for JDK-6288609 JInternalFrame.setDefaultCloseOperation() interferes with "close" behavior

[prasanta sadhukhan]

Looks ok to me.

Regards
Prasanta
On 11/16/2015 2:24 PM, Rajeev Chamyal wrote:
> Hello Prasanta,
>
> Please review the updated webrev. I have updated it as per review comments.
> http://cr.openjdk.java.net/~rchamyal/6288609/webrev.01
>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: prasanta sadhukhan
> Sent: 16 November 2015 12:32
> To: Rajeev Chamyal
> Cc: Alexander Scherbatiy; swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> Review request for JDK-6288609 JInternalFrame.setDefaultCloseOperation() interferes with "close" behavior
>
> Hi Rajeev,
>
> The fix looks ok to me.
>      But,  Don't we need to put this testcode in EDT?
>
> JInternalFrame internalFrame = desktopPane.getSelectedFrame();
>    133         internalFrame.doDefaultCloseAction();
>    134         internalFrame = desktopPane.getSelectedFrame();
>
> Also, there are wildcard imports in test?
> Also, there is a repetition of code in lin119-130.
>
> Regards
> Prasanta
> On 11/12/2015 4:37 PM, Alexander Scherbatiy wrote:
>>    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 at 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