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

Anthony Petrov anthony.petrov at oracle.com
Thu Aug 29 06:16:51 PDT 2013


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? :)


>> 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?

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


More information about the awt-dev mailing list