Editbox background regression (bug 2695)
*See Bug #2695 for screenshots: http://bugs.winehq.com/show_bug.cgi?id=2695 This regression was introduced within wine 20041019, since wine-20040914 was working just fine. (The latest release is still affected by the problem). The diff between these two versions is 5 megs big so I'm just wondering, which area of the codebase is affected by the bug... edit.c is not the case... Regards. *
On Thu, 03 Feb 2005 18:04:17 +0100, George Ginden <ginden(a)email.com> wrote:
*See Bug #2695 for screenshots: http://bugs.winehq.com/show_bug.cgi?id=2695
This regression was introduced within wine 20041019, since wine-20040914 was working just fine. (The latest release is still affected by the problem). The diff between these two versions is 5 megs big so I'm just wondering, which area of the codebase is affected by the bug... edit.c is not the case...
It would help if you could do a regression test on the problem. See this link: http://winehq.org/site/docs/wine-devel/x1314 -- James Hawkins
James Hawkins ha scritto:
It would help if you could do a regression test on the problem. See this link:
Ok I've been doing the "binary search" for a while and, luckily, here is the offending patch: diff -urN wine-20040916/dlls/user/edit.c wine-20040917/dlls/user/edit.c --- wine-20040916/dlls/user/edit.c Fri Feb 4 11:21:16 2005 +++ wine-20040917/dlls/user/edit.c Fri Feb 4 14:41:11 2005 @@ -4423,13 +4423,18 @@ /* * In Win95 look and feel, the WS_BORDER style is replaced by the * WS_EX_CLIENTEDGE style for the edit control. This gives the edit - * control a non client area. Not always. This coordinates in some - * way with the window creation code in dialog.c When making - * modifications please ensure that the code still works for edit - * controls created directly with style 0x50800000, exStyle 0 ( - * which should have a single pixel border) + * control a nonclient area so we don't need to draw the border. + * If WS_BORDER without WS_EX_CLIENTEDGE is specified we shouldn't have + * a nonclient area and we should handle painting the border ourselves. + * + * When making modifications please ensure that the code still works + * for edit controls created directly with style 0x50800000, exStyle 0 + * (which should have a single pixel border) */ - es->style &= ~WS_BORDER; + if (lpcs->dwExStyle & WS_EX_CLIENTEDGE) + es->style &= ~WS_BORDER; + else if (es->style & WS_BORDER) + SetWindowLongW(hwnd, GWL_STYLE, es->style & ~WS_BORDER); return TRUE; } Please refer to http://bugs.winehq.com/show_bug.cgi?id=2695 for the reverting patch. Regards.
James Hawkins ha scritto:
It would help if you could do a regression test on the problem. See this link:
Is anybody on this is issue ?
On Fri, 04 Feb 2005 17:40:13 +0100, Gabriele Giorgetti <g.giorgetti(a)teamsystem.com> wrote:
James Hawkins ha scritto:
It would help if you could do a regression test on the problem. See this link:
Ok I've been doing the "binary search" for a while and, luckily, here is the offending patch:
diff -urN wine-20040916/dlls/user/edit.c wine-20040917/dlls/user/edit.c --- wine-20040916/dlls/user/edit.c Fri Feb 4 11:21:16 2005 +++ wine-20040917/dlls/user/edit.c Fri Feb 4 14:41:11 2005 @@ -4423,13 +4423,18 @@ /* * In Win95 look and feel, the WS_BORDER style is replaced by the * WS_EX_CLIENTEDGE style for the edit control. This gives the edit - * control a non client area. Not always. This coordinates in some - * way with the window creation code in dialog.c When making - * modifications please ensure that the code still works for edit - * controls created directly with style 0x50800000, exStyle 0 ( - * which should have a single pixel border) + * control a nonclient area so we don't need to draw the border. + * If WS_BORDER without WS_EX_CLIENTEDGE is specified we shouldn't have + * a nonclient area and we should handle painting the border ourselves. + * + * When making modifications please ensure that the code still works + * for edit controls created directly with style 0x50800000, exStyle 0 + * (which should have a single pixel border) */ - es->style &= ~WS_BORDER; + if (lpcs->dwExStyle & WS_EX_CLIENTEDGE) + es->style &= ~WS_BORDER; + else if (es->style & WS_BORDER) + SetWindowLongW(hwnd, GWL_STYLE, es->style & ~WS_BORDER);
return TRUE; }
Please refer to http://bugs.winehq.com/show_bug.cgi?id=2695 for the reverting patch.
I'm not sure if your patch is correct or not, but you can send it to wine-patches to see if it gets accepted. -- James Hawkins
participants (3)
-
Gabriele Giorgetti -
George Ginden -
James Hawkins