Re: Initialize listview item size.

[Dimitrie O. Paun]

On February 3, 2003 11:58 am, Duane Clark wrote:
> This is a separate bug from the other listview patches. If an app sends
> a LISTVIEW_Paint to a new listview before adding any items (which an app
> was :-) the item size was not getting set, causing subsequent
> LISTVIEW_Paint calls to clip the painting.
>
> Changelog:
>         Make sure item size is initialized when the first item is added.

This is an optimization I've put in to avoid a lot of complex calculations
while the listview is initially populated (typically before it's being
painted). You are right, we have to detect the change nItemCount from 0
to 1, to do all those calculations. But since we don't actually need them
until we paint, I'd like to defer them as much as possible. Moreover,
with your patch, we don't catch the SetItemCount case. What about this
patch instead:

Index: dlls/comctl32/listview.c
===================================================================
RCS file: /var/cvs/wine/dlls/comctl32/listview.c,v
retrieving revision 1.338
diff -u -r1.338 listview.c
--- dlls/comctl32/listview.c	24 Jan 2003 00:54:59 -0000	1.338
+++ dlls/comctl32/listview.c	5 Feb 2003 06:48:41 -0000
@@ -7850,7 +7850,7 @@
 {
     TRACE("(hdc=%p)\n", hdc);

-    if (infoPtr->bFirstPaint)
+    if (infoPtr->bFirstPaint && infoPtr->nItemCount)
     {
    UINT uView =  infoPtr->dwStyle & LVS_TYPEMASK;

Initialize listview item size.

[Duane Clark]

Dimitrie O. Paun wrote:
> On February 3, 2003 11:58 am, Duane Clark wrote:
> > This is a separate bug from the other listview patches. If an app sends
> > a LISTVIEW_Paint to a new listview before adding any items (which an app
> > was :-) the item size was not getting set, causing subsequent
> > LISTVIEW_Paint calls to clip the painting.
> >
> > Changelog:
> >        Make sure item size is initialized when the first item is added.
>
> This is an optimization I've put in to avoid a lot of complex calculations
> while the listview is initially populated (typically before it's being
> painted). You are right, we have to detect the change nItemCount from 0
> to 1, to do all those calculations. But since we don't actually need them
> until we paint, I'd like to defer them as much as possible. Moreover,
> with your patch, we don't catch the SetItemCount case. What about this
> patch instead:

Last night almost the same solution occured to me, so yes I would agree 
this is better.