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
