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@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