Recent CVS update causes Quicken popup problem/Help please
I recently did a CVS update after a fairly long time without one. Afterwards, Quicken 2000 Deluxe has had a problem: When in an account register, as you type the description into a new record, Quicken will pop-up a window showing prior transactions that match what you type. (Quicken calls this Quick Fill. If you press Enter, the transaction is copied into the new record. A VERY nice feature!) The problem is that the pop-up never "goes away", which it should do if (a) your typing causes no prior transaction matches, or (b) you accept the match that is suggested. I have found in the wine debug log that Quicken tries to "get rid" of the popup by setting the popup's rectangle to {0,0;0,0}, which causes the server call to set_window_pos to return with "INVALID_PARAMETER {new_style=00000000}". After adding debug TRACE messages to dlls/x11drv/winpos.c, I have confirmed that the window style just prior to the server call is 94800007 (WS_POPUP | WS_VISIBLE | WS_CLIPSIBLINGS | WS_BORDER | WS_DLGMODALFRAME | WS_DRAGDETECT | WS_NOPARENTNOTIFY). After adding further debugging statements to server/window.c, I have found that the server handler for set_window_pos calls validate_window_rectangles(). Validate_window_rectangles fails because {0,0;0,0} is not within the client's rectangle ({1,1;479,20}), so set_window_pos never gets called. Now, I assume that using a rectangle size of {0,0;0,0} is a valid way to pop-down the popup. Even if not, that appears to be the way Quicken is doing it. 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. If anyone has any hints as to what should be done here, I could implement and test this, and send a patch along... As an aside, I noticed on the winehq.org web site that the debugging "quick start" page specifically states that the Debug Channels are not used for the server but the developer's guide does not. And neither suggest how to add debugging messages to the server. Perhaps this could be explained in more detail somewhere? (I could add a section, if the sources of the manual is in CVS, and I knew where they were...) Thanks for the help, Carl
Carl Sopchak <carl.sopchak(a)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. -- Alexandre Julliard julliard(a)winehq.org
On 10 Feb 2005 21:19:46 +0100, you wrote:
Carl Sopchak <carl.sopchak(a)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.
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(a)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
participants (3)
-
Alexandre Julliard -
Carl Sopchak -
Rein Klazes