At 01:58 PM 21/11/2001 -0800, you wrote:
With regard to my problem that I was getting infinite redraws in my listview following Alexandre's change to server/user/message.c:
I eventually tracked it down to the fact our code used SetRedraw(FALSE)/SetRedraw(TRUE) on a list control. (So the bug can now be demonstrated easily on e.g. the MFC RowList sample with a two-line change). Now I see that in the case of LISTVIEW_SetRedraw DefWindowProc is called and then RedrawWindow. In the TREEVIEW_SetRedraw case it simply sets a flag within the treeview's data.
Which is (more) correct?
I have seen the same problem with the plain listbox
I have an app (Eudora) that is using WM_SETREDRAW on a listbox and found that it was not possible to reproduce the app's behaviour without doing directly a RedrawWindow. Andi commented it was ugly and unefficient (IIRC) and Alexandre Julliard ignored the patch anyway.
So I intended at some point to look at Listview and Treeview (with the nasty intent to prove that I am right and they are wrong of course :-)) If you find that doing an explicit RedrawWindow is the right way (TM) I am all for it.
OTOH, I have myself - at least ;-( - one regression pending for this patch. The attached hack (on dlls/x11drv/winpos.c) fixes it, maybe with a lot of luck it could fix your problem too ?
I'm not too hopeful as it does not seem related but you never know.
Gerard
--- winpos.c.orig Tue Nov 13 23:02:20 2001 +++ winpos.c Thu Nov 22 00:24:35 2001 @@ -1464,6 +1464,14 @@ /*********************************************************************** * X11DRV_ConfigureNotify */ + +Bool predicate(Display *display, XEvent *event, char *arg) +{ + Window w = *((Window *) arg); + return ((event->type == ConfigureNotify) && + (event->xany.window == w)); +} + void X11DRV_ConfigureNotify( HWND hwnd, XConfigureEvent *event ) { HWND oldInsertAfter; @@ -1472,8 +1480,20 @@ RECT rect; WINDOWPOS winpos; int x = event->x, y = event->y; + XConfigureEvent ev;
if (!(win = WIN_GetPtr( hwnd ))) return; + + while (XCheckIfEvent(event->display, (XEvent *)&ev, + predicate, (XPointer)&event->window)) + { + event->x = ev.x; + event->y = ev.y; + event->width = ev.width; + event->height = ev.height; + event->above = ev.above; + event->send_event = ev.send_event; + } data = win->pDriverData;
/* Get geometry */
"Gerard Patel" gerard.patel@nerim.net wrote in message news:1.5.4.32.20011122003731.41920dbc@pop.nerim.net...
At 01:58 PM 21/11/2001 -0800, you wrote:
With regard to my problem that I was getting infinite redraws in my
listview
following Alexandre's change to server/user/message.c:
I eventually tracked it down to the fact our code used SetRedraw(FALSE)/SetRedraw(TRUE) on a list control. (So the bug can now
be
demonstrated easily on e.g. the MFC RowList sample with a two-line
change).
Now I see that in the case of LISTVIEW_SetRedraw DefWindowProc is called
and
then RedrawWindow. In the TREEVIEW_SetRedraw case it simply sets a flag within the
treeview's
data.
Which is (more) correct?
I have seen the same problem with the plain listbox
I have an app (Eudora) that is using WM_SETREDRAW on a listbox and found that it was not possible to reproduce the app's behaviour without doing
directly
a RedrawWindow. Andi commented it was ugly and unefficient (IIRC) and Alexandre Julliard ignored the patch anyway.
So I intended at some point to look at Listview and Treeview (with the
nasty
intent to prove that I am right and they are wrong of course :-)) If you find that doing an explicit RedrawWindow is the right way (TM) I am all for it.
OTOH, I have myself - at least ;-( - one regression pending for this
patch.
The attached hack (on dlls/x11drv/winpos.c) fixes it, maybe with a lot of luck it could fix your problem too ?
I'm not too hopeful as it does not seem related but you never know.
Gerard
<snip>
Thanks Gerard.
It didn't help, I'm afraid.
So I am at a loss. I am about to submit a patch that will "make the problem go away". I hate doing that but it is all beyond me.
If anyone wants to go further here are the details.
The problem disappears if we remove the RDW_FRAME from the RedrawWindow call. (However there is a comment that suggests that someone added it very deliberately).
I see in painting.c that this means we don't do an add_paint_count that we would otherwise have done. It makes sense that this, combined with Alexandre's change, could have an effect.
When the applications are misbehaving there is a continual stream of calls to DispatchMessageA resulting in LISTVIEW_Paint, but without calls to GetMessageW. I suspect that these DispatchMessages are coming from MFC42 but I can't prove that.
anyway, on to something new.
Bill