Re: edit control

[Robert Shearman]

Ulrich Czekalla wrote:
> Running some tests under WinXP I noticed that if the edit control doesn't
> have WS_EX_CLIENTEDGE it looses the WS_BORDER style and it handles painting
> the border. This also has the side effect that it's non-client area goes to
> zero.
>
> ChangeLog:
>        Ulrich Czekalla <ulrich(a)codeweavers.com>
>        Handle painting the border if WS_EX_CLIENTEDGE is not set

This changelog doesn't really seem to match the patch. Are you sure it's 
right?
> ------------------------------------------------------------------------
>
> Index: dlls/user/edit.c
> ===================================================================
> RCS file: /home/wine/wine/dlls/user/edit.c,v
> retrieving revision 1.2
> diff -u -r1.2 edit.c
> --- dlls/user/edit.c	9 Sep 2004 19:18:40 -0000	1.2
> +++ dlls/user/edit.c	15 Sep 2004 16:30:50 -0000
> @@ -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);

This doesn't seem right at all. The new code should be exactly the same 
as the old, barring any side effects from SetWindowLong (which shouldn't 
affect the control anyway since this the function changed is the handler 
for WM_NCCREATE).

Rob

edit control

[Ulrich Czekalla]

On Wed, Sep 15, 2004 at 06:27:11PM +0100, Robert Shearman wrote:
> Ulrich Czekalla wrote:
> > Running some tests under WinXP I noticed that if the edit control doesn't
> > have WS_EX_CLIENTEDGE it looses the WS_BORDER style and it handles painting
> > the border. This also has the side effect that it's non-client area goes to
> > zero.
> >
> > ChangeLog:
> >       Ulrich Czekalla <ulrich(a)codeweavers.com>
> >       Handle painting the border if WS_EX_CLIENTEDGE is not set
>
> This changelog doesn't really seem to match the patch. Are you sure it's 
> right?

Yes. Currently the code always removes its internal WS_BORDER flag so it
doesn't paint its own border. Basically it leaves it to the default
nonclient handler. But it should only do this if WS_EX_CLIENTEDGE is
set. Otherwise it removes the WS_BORDER style and paints the border itself.

The SetWindowLong call is necessary otherwise the default non-client code
will allocate non-client space for the border and we don't want that. We
want to handle the border ourselves.

I'm working on an app that relies on this behaviour.

/Ulrich

edit control

[Robert Shearman]

Ulrich Czekalla wrote:
> Currently the code always removes its internal WS_BORDER flag so it
> doesn't paint its own border. Basically it leaves it to the default
> nonclient handler. But it should only do this if WS_EX_CLIENTEDGE is
> set. Otherwise it removes the WS_BORDER style and paints the border itself.
>
> The SetWindowLong call is necessary otherwise the default non-client code
> will allocate non-client space for the border and we don't want that. We
> want to handle the border ourselves.

Thanks. I see what you mean now.

Rob

edit control

[George Ginden]

Ulrich Czekalla wrote:
> Yes. Currently the code always removes its internal WS_BORDER flag so it
> doesn't paint its own border. Basically it leaves it to the default
> nonclient handler. But it should only do this if WS_EX_CLIENTEDGE is
> set. Otherwise it removes the WS_BORDER style and paints the border itself.
>
> The SetWindowLong call is necessary otherwise the default non-client code
> will allocate non-client space for the border and we don't want that. We
> want to handle the border ourselves.
>
> I'm working on an app that relies on this behaviour.

Hi Ulrich, how is it going with this issue ?

I've noticed that this code paints a perfect edit control, with its 
background color (for the whole area).
4545         es->style      &= ~WS_BORDER;

While the following code in place of the line above, doesn't fill the 
whole edit with the background color, but the area behind the text 
inside the control ONLY.

 4554         if (lpcs->dwExStyle & WS_EX_CLIENTEDGE)
4555             es->style &= ~WS_BORDER;
4556         else if (es->style & WS_BORDER)
4557             SetWindowLongW(hwnd, GWL_STYLE, es->style & ~WS_BORDER);

This is also reletad to 2695.

Thanks !