Editbox background regression (bug 2695)

[George Ginden]

*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.

*

[James Hawkins]

On Thu, 03 Feb 2005 18:04:17 +0100, George Ginden  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

[Gabriele Giorgetti]

James Hawkins ha scritto:
> It would help if you could do a regression test on the problem.  See this link:
>
> http://winehq.org/site/docs/wine-devel/x1314

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.

[George Ginden]

James Hawkins ha scritto:
> > It would help if you could do a regression test on the problem.  See 
> > this link:
> >
> > http://winehq.org/site/docs/wine-devel/x1314

Is anybody on this is issue ?

[James Hawkins]

On Fri, 04 Feb 2005 17:40:13 +0100, Gabriele Giorgetti
 wrote:
> James Hawkins ha scritto:
> > It would help if you could do a regression test on the problem.  See this link:
> >
> > http://winehq.org/site/docs/wine-devel/x1314
>
> 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.