This is the mail archive of the
cygwin-xfree@cygwin.com
mailing list for the Cygwin XFree86 project.
Re: Minimising window with "Always on top" attribute leaves contents in underlying window
- From: "Earle F. Philhower III" <earle at ziplabel dot com>
- To: cygwin-xfree at cygwin dot com
- Date: Sun, 25 Jan 2004 21:05:20 -0800
- Subject: Re: Minimising window with "Always on top" attribute leaves contents in underlying window
- Reply-to: cygwin-xfree at cygwin dot com
Howdy Harold, I thought you were taking it easy for a while!
At 11:37 PM 1/25/2004 -0500, you wrote:
Any reason for the following in your patch:
@@ -893,7 +909,7 @@
if (s_pScreenPriv != NULL)
s_pScreenPriv->fWindowOrderChanged = TRUE;
}
- return 0;
+ break;
The thing that strikes me as odd is that you have to return from the
WM_WINDOWPOSCHANGED message without calling DefWindowProc (which will get
called if you change that return to a break) in order to prevent Windows
from breaking that message down into a WM_SIZE and WM_MOVE message and
sending those in addition. My worry is that you may have essentially
found a bug in the WM_WINDOWPOSCHANGED handling that was fixed by allowing
the WM_SIZE and WM_MOVE messages to be generated and handled, when we
should really fix such a bug instead of accidentally masking its existance.
I'm not comfortable removing this change from your patch since it will
then need to be tested again to verify that things work as expected. Since
you have already been testing it, I figured it would be easier for you to
do the testing :)
I did extensive testing without that change, actually, because it
took me a while to figure out why the minimize button and sysmenus
worked but the taskbar left-click 2x didn't. ;)
You can remove it, but minimizing the window by 2x-clicking on the
Windows taskbar won't propagate the Z order change w/the same
messages as if you were to use the system menu or the minimize
button. Why? AFAICT the minimize button or menu item send a wm-move,
even if you don't let DefWindowProc() do its thing. I suspect
Explorer sends its own messages when you click on the taskbar,
and they are not the same as the frame WndProc()'s.
FWIW I can't really see any reason not to allow DefWindowProc to have
a shot at the WM_WINDOWPOSCHANGED message, but I'll admit that I've
not gone through all of Kensuke's code...
-Earle F. Philhower, III
earle@ziplabel.com
cdrlabel - ZipLabel - FlpLabel
http://www.cdrlabel.com