"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