Re: Minimising window with "Always on top" attribute leaves contents in underlying window

["Earle F. Philhower III" <earle at ziplabel 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