<AWT Dev> [8] Review request for 8016356: Any swing frame resizes ugly.

[Anthony Petrov]

Hi Oleg,

Thanks for investigating this deeper and finding a better solution. This 
version of the fix looks fine to me.

Only a minor formatting issue: please put the "else {" on the previous 
line (right after "} ".) No need for a new webrev with this change.
And I second to Artem, please add more information to the bug report 
with some examples of values reported by those two WinAPI functions.

--
best regards,
Anthony

On 10/07/2013 02:17 PM, Oleg Pekhovskiy wrote:
> Hi All,
>
> Please review the second version of fix
> http://cr.openjdk.java.net/~bagiras/8016356.2/
> for
> http://bugs.sun.com/view_bug.do?bug_id=8016356
>
> I found quite robust way to determine Windows Snap-feature that relies
> upon the difference between the real (GetWindowRect()) and the normal
> placement of the window (GetWindowPlacement()).
> When a window goes snapped the actual and normal rectangles are
> different. In this case WindowResized() method is called to send
> ComponentResized event and update window layout.
>
> This check was placed in the handler of WM_SYSCOMMAND message right
> after SIZE-MOVE loop that works inside AwtWindow::DefWindowProc().
>
> Thanks,
> Oleg
>
>
> On 01.09.2013 10:32, Oleg Pekhovskiy wrote:
>> Hi Anthony,
>>
>> On 29.08.2013 17:16, Anthony Petrov wrote:
>>> Hi Oleg,
>>>
>>> On 08/28/13 01:35, Oleg Pekhovskiy wrote:
>>>> On 26.08.2013 17:20, Anthony Petrov wrote:
>>>>> The fix looks somewhat fragile to me. The sequence of events may
>>>>> change
>>>>> in a future version of Windows, and the fix will fail then.
>>>>
>>>> I agree, the fix is not elegant.
>>>> As for the future: I tested it on Windows 8.1 - it worked.
>>>
>>> I didn't mean *the* Win 8.1, I meant *a* future version. I suppose you
>>> can't test with Win 9 or Win 19 yet, can you? :)
>>>
>>
>> Sure, no guarantee...
>>
>>>
>>>>> Are there any peculiarities for the WM_SIZE messages being posted
>>>>> when a
>>>>> window is snapped? I'm referring to [1] for example, and they suggest
>>>>> that a proper SC_ flag might be specified when snapping occurs. So, if
>>>>> we could detect that, we might unblock the WindowResized() call at the
>>>>> end of the WmSize() method in the AwtWindow class, which would fix the
>>>>> issue.
>>>>
>>>> Unfortunately there is not direct way to determine the snapping.
>>>> My experience says not to play with sending system events manually on
>>>> Windows. That is much more fragile and nobody knows how DefWindowProc()
>>>> would behave.
>>>
>>> I totally agree.
>>>
>>>> I chose WM_SYSCOMMAND handler in AwtWindow::WindowProc() because it's
>>>> synchronous during window resize (looping in
>>>> AwtWindow::DefWindowProc())
>>>> So WindowResized() would be called only when the user releases mouse
>>>> button after resizing. But WM_SIZE message is called each time the size
>>>> of the window is changed while resizing.
>>>
>>> Aren't the position/size of a window change noticeably greater from one
>>> WM_SIZE message to the next one when the snapping occurs, as opposed to
>>> normal resizing? Could we introduce a threshold and only call
>>> WindowResized from WmSize() if the size/position change is greater than
>>> the threshold?
>>
>> Unfortunately, that's impossible in, at least, to cases:
>> 1. The height of window is near the height of desktop, so snapping
>> increases the height of window just for a few pixels.
>> 2. The mouse is moved quite fast during the simple resizing (I got >100
>> pixel increase for one WM_SIZE message).
>>
>>>
>>> I realize that such a solution is no more elegant than your original
>>> one, but at least it doesn't rely on a particular sequence of different
>>> messages, which may change in future versions of Windows.
>>>
>>> --
>>> best regards,
>>> Anthony
>>>
>>>>
>>>> You might also want to explore the WM_WINDOWPOSCHANGED and
>>>>> WM_WINDOWPOSCHANGING events that the window receives during snapping,
>>>>> perhaps they have some characteristics allowing us to ignore the
>>>>> IsResizing() and call the WindowResized() nonetheless.
>>>>
>>>> These messages are sent "as a result of a call to the SetWindowPos
>>>> function or another window-management function" and never appears
>>>> during
>>>> window resizing with the mouse.
>>>>
>>>>>
>>>>> [1]
>>>>> http://stackoverflow.com/questions/9321549/handling-aerosnap-message-in-wndproc
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> This article is an attempt to handle maximize/restore snapping, but
>>>> this
>>>> issue deals with vertical snapping, when top or bottom edge of the
>>>> window moved to the corresponding edge of the screen.
>>>>
>>>>>
>>>>> --
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>> On 08/25/13 16:40, Oleg Pekhovskiy wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> please review the fix
>>>>>> http://cr.openjdk.java.net/~bagiras/8016356.1/
>>>>>> for
>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016356
>>>>>>
>>>>>> Windows 7 has a feature that makes "window being automatically
>>>>>> arranged
>>>>>> when moved to the edge of the screen". And there is no specific
>>>>>> system
>>>>>> notification when that happens. From the other side AwtWindow class
>>>>>> has
>>>>>> some optimization algorithm for resizing that doesn't take into
>>>>>> account
>>>>>> such the arranging. I found indirect way to determine the
>>>>>> arranging by
>>>>>> tracking the sequence of WM_GETMINMAXINFO and WM_SIZE before the
>>>>>> end of
>>>>>> resizing routine, and call WindowResized() when needed to update the
>>>>>> layout.
>>>>>>
>>>>>> Thanks,
>>>>>> Oleg