<AWT Dev>  Review request for 8016356: Any swing frame resizes ugly.
oleg.pekhovskiy at oracle.com
Sat Aug 31 23:32:25 PDT 2013
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  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
>> 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,
>> 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.
>> 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,
>>> On 08/25/13 16:40, Oleg Pekhovskiy wrote:
>>>> Hi all,
>>>> please review the fix
>>>> 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
More information about the awt-dev