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 [email protected] 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
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 [email protected] 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
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
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 !
-
George Ginden -
Robert Shearman -
Ulrich Czekalla