From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9807 invoked by alias); 26 Jan 2004 05:10:15 -0000 Mailing-List: contact cygwin-xfree-help@cygwin.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-xfree-owner@cygwin.com Mail-Followup-To: cygwin-xfree@cygwin.com Reply-To: cygwin-xfree@cygwin.com Received: (qmail 9797 invoked from network); 26 Jan 2004 05:10:14 -0000 Received: from unknown (HELO mail03.powweb.com) (66.152.97.36) by sources.redhat.com with SMTP; 26 Jan 2004 05:10:14 -0000 Received: from earle.ziplabel.com (node-40240eca.sjc.onnet.us.uu.net [64.36.14.202]) by mail03.powweb.com (Postfix) with ESMTP id 980FB15F66 for ; Sun, 25 Jan 2004 21:10:27 -0800 (PST) Message-Id: <5.1.1.6.2.20040125204439.00aeb290@mail.ziplabel.com> X-Sender: ziplabel@mail.ziplabel.com Date: Mon, 26 Jan 2004 05:10:00 -0000 To: cygwin-xfree@cygwin.com From: "Earle F. Philhower III" Subject: Re: Minimising window with "Always on top" attribute leaves contents in underlying window In-Reply-To: <40149972.2050200@msu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SW-Source: 2004-01/txt/msg00489.txt.bz2 List-Id: 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