Recent CVS update causes Quicken popup problem/Help please

[Carl Sopchak]

On Monday, February 21, 2005 03:43 pm, Rein Klazes wrote:
> On 10 Feb 2005 21:19:46 +0100, you wrote:
> > Carl Sopchak <carl.sopchak at cegis123.com> writes:
> > > I guess my problem is that I have NO CLUE as to how this SHOULD be
> > > handled. Should the style be set to (style & ~WS_VISIBLE) when the
> > > rectangle is {0,0;0,0}?  Should {0,0;0,0} be considered a valid
> > > rectangle in validate_window_rectangles()?  Should
> > > validate_window_rectangles() only get called if the rectangle is not
> > > {0,0;0,0}?  Or, very possibly, is there something else that should
> > > happen?  Just to see what happened, I commented out the call to
> > > validate_window_rectangles, and the popup disappeared as it should.
> >
> > The client rectangle should have been set to {0,0;0,0} too. You should
> > look at the WM_NCCALCSIZE processing (SWP_DoNCCalcSize in
> > dlls/x11drv/winpos.c) and check what's happening there with the
> > rectangles.
>
> Experimenting for another issue, I noticed today:
>
> If I execute this under Win2K for a window with the WS_BORDER style:
> |   MoveWindow( hwnd, 0,0,0,0,0);
> |   GetWindowRect ( hwnd, &rc);
> |   trace(" 1. %ld,%ld-%ld,%ld\n", rc.left,rc.top, rc.right, rc.bottom);
> |   DefWindowProcA(hwnd, WM_NCCALCSIZE, 0, (LPARAM)&rc);
> |   trace(" 2. %ld,%ld-%ld,%ld\n", rc.left,rc.top, rc.right, rc.bottom);
>
> this is the result:
>
>  1. 0,0-0,0
>  2. 1,1-1,1
>
> It seems to me this should be allowed as valid.
>
> Rein.

This is the same issue.  I had sent the following under another subject, so it 
didn't get "attached" to this thread, but here is what I found upon further 
investigation:

Ok, so what is happening is this:  In dlls/x11drv/winpos.c, the pNewWindowRect 
is coming into SWP_DoNCCalcSize as (0,0;0,0), wndPtr->rectWindow is 
(182,977;662;998), and wndPty->rectClient is (183,978;661,997).  Then 
winpos.c sends it's own WM_NCCALCSIZE message, and upon return, 
params.rgrc[0] is (1,1;1,1)!  This, in turn, causes the third and fourth 
conditions in the section commented as "If the application sends back 
garbage, ignore it" to be true, which in turn causes the next condition to be 
false, so the client rectangle (pNewClientRect) does NOT get set.  (Follow 
that?? <g>)

Tracing through the processing of this WM_NCCALCSIZE, I find it ends up 
generating two WM_NCCALCSIZE messages, one being handled by DefWindowProc32.  
This leads me to ./windows/defwnd.c, which calls NC_HandleNCCalcSize 
in ./windows/nonclient.c.  Within NC_HandleNCCalcSize, a call is made to 
NC_AdjustRectOuter, then the window's rectangle (winRect) is adjusted based 
on this call.  It is this call and adjustment of winRect that changes winRect 
from (0,0;0,0) to (1,1;-1,-1), which is later "fixed" to (1,1;1,1).

Diving deeper, into NC_AdjustRectOuter, I find that because the window style 
has WS_BOARDER set, adjust is set to 1, then InflateRect is called, which 
sets rect to (-1,-1;1,1) [returned to NC_HandleNCCalcSize tmpRect variable].

So, there's the problem.  The new rectangle size is (0,0;0,0), but has 
WS_BOARDER set, so the WM_NCCALCSIZE message returns (1,1;1,1) erroneously.

The only thing is, I'm still not sure where the "best" place would be to check 
for the new window rectangle of (0,0;0,0) and handle it appropriately - or 
what "appropriate" would be, for that matter...

Further help would be appreciated.

Thanks,

Carl