Re: listview expert required (again)

[Dimitrie O. Paun]

On September 1, 2003 03:46 pm, Eric Pouech wrote:
> configuration :
> - a listview in autoarrange mode
> - adding item one after the other
> - say the first item is created with the selection (LVIS_SELECTED)
> - some more items are inserted without the selection
> - in some cases, the selection will move to the newly inserted item
> instead of remaining on the first item (likely some internal index is
> not recalculated in autoarrange mode)

A few questions:
  -- LVS_OWNERDATA? (I guess not...)
  -- LVS_SORTASCENDING or LVS_SORTDESCENDING?
  -- LVS_OWNERDRAWFIXED?
  -- Do you use LPSTR_TEXTCALLBACK for the item text?
  -- Does a refresh fix the problem?
  -- Any pattern to the "some cases"?
  -- Do you use any callbacks?

How important is this to the functionality of the app. It would be
a lot simpler for me to debug it, once I have the app in the tree
(if this is for the app you were talking about, of course).

-- 
Dimi.

Re: listview expert required

[Rein Klazes]

On Fri, 29 Aug 2003 16:15:17 -0400 (EDT), you wrote:

> On Fri, 29 Aug 2003, Rein Klazes wrote:
> 
> > Hi Dimitrie,
> > 
> > This is causing a regression in newsbin pro. 
> > 
> > New postings are highlighted by a green background colour. With the
> > patch the text in the second and higher columns is painted with a normal
> > backgound colour instead of green.
> > Selected rows are OK.
> 
> Can you give this a try please and tell me if it works:
> 
> Index: dlls/comctl32/listview.c

Yes, that fixes it. 

Thank you,

Rein.
-- 
Rein Klazes
[EMAIL PROTECTED]

Re: listview expert required

[Dimitrie O. Paun]

On Fri, 29 Aug 2003, Rein Klazes wrote:

> Hi Dimitrie,
> 
> This is causing a regression in newsbin pro. 
> 
> New postings are highlighted by a green background colour. With the
> patch the text in the second and higher columns is painted with a normal
> backgound colour instead of green.
> Selected rows are OK.

Can you give this a try please and tell me if it works:

Index: dlls/comctl32/listview.c
===
RCS file: /var/cvs/wine/dlls/comctl32/listview.c,v
retrieving revision 1.359
diff -u -r1.359 listview.c
--- dlls/comctl32/listview.c25 Aug 2003 23:44:51 -  1.359
+++ dlls/comctl32/listview.c29 Aug 2003 20:13:33 -
@@ -3565,7 +3565,8 @@
 cdsubitemmode = notify_customdraw(infoPtr, CDDS_PREPAINT, &nmlvcd);
 if (nSubItem == 0) infoPtr->cditemmode = cdsubitemmode;
 if (cdsubitemmode & CDRF_SKIPDEFAULT) goto postpaint;
-prepaint_setup(infoPtr, hdc, &nmlvcd);
+if (nSubItem == 0 || (cdmode & CDRF_NOTIFYITEMDRAW))
+prepaint_setup(infoPtr, hdc, &nmlvcd);
 
 /* in full row select, subitems, will just use main item's colors */
 if (nSubItem && uView == LVS_REPORT && (infoPtr->dwLvExStyle & 
LVS_EX_FULLROWSELECT))

Thanks!


-- 
Dimi.

Re: listview expert required

[Dimitrie O. Paun]

On Fri, 29 Aug 2003, Rein Klazes wrote:

> New postings are highlighted by a green background colour. With the
> patch the text in the second and higher columns is painted with a normal
> backgound colour instead of green.
> Selected rows are OK.

OK, I think I know what the problem is, I'll fix it when I get home.

-- 
Dimi.

Re: listview expert required

[Rein Klazes]

On Sun, 24 Aug 2003 19:34:36 -0400, you wrote:

> On August 24, 2003 05:44 pm, Dimitrie O. Paun wrote:
> > Yes, this patch broke selection drawing:
> >
> > http://www.winehq.org/hypermail/wine-cvs/2003/04/0243.html
> >
> > It's my patch, mea culpa.
> 
> Yeah, at a second look, it was rather obvious what went wrong.
> 
> ChangeLog
> Always setup the selection colour, not just in custom draw.
> 
> Index: dlls/comctl32/listview.c
> ===
> RCS file: /var/cvs/wine/dlls/comctl32/listview.c,v
> retrieving revision 1.357
> diff -u -r1.357 listview.c
> --- dlls/comctl32/listview.c  24 Jul 2003 00:03:13 -  1.357
> +++ dlls/comctl32/listview.c  24 Aug 2003 23:30:31 -

Hi Dimitrie,

This is causing a regression in newsbin pro. 

New postings are highlighted by a green background colour. With the
patch the text in the second and higher columns is painted with a normal
backgound colour instead of green.
Selected rows are OK.

Rein.
-- 
Rein Klazes
[EMAIL PROTECTED]

Re: listview expert required

[Dimitrie O. Paun]

On August 24, 2003 05:44 pm, Dimitrie O. Paun wrote:
> Yes, this patch broke selection drawing:
>
> http://www.winehq.org/hypermail/wine-cvs/2003/04/0243.html
>
> It's my patch, mea culpa.

Yeah, at a second look, it was rather obvious what went wrong.

ChangeLog
Always setup the selection colour, not just in custom draw.

Index: dlls/comctl32/listview.c
===
RCS file: /var/cvs/wine/dlls/comctl32/listview.c,v
retrieving revision 1.357
diff -u -r1.357 listview.c
--- dlls/comctl32/listview.c24 Jul 2003 00:03:13 -  1.357
+++ dlls/comctl32/listview.c24 Aug 2003 23:30:31 -
@@ -882,15 +882,10 @@
 return result;
 }
 
-static DWORD notify_prepaint (LISTVIEW_INFO *infoPtr, HDC hdc, NMLVCUSTOMDRAW 
*lpnmlvcd)
+static void prepaint_setup (LISTVIEW_INFO *infoPtr, HDC hdc, NMLVCUSTOMDRAW *lpnmlvcd)
 {
-BOOL isSelected = lpnmlvcd->nmcd.uItemState & CDIS_SELECTED;
-DWORD cditemmode = notify_customdraw(infoPtr, CDDS_PREPAINT, lpnmlvcd);
-
-if (cditemmode & CDRF_SKIPDEFAULT) return cditemmode;
-
 /* apprently, for selected items, we have to override the returned values */
-if (isSelected)
+if (lpnmlvcd->nmcd.uItemState & CDIS_SELECTED)
 {
if (infoPtr->bFocus)
{
@@ -916,8 +911,6 @@
 else
SetBkMode(hdc, TRANSPARENT);
 SetTextColor(hdc, lpnmlvcd->clrText);
-
-return cditemmode;
 }
 
 static inline DWORD notify_postpaint (LISTVIEW_INFO *infoPtr, NMLVCUSTOMDRAW 
*lpnmlvcd)
@@ -3569,9 +3562,10 @@
 
 if (nSubItem > 0) cdmode = infoPtr->cditemmode;
 if (cdmode & CDRF_NOTIFYITEMDRAW)
-cdsubitemmode = notify_prepaint ( infoPtr, hdc, &nmlvcd);
+cdsubitemmode = notify_customdraw(infoPtr, CDDS_PREPAINT, &nmlvcd);
 if (nSubItem == 0) infoPtr->cditemmode = cdsubitemmode;
 if (cdsubitemmode & CDRF_SKIPDEFAULT) goto postpaint;
+prepaint_setup(infoPtr, hdc, &nmlvcd);
 
 /* in full row select, subitems, will just use main item's colors */
 if (nSubItem && uView == LVS_REPORT && (infoPtr->dwLvExStyle & 
LVS_EX_FULLROWSELECT))
@@ -3697,11 +3691,14 @@
if (cdmode & CDRF_NOTIFYITEMDRAW)
{
customdraw_fill(&nmlvcd, infoPtr, hdc, &dis.rcItem, &item);
-cditemmode = notify_prepaint (infoPtr, hdc, &nmlvcd);
+cditemmode = notify_customdraw(infoPtr, CDDS_PREPAINT, &nmlvcd);
}
 
if (!(cditemmode & CDRF_SKIPDEFAULT))
+   {
+prepaint_setup (infoPtr, hdc, &nmlvcd);
SendMessageW(hwndParent, WM_DRAWITEM, dis.CtlID, (LPARAM)&dis);
+   }
 
if (cditemmode & CDRF_NOTIFYPOSTPAINT)
 notify_postpaint(infoPtr, &nmlvcd);
@@ -3848,8 +3845,9 @@
 
 GetClientRect(infoPtr->hwndSelf, &rcClient);
 customdraw_fill(&nmlvcd, infoPtr, hdc, &rcClient, 0);
-cdmode = notify_prepaint(infoPtr, hdc, &nmlvcd);
+cdmode = notify_customdraw(infoPtr, CDDS_PREPAINT, &nmlvcd);
 if (cdmode & CDRF_SKIPDEFAULT) goto enddraw;
+prepaint_setup(infoPtr, hdc, &nmlvcd);
 
 /* Use these colors to draw the items */
 infoPtr->clrTextBk = nmlvcd.clrTextBk;


-- 
Dimi.

Re: listview expert required

[Dimitrie O. Paun]

On August 23, 2003 04:32 am, Eric Pouech wrote:
> also, as a noted difference, in selection. Wine's only draws a dotted
> rect around the selected item (or row in full row select mode). In
> native, the rect interior is grayed if the control doesn't have the
> focus, and filled in blue if control has the focus.

Yes, this patch broke selection drawing:

http://www.winehq.org/hypermail/wine-cvs/2003/04/0243.html

It's my patch, mea culpa.

I'll have to look into it, it's not obvious why it broke.
It will have to wait a bit, I don't have time now.

-- 
Dimi.

Re: listview expert required

[Dimitrie O. Paun]

On August 23, 2003 11:37 am, Eric Pouech wrote:
> thanks... works like a charm now
> impressive turn around time btw!!

Oh, thank you, you are too kind. I just happened to
have a few moments free in the morning (thanks to my
g/f who did not complain too loudly about me being
late for breakfast :)).

So I guess we can include it...

ChangeLog
Fix the hit test for full row select in REPORT mode.
(Found, debugged, and tested by Eric Pouech)

Index: dlls/comctl32/listview.c
===
RCS file: /var/cvs/wine/dlls/comctl32/listview.c,v
retrieving revision 1.357
diff -u -r1.357 listview.c
--- dlls/comctl32/listview.c24 Jul 2003 00:03:13 -  1.357
+++ dlls/comctl32/listview.c23 Aug 2003 15:02:54 -
@@ -5768,6 +5768,7 @@
 POINT Origin, Position, opt;
 LVITEMW lvItem;
 ITERATOR i;
+INT iItem;
 
 TRACE("(pt=%s, subitem=%d, select=%d)\n", debugpoint(&lpht->pt), subitem, select);
 
@@ -5800,17 +5801,17 @@
 
 iterator_frameditems(&i, infoPtr, &rcSearch);
 iterator_next(&i); /* go to first item in the sequence */
-lpht->iItem = i.nItem;
+iItem = i.nItem;
 iterator_destroy(&i);

-TRACE("lpht->iItem=%d\n", lpht->iItem); 
-if (lpht->iItem == -1) return -1;
+TRACE("lpht->iItem=%d\n", iItem); 
+if (iItem == -1) return -1;
 
 lvItem.mask = LVIF_STATE | LVIF_TEXT;
 if (uView == LVS_REPORT) lvItem.mask |= LVIF_INDENT;
 lvItem.stateMask = LVIS_STATEIMAGEMASK;
 if (uView == LVS_ICON) lvItem.stateMask |= LVIS_FOCUSED;
-lvItem.iItem = lpht->iItem;
+lvItem.iItem = iItem;
 lvItem.iSubItem = 0;
 lvItem.pszText = szDispText;
 lvItem.cchTextMax = DISP_TEXT_SIZE;
@@ -5818,11 +5819,11 @@
 if (!infoPtr->bFocus) lvItem.state &= ~LVIS_FOCUSED; 
 
 LISTVIEW_GetItemMetrics(infoPtr, &lvItem, &rcBox, &rcState, &rcIcon, &rcLabel);
-LISTVIEW_GetItemOrigin(infoPtr, lpht->iItem, &Position);
+LISTVIEW_GetItemOrigin(infoPtr, iItem, &Position);
 opt.x = lpht->pt.x - Position.x - Origin.x;
 opt.y = lpht->pt.y - Position.y - Origin.y;
 
-if (uView == LVS_REPORT && (infoPtr->dwLvExStyle & LVS_EX_FULLROWSELECT))
+if (uView == LVS_REPORT)
rcBounds = rcBox;
 else
UnionRect(&rcBounds, &rcIcon, &rcLabel);
@@ -5839,7 +5840,7 @@
lpht->flags &= ~LVHT_NOWHERE;

 TRACE("lpht->flags=0x%x\n", lpht->flags); 
-if (uView == LVS_REPORT && lpht->iItem != -1 && subitem)
+if (uView == LVS_REPORT && subitem)
 {
INT j;
 
@@ -5856,12 +5857,12 @@
}
 }
 
-if (!select || lpht->iItem == -1) return lpht->iItem;
-
-if (uView == LVS_REPORT && (infoPtr->dwLvExStyle & LVS_EX_FULLROWSELECT)) return 
lpht->iItem;
-
-if (uView == LVS_REPORT) UnionRect(&rcBounds, &rcIcon, &rcLabel);
-return PtInRect(&rcBounds, opt) ? lpht->iItem : -1;
+if (select && !(uView == LVS_REPORT && (infoPtr->dwLvExStyle & 
LVS_EX_FULLROWSELECT)))
+{
+if (uView == LVS_REPORT) UnionRect(&rcBounds, &rcIcon, &rcLabel);
+if (!PtInRect(&rcBounds, opt)) iItem = -1;
+}
+return lpht->iItem = iItem;
 }
 
 


-- 
Dimi.

Re: listview expert required

[Eric Pouech]

implements what you described.
thanks... works like a charm now
impressive turn around time btw!!
A+
--
Eric Pouech

Re: listview expert required

[Dimitrie O. Paun]

On August 23, 2003 04:32 am, Eric Pouech wrote:
> listview: multicolumn, in report mode, without LVS_EX_FULLROWSELECT
> extended style
>
> message concerned:
> NM_CLICK notification for left click in LV (mainly in a column for any
> subitem)
>
> native:
> iItem: always set to -1
> iSubItem: set to the subItem of the column clicked
>
> builtin:
> iItem: set to the row number
> iSubItem: always set to 0
>
> (Note: I don't like either the iItem value I get from the native DLL
> (didn't test LVM_GETITEMHITTEST information though)

Can you please give this one a try? Sorry, my Wine crashes ATM so
I can not test, but I hope it Index: dlls/comctl32/listview.c
===
RCS file: /var/cvs/wine/dlls/comctl32/listview.c,v
retrieving revision 1.357
diff -u -r1.357 listview.c
--- dlls/comctl32/listview.c24 Jul 2003 00:03:13 -  1.357
+++ dlls/comctl32/listview.c23 Aug 2003 15:02:54 -
@@ -5768,6 +5768,7 @@
 POINT Origin, Position, opt;
 LVITEMW lvItem;
 ITERATOR i;
+INT iItem;
 
 TRACE("(pt=%s, subitem=%d, select=%d)\n", debugpoint(&lpht->pt), subitem, select);
 
@@ -5800,17 +5801,17 @@
 
 iterator_frameditems(&i, infoPtr, &rcSearch);
 iterator_next(&i); /* go to first item in the sequence */
-lpht->iItem = i.nItem;
+iItem = i.nItem;
 iterator_destroy(&i);

-TRACE("lpht->iItem=%d\n", lpht->iItem); 
-if (lpht->iItem == -1) return -1;
+TRACE("lpht->iItem=%d\n", iItem); 
+if (iItem == -1) return -1;
 
 lvItem.mask = LVIF_STATE | LVIF_TEXT;
 if (uView == LVS_REPORT) lvItem.mask |= LVIF_INDENT;
 lvItem.stateMask = LVIS_STATEIMAGEMASK;
 if (uView == LVS_ICON) lvItem.stateMask |= LVIS_FOCUSED;
-lvItem.iItem = lpht->iItem;
+lvItem.iItem = iItem;
 lvItem.iSubItem = 0;
 lvItem.pszText = szDispText;
 lvItem.cchTextMax = DISP_TEXT_SIZE;
@@ -5818,11 +5819,11 @@
 if (!infoPtr->bFocus) lvItem.state &= ~LVIS_FOCUSED; 
 
 LISTVIEW_GetItemMetrics(infoPtr, &lvItem, &rcBox, &rcState, &rcIcon, &rcLabel);
-LISTVIEW_GetItemOrigin(infoPtr, lpht->iItem, &Position);
+LISTVIEW_GetItemOrigin(infoPtr, iItem, &Position);
 opt.x = lpht->pt.x - Position.x - Origin.x;
 opt.y = lpht->pt.y - Position.y - Origin.y;
 
-if (uView == LVS_REPORT && (infoPtr->dwLvExStyle & LVS_EX_FULLROWSELECT))
+if (uView == LVS_REPORT)
rcBounds = rcBox;
 else
UnionRect(&rcBounds, &rcIcon, &rcLabel);
@@ -5839,7 +5840,7 @@
lpht->flags &= ~LVHT_NOWHERE;

 TRACE("lpht->flags=0x%x\n", lpht->flags); 
-if (uView == LVS_REPORT && lpht->iItem != -1 && subitem)
+if (uView == LVS_REPORT && subitem)
 {
INT j;
 
@@ -5856,12 +5857,12 @@
}
 }
 
-if (!select || lpht->iItem == -1) return lpht->iItem;
-
-if (uView == LVS_REPORT && (infoPtr->dwLvExStyle & LVS_EX_FULLROWSELECT)) return 
lpht->iItem;
-
-if (uView == LVS_REPORT) UnionRect(&rcBounds, &rcIcon, &rcLabel);
-return PtInRect(&rcBounds, opt) ? lpht->iItem : -1;
+if (select && !(uView == LVS_REPORT && (infoPtr->dwLvExStyle & 
LVS_EX_FULLROWSELECT)))
+{
+if (uView == LVS_REPORT) UnionRect(&rcBounds, &rcIcon, &rcLabel);
+if (!PtInRect(&rcBounds, opt)) iItem = -1;
+}
+return lpht->iItem = iItem;
 }
 
 
implements what you described.



-- 
Dimi.

Re: listview expert required

[Eric Pouech]

Dimitrie O. Paun wrote:
On Fri, 22 Aug 2003, Eric Pouech wrote:


some apps of mine needs this to get going:
can someone with good listview knowledge confirm ? (or find the correct fix)


-if (uView == LVS_REPORT && (infoPtr->dwLvExStyle & LVS_EX_FULLROWSELECT))
+if (uView == LVS_REPORT /*&& (infoPtr->dwLvExStyle & LVS_EX_FULLROWSELECT)*/)
 
If you do this, you will be able to select a row in REPORT mode when you
are not in LVS_EX_FULLROWSELECT, when you just click in a sub item.

This is easy enough to test (I can't do it right now, sorry), and if that's
how the native control behaves, then let's just get rid of it.
What's the problem with your app?

but here's the differences I get between running native Win98 comctl and 
Wine's builtin

listview: multicolumn, in report mode, without LVS_EX_FULLROWSELECT 
extended style

message concerned:
NM_CLICK notification for left click in LV (mainly in a column for any 
subitem)

native:
iItem: always set to -1
iSubItem: set to the subItem of the column clicked
builtin:
iItem: set to the row number
iSubItem: always set to 0
(Note: I don't like either the iItem value I get from the native DLL 
(didn't test LVM_GETITEMHITTEST information though)

also, as a noted difference, in selection. Wine's only draws a dotted 
rect around the selected item (or row in full row select mode). In 
native, the rect interior is grayed if the control doesn't have the 
focus, and filled in blue if control has the focus.

if everything goes smoothly full code of the app should be posted this 
weekend (app will allow, among other things, to enable/disable debug 
channels on any running wine app)

A+
--
Eric Pouech

Re: listview expert required

[Dimitrie O. Paun]

On Fri, 22 Aug 2003, Eric Pouech wrote:

> some apps of mine needs this to get going:
> can someone with good listview knowledge confirm ? (or find the correct fix)


-if (uView == LVS_REPORT && (infoPtr->dwLvExStyle & LVS_EX_FULLROWSELECT))
+if (uView == LVS_REPORT /*&& (infoPtr->dwLvExStyle & LVS_EX_FULLROWSELECT)*/)
 
If you do this, you will be able to select a row in REPORT mode when you
are not in LVS_EX_FULLROWSELECT, when you just click in a sub item.

This is easy enough to test (I can't do it right now, sorry), and if that's
how the native control behaves, then let's just get rid of it.

What's the problem with your app?

-- 
Dimi.

Re: ListView

[Maxime Bellengé]

I think you should post it to wine-patches if this patch has been
forgotten.



On Tue, 2003-06-10 at 08:47, Matej Spiller wrote:
> When running UltimateZip I get 
> LISTVIEW_GetColumnInfo(LISTVIEW_INFO *infoPtr, INT nSubItem)  
> (listview.c:1237) ... assert (nSubItem >= 0 &&
> nSubItem < infoPtr->hdpaColumns->nItemCount);
>  
> Atfer doing some digging, I found out that problem is when deleting
> last column in ListView and scrolling it afterward. Atfer some more
> digging I found out that patch for this was already created and issued
> by Stefan Haller but was never commited. 
>  
> In MSDN it says that last column should never be deleted (but we still
> need bulletproof code), but under WinXP I'm able to delete last column
> without any problems. We have two options, to delete last colulmn, or
> to return false and not delete last column. 
>  
> Anyway after mine or Stefan's patch UltimateZip and Starbase
> StarTeam work (our patch uses first option, deletes last column).
>  
> http://www.winehq.com/hypermail/wine-patches/2003/02/0212.html
>  
> Matej Spiller-Muys
-- 
Maxime Bellengé <[EMAIL PROTECTED]>

Re: Listview alignment fix

[biggun from the sun]

>Can you try DT_VCENTER instead of DT_BOTTOM? Maybe that will do the trick. 

 
OK :) Now it's looks exactly what it have to !MSN 8 with e-mail virus protection service:  2 months FREE*

Re: Listview alignment fix

[Dimitrie O. Paun]

On Tue, 27 May 2003, BiGgUn wrote:

> 
> Hi,
> 
>The alignment is OK with your patch. I think it's better than mine. But the 
> text doesn't have the same alignment as Windows
>  font or #define'd problem ?)

Can you try DT_VCENTER instead of DT_BOTTOM? Maybe that will do the trick.


-- 
Dimi.

Re: Listview alignment fix

[BiGgUn]

Hi,

   The alignment is OK with your patch. I think it's better than mine. But the 
text doesn't have the same alignment as Windows
 font or #define'd problem ?)

 Stéphan

Re: ListView - add CACHEHINT notification in OwnerData mode

[Dimitrie O. Paun]

On March 22, 2003 04:21 pm, Vitaliy Margolen wrote:
> List view should sent LVN_ODCACHEHINT notification before paint when it's
> virtual list (LVS_OWNERDATA style). We were sending it only in OwnerDraw.

Indeed. Thanks for the patch. I suggest a slightly different patch,
that cleansup the duplication. Does this work for you?

ChangeLog
  Send LVN_ODCACHEHINT notification for LVS_OWNERDATA style in all modes
  (based on a patch by Vitaliy Margolen).

Index: dlls/comctl32/listview.c
===
RCS file: /var/cvs/wine/dlls/comctl32/listview.c,v
retrieving revision 1.345
diff -u -r1.345 listview.c
--- dlls/comctl32/listview.c15 Mar 2003 00:05:46 -  1.345
+++ dlls/comctl32/listview.c23 Mar 2003 16:54:05 -
@@ -3618,14 +3618,13 @@
  * RETURN:
  * None
  */
-static void LISTVIEW_RefreshOwnerDraw(LISTVIEW_INFO *infoPtr, HDC hdc)
+static void LISTVIEW_RefreshOwnerDraw(LISTVIEW_INFO *infoPtr, ITERATOR *i, HDC hdc)
 {
 UINT uID = GetWindowLongW(infoPtr->hwndSelf, GWL_ID);
 HWND hwndParent = GetParent(infoPtr->hwndSelf);
 POINT Origin, Position;
 DRAWITEMSTRUCT dis;
 LVITEMW item;
-ITERATOR i;
 
 TRACE("()\n");
 
@@ -3633,26 +3632,11 @@
 
 /* Get scroll info once before loop */
 LISTVIEW_GetOrigin(infoPtr, &Origin);
-
-/* figure out what we need to draw */
-iterator_visibleitems(&i, infoPtr, hdc);
 
-/* send cache hint notification */
-if (infoPtr->dwStyle & LVS_OWNERDATA)
-{
-   RANGE range = iterator_range(&i);
-NMLVCACHEHINT nmlv;
-
-   ZeroMemory(&nmlv, sizeof(NMLVCACHEHINT));
-nmlv.iFrom = range.lower;
-nmlv.iTo   = range.upper - 1;
-notify_hdr(infoPtr, LVN_ODCACHEHINT, &nmlv.hdr);
-}
-
 /* iterate through the invalidated rows */
-while(iterator_next(&i))
+while(iterator_next(i))
 {
-   item.iItem = i.nItem;
+   item.iItem = i->nItem;
item.iSubItem = 0;
item.mask = LVIF_PARAM | LVIF_STATE;
item.stateMask = LVIS_SELECTED | LVIS_FOCUSED;
@@ -3677,7 +3661,6 @@
TRACE("item=%s, rcItem=%s\n", debuglvitem_t(&item, TRUE), 
debugrect(&dis.rcItem));
SendMessageW(hwndParent, WM_DRAWITEM, dis.CtlID, (LPARAM)&dis);
 }
-iterator_destroy(&i);
 }
 
 /***
@@ -3692,13 +3675,13 @@
  * RETURN:
  * None
  */
-static void LISTVIEW_RefreshReport(LISTVIEW_INFO *infoPtr, HDC hdc, DWORD cdmode)
+static void LISTVIEW_RefreshReport(LISTVIEW_INFO *infoPtr, ITERATOR *i, HDC hdc, 
DWORD cdmode)
 {
 INT rgntype;
 RECT rcClip, rcItem;
 POINT Origin, Position;
 RANGE colRange;
-ITERATOR i, j;
+ITERATOR j;
 
 TRACE("()\n");
 
@@ -3726,16 +3709,13 @@
 if (infoPtr->dwLvExStyle & LVS_EX_FULLROWSELECT)
j.nSpecial = 0;
 
-/* figure out what we need to draw */
-iterator_visibleitems(&i, infoPtr, hdc);
-
 /* iterate through the invalidated rows */
-while(iterator_next(&i))
+while(iterator_next(i))
 {
/* iterate through the invalidated columns */
while(iterator_next(&j))
{
-   LISTVIEW_GetItemOrigin(infoPtr, i.nItem, &Position);
+   LISTVIEW_GetItemOrigin(infoPtr, i->nItem, &Position);
Position.x += Origin.x;
Position.y += Origin.y;
 
@@ -3748,10 +3728,10 @@
if (!RectVisible(hdc, &rcItem)) continue;
}
 
-   LISTVIEW_DrawItem(infoPtr, hdc, i.nItem, j.nItem, Position, cdmode);
+   LISTVIEW_DrawItem(infoPtr, hdc, i->nItem, j.nItem, Position, cdmode);
}
 }
-iterator_destroy(&i);
+iterator_destroy(&j);
 }
 
 /***
@@ -3766,26 +3746,21 @@
  * RETURN:
  * None
  */
-static void LISTVIEW_RefreshList(LISTVIEW_INFO *infoPtr, HDC hdc, DWORD cdmode)
+static void LISTVIEW_RefreshList(LISTVIEW_INFO *infoPtr, ITERATOR *i, HDC hdc, DWORD 
cdmode)
 {
 POINT Origin, Position;
-ITERATOR i;
 
 /* Get scroll info once before loop */
 LISTVIEW_GetOrigin(infoPtr, &Origin);
 
-/* figure out what we need to draw */
-iterator_visibleitems(&i, infoPtr, hdc);
-
-while(iterator_prev(&i))
+while(iterator_prev(i))
 {
-   LISTVIEW_GetItemOrigin(infoPtr, i.nItem, &Position);
+   LISTVIEW_GetItemOrigin(infoPtr, i->nItem, &Position);
Position.x += Origin.x;
Position.y += Origin.y;
 
-LISTVIEW_DrawItem(infoPtr, hdc, i.nItem, 0, Position, cdmode);
+LISTVIEW_DrawItem(infoPtr, hdc, i->nItem, 0, Position, cdmode);
 }
-iterator_destroy(&i);
 }
 
 
@@ -3809,6 +3784,7 @@
 DWORD cdmode;
 INT oldBkMode;
 RECT rcClient;
+ITERATOR i;
 
 LISTVIEW_DUMP(infoPtr);
   
@@ -3835,19 +3811,35 @@
 /* nothing to draw */
 if(infoPtr->nItemCount == 0) goto enddraw;
 
+/* figure out what we need to draw */
+iterator_visibleitems(&i, infoPtr, hdc);
+
+/* send cache hint notification */
+if (infoPtr->dwStyle & LVS_OWNERDATA)
+{

Re: ListView Part2

[Dimitrie O. Paun]

On March 14, 2003 02:22 am, Vitaliy Margolen wrote:
> -INT cy = HIWORD(spacing), cx = LOWORD(spacing);
> +signed short int cy = HIWORD(spacing), cx = LOWORD(spacing);

Good spotting! An alternative fix is to us SHIWORD() and SLOWORD() instead.

But since we're here, the pattern is to decode this sort of thing
directly in LISTVIEW_WindowProc(), so let's do just that:

ChangeLog
  Spacing information is signed (debugged and fixed by Vitaliy Margolen).
  Decode spacing information in the window procedure.
  Some spelling fixes.

Index: dlls/comctl32/listview.c
===
RCS file: /var/cvs/wine/dlls/comctl32/listview.c,v
retrieving revision 1.343
diff -u -r1.343 listview.c
--- dlls/comctl32/listview.c7 Mar 2003 20:35:30 -   1.343
+++ dlls/comctl32/listview.c14 Mar 2003 13:59:57 -
@@ -937,7 +937,7 @@
  *   - a special item to deal with
  *   - simple range, or composite range
  *   - empty range.
- * If find bugs, or want to add features, please make sure you
+ * If you find bugs, or want to add features, please make sure you
  * always check/modify *both* iterator_prev, and iterator_next.
  */
 
@@ -1249,7 +1249,7 @@
 return LISTVIEW_GetItemT(infoPtr, lpLVItem, TRUE);
 }
 
-/* Listview invlaidation functions: use _only_ these function to invalidate */
+/* Listview invalidation functions: use _only_ these functions to invalidate */
 
 static inline BOOL is_redrawing(LISTVIEW_INFO *infoPtr)
 {
@@ -6478,12 +6478,13 @@
  *
  * PARAMETER(S):
  * [I] infoPtr : valid pointer to the listview structure
- * [I] spacing : MAKELONG(cx, cy)
+ * [I] cx : horizontal spacing (-1 = system spacing, 0 = autosize)
+ * [I] cy : vertical spacing (-1 = system spacing, 0 = autosize)
  *
  * RETURN:
  *   MAKELONG(oldcx, oldcy)
  */
-static DWORD LISTVIEW_SetIconSpacing(LISTVIEW_INFO *infoPtr, DWORD spacing)
+static DWORD LISTVIEW_SetIconSpacing(LISTVIEW_INFO *infoPtr, INT cx, INT cy)
 {
 INT cy = HIWORD(spacing), cx = LOWORD(spacing);
 DWORD oldspacing = MAKELONG(infoPtr->iconSpacing.cx, infoPtr->iconSpacing.cy);
@@ -6567,7 +6568,7 @@
 himlOld = infoPtr->himlNormal;
 infoPtr->himlNormal = himl;
 if (uView == LVS_ICON) set_icon_size(&infoPtr->iconSize, himl, FALSE);
-LISTVIEW_SetIconSpacing(infoPtr, 0);
+LISTVIEW_SetIconSpacing(infoPtr, 0, 0);
 break;
 
 case LVSIL_SMALL:
@@ -8298,7 +8299,7 @@
 {
TRACE("icon old size=(%ld,%ld), new size=(%ld,%ld)\n",
  oldIconSize.cx, oldIconSize.cy, infoPtr->iconSize.cx, 
infoPtr->iconSize.cy);
-   LISTVIEW_SetIconSpacing(infoPtr, 0);
+   LISTVIEW_SetIconSpacing(infoPtr, 0, 0);
 }
 }
 else if (uNewView == LVS_REPORT)
@@ -8620,7 +8621,7 @@
 return LISTVIEW_SetHoverTime(infoPtr, (DWORD)wParam);
 
   case LVM_SETICONSPACING:
-return LISTVIEW_SetIconSpacing(infoPtr, (DWORD)lParam);
+return LISTVIEW_SetIconSpacing(infoPtr, SLOWORD(lParam), SHIWORD(lParam));
 
   case LVM_SETIMAGELIST:
 return (LRESULT)LISTVIEW_SetImageList(infoPtr, (INT)wParam, (HIMAGELIST)lParam);


-- 
Dimi.

Re: Listview delete column zero

[Duane Clark]

Dimitrie O. Paun wrote:

On February 13, 2003 11:06 pm, Duane Clark wrote:


I probably should have mentioned why the app deletes column zero. It
repeatedly deletes column zero, testing the returned Boolean until it
gets false, and then it starts inserting new columns. So it ends up
completely replacing the listview contents.



That sounds ... strage . Why not just use LVM_DELETEALLITEMS?



Well, I thought it seemed a bit strange too. The short answer is that 
the new listview has a different number of columns.

Re: Listview delete column zero

[Dimitrie O. Paun]

On February 13, 2003 11:06 pm, Duane Clark wrote:
> I probably should have mentioned why the app deletes column zero. It
> repeatedly deletes column zero, testing the returned Boolean until it
> gets false, and then it starts inserting new columns. So it ends up
> completely replacing the listview contents.

That sounds ... strage . Why not just use LVM_DELETEALLITEMS?

-- 
Dimi.

Re: Listview delete column zero

[Duane Clark]

Duane Clark wrote:

While the MSDN specifically says that column zero should not be deleted,
it does in fact work on WinNT, and at least one app depends on it. On
WinNT, deleting column zero deletes the last column of items but the
first header. Since no app will ever depend on that bizarre behavior,
we just delete the last column including the header.



I probably should have mentioned why the app deletes column zero. It 
repeatedly deletes column zero, testing the returned Boolean until it 
gets false, and then it starts inserting new columns. So it ends up 
completely replacing the listview contents.

Re: Listview problems

[Dimitrie O. Paun]

On February 6, 2003 10:47 pm, Dan Kegel wrote:
> Thanks, Dimi, for finally getting me to try mingw;
> I've been avoiding it out of fear for about eight years.
> It's really improved since those early days!
> (Golly, a gui installer and everything!)

It is cool, isn't it? You're welcome! :)

Here is a Makefile that should work with both mingw and winelib:

==> Makefile <=
# for mingw
#CC = gcc
#RC = windres
# for wine
CC = winegcc
RC = wrc

%-res.o: %.rc
$(RC) -o $@ $<

%.o: %.c
$(CC) -DWIN32 -D_WIN32_IE=0x300 -o $@ -c $<

vlistvw: vlistvw-res.o vlistvw.o
$(CC) -mwindows $^ -o $@ -lcomctl32

===

This is for winelib, to make it work with mingw, just change
the CC & RC definitions.

To compile this under winelib, you need to apply the little
patch that I just send, which I'll include in there for your
convenience:

Index: include/commctrl.h
===
RCS file: /var/cvs/wine/include/commctrl.h,v
retrieving revision 1.103
diff -u -r1.103 commctrl.h
--- include/commctrl.h  4 Jan 2003 00:19:17 -   1.103
+++ include/commctrl.h  7 Feb 2003 07:29:41 -
@@ -3334,6 +3334,8 @@
 int dy;
 } NMLVSCROLL, *LPNMLVSCROLL;

+#define ListView_SetItemCount(hwnd,count) \
+(BOOL)SNDMSGA((hwnd),LVM_SETITEMCOUNT,(WPARAM)(INT)(count),0)
 #define ListView_SetTextBkColor(hwnd,clrBk) \
 (BOOL)SNDMSGA((hwnd),LVM_SETTEXTBKCOLOR,0,(LPARAM)(COLORREF)(clrBk))
 #define ListView_SetTextColor(hwnd,clrBk) \


-- 
Dimi.

Re: Listview problems

[Dimitrie O. Paun]

On February 6, 2003 05:15 am, Dan Kegel wrote:
> I've already sent this to Dimi, but... the demo
> http://msdn.microsoft.com/downloads/samples/internet/commctrl/vlistvw/defau
>lt.asp doesn't work very well with Wine at the moment.
> It demonstrates the LVS_OWNERDATA variant of a listview.

BTW, can you please create a bug report with this stuff,
and either assign it to me, or if you can't, just forward
me the bug number. TIA.

-- 
Dimi.

Re: Listview problems

[Dan Kegel]

Dan Kegel wrote:

I've already sent this to Dimi, but... the demo
http://msdn.microsoft.com/downloads/samples/internet/commctrl/vlistvw/default.asp 

doesn't work very well with Wine at the moment.
It demonstrates the LVS_OWNERDATA variant of a listview.

I built it with msvc6.  The default view looks ok, but if you pick
a different view, the fun starts... "large icons" seem to all
be drawn on top of each other.

BTW: here's how to build that sample from the commandline without nmake:

rc VListVw.rc
cl VListVw.c VListVw.res user32.lib comctl32.lib

And here's how to build it from the commandline with mingw:

windres -o vlistvw_res.o vlistvw.rc
gcc -D_WIN32_IE=0x300 vlistw.c vlistvw_res.o -mwindows -lcomctl32

You'll need to add the definition
#define LPNMLVCACHEHINT PNMLVCACHEHINT
which is missing from mingw's comctl32.h,
and comment out the reference to LPNMLVFINDITEM,
which is also missing from mingw's comctl32.h,
but isn't really used in this demo.

Thanks, Dimi, for finally getting me to try mingw;
I've been avoiding it out of fear for about eight years.
It's really improved since those early days!
(Golly, a gui installer and everything!)
- Dan

--
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Re: Listview scroll patch

[Dimitrie O. Paun]

On December 27, 2002 01:18 am, Chris Morgan wrote:
> +/* Return the corresponding text for a given scroll value */
> +static inline LPSTR debugscrollcode(int nScrollCode)
> +{
> +  switch(nScrollCode)
> +  {
> +  case SB_LINELEFT: return "SB_LINELEFT";
> +  case SB_LINERIGHT: return "SB_LINERIGHT";
> +  case SB_PAGELEFT: return "SB_PAGELEFT";
> +  case SB_PAGERIGHT: return "SB_PAGERIGHT";
> +  case SB_THUMBPOSITION: return "SB_THUMBPOSITION";
> +  case SB_THUMBTRACK: return "SB_THUMBTRACK";
> +  case SB_ENDSCROLL: return "SB_ENDSCROLL";
> +  case SB_INTERNAL: return "SB_INTERNAL";
> +  default: return "unknown";
> +  }
> +}

Sorry to be a nag, but please use 4-space indents, like most of the
code in there. 2-space indented code is old, and it's a mark for me
to look over it, all new code should be 4-space indented.

-- 
Dimi.

Re: Listview scroll patch

[Chris Morgan]

Hmm for some reason I was thinking it had to be done via a macro but I 
suppose I can return a pointer to a static string just as easily.  I figured 
someone would balk at that cool macro ;-) hahah

Chris



On Thursday 26 December 2002 09:51 pm, Dimitrie O. Paun wrote:
> On December 26, 2002 04:06 pm, Chris Morgan wrote:
> > +/* Replace the scroll value with text */
> > +#define SCROLL_CODE_TEXT(nScrollCode) \
> > +   (nScrollCode == SB_LINELEFT) ? "SB_LINELEFT" : (nScrollCode ==
> > SB_LINERIGHT) \ +   ? "SB_LINERIGHT" : (nScrollCode ==
> > SB_INTERNAL) ? "SB_INTERNAL" : \ +   (nScrollCode ==
> > SB_PAGELEFT) ? "SB_PAGELEFT" : (nScrollCode == \
> > +   SB_PAGERIGHT) ? "SB_PAGERIGHT" : (nScrollCode ==
> > SB_THUMBPOSITION) ? \ +   "SB_THUMBPOSITION" : (nScrollCode
> > == SB_THUMBTRACK) ? \ +   "SB_THUMBTRACK" : \
> > +   (nScrollCode == SB_ENDSCROLL) ? "SB_ENDSCROLL" \
> > +   : "unknown"
>
> Please do not introduce such macros. I don't really think it's necessary
> to transform the code to text (it clutters the output), but if you
> insist on doing it, just do it through a function:
>
> static inline LPCSTR debugscrollcode(INT nScrollCode)
> {
>  ...
> }
>
> This is the pattern used throughout listview.c. But in general speaking,
> if you can do it without macros, then macros are not the answer.

Re: Listview scroll patch

[Dimitrie O. Paun]

On December 26, 2002 04:06 pm, Chris Morgan wrote:
> +/* Replace the scroll value with text */
> +#define SCROLL_CODE_TEXT(nScrollCode) \
> +   (nScrollCode == SB_LINELEFT) ? "SB_LINELEFT" : (nScrollCode ==
> SB_LINERIGHT) \ +   ? "SB_LINERIGHT" : (nScrollCode ==
> SB_INTERNAL) ? "SB_INTERNAL" : \ +   (nScrollCode ==
> SB_PAGELEFT) ? "SB_PAGELEFT" : (nScrollCode == \
> +   SB_PAGERIGHT) ? "SB_PAGERIGHT" : (nScrollCode ==
> SB_THUMBPOSITION) ? \ +   "SB_THUMBPOSITION" : (nScrollCode ==
> SB_THUMBTRACK) ? \ +   "SB_THUMBTRACK" : \
> +   (nScrollCode == SB_ENDSCROLL) ? "SB_ENDSCROLL" \
> +   : "unknown"

Please do not introduce such macros. I don't really think it's necessary
to transform the code to text (it clutters the output), but if you
insist on doing it, just do it through a function:

static inline LPCSTR debugscrollcode(INT nScrollCode)
{
 ...
}

This is the pattern used throughout listview.c. But in general speaking,
if you can do it without macros, then macros are not the answer.

-- 
Dimi.

Re: Listview report mode tweaks #2

[Dimitrie O. Paun]

On December 20, 2002 01:02 pm, Duane Clark wrote:
> So the only fix to LISTVIEW_GetSubItemRect that remains is to change the
> offset that is applied.

This looks great. Another small nit:
+if (!(uFormat & (DT_RIGHT | DT_CENTER)))
+{
+if (himl && lvItem.iImage >= 0 && !IsRectEmpty(&rcIcon)) rcLabel.left += 2;
+else rcLabel.left += 5;
+}
+else if (uFormat & DT_RIGHT) rcLabel.right -= 5;

It seems this "5" is the same, so maybe a symbolic constant would be better.
Also, it seems the 2 has to do with IMAGE_PADDING which you changed to 0,
so maybe a small rearangement can make this thing more clear.

What I mean is that you disabled image padding, and you achive it some
other way using explicit numbers (2, 5, etc). Turning the logic inside out, 
maybe we can give meaning back to IMAGE_PADDING. If not, we should remove it 
and introduce another meaningful constant.


-- 
Dimi.

Re: Listview report mode tweaks

[Duane Clark]

Dimitrie O. Paun wrote:

On December 19, 2002 07:48 pm, Duane Clark wrote:


I also altered LISTVIEW_GetSubItemRect so that it reports correct
values, as compared against WinNT on ControlSpy.



Problem is that LISTVIEW_GetSubItemRect is documented to return
same thing for LVIR_LABEL and LVIR_BOUNDS. Of course, incorrect
documentation is known to exist, so as long as you checked it...

However, when we implement things different from the documented
behavior, a clear comment explaining why we deviate is appropriate.
Otherwise, someone might get rid of it in the future. :(



Well well... I had not read the docs that closely. I did not expect the 
definition of LVIR_LABEL to depend on what function used it.

This might require that I do a bit more testing. I had noticed that 
LISTVIEW_GetSubItemRect was only specified for use with a "one-based 
index of the subitem", but it works fine on WinNT with subitem '0', the 
first item.

A little more testing shows that with subitem '0', 
LISTVIEW_GetSubItemRect succeeds with LVIR_SELECTBOUNDS too, but that 
item fails for any other subitem. So I suspect the correct behavior is 
for subitem '0' to pass the request on to LISTVIEW_GetItemRect. For non 
zero subitems I may need to try to get icons inserted into another 
column to test with.

Re: Listview report mode tweaks

[Dimitrie O. Paun]

On December 19, 2002 07:48 pm, Duane Clark wrote:
> I also altered LISTVIEW_GetSubItemRect so that it reports correct
> values, as compared against WinNT on ControlSpy.

Problem is that LISTVIEW_GetSubItemRect is documented to return
same thing for LVIR_LABEL and LVIR_BOUNDS. Of course, incorrect
documentation is known to exist, so as long as you checked it...

However, when we implement things different from the documented
behavior, a clear comment explaining why we deviate is appropriate.
Otherwise, someone might get rid of it in the future. :(

-- 
Dimi.

Re: Listview WM_NOTIFYFORMAT and LVN_GETDISPINFO

[Dimitrie O. Paun]

On November 21, 2002 12:13 pm, Aric Stewart wrote:
> i tried all sorts of variations on the W and A creations to see if i saw
> any difference and I did not.
>
> Also this patch fixes the bug in Outlook...

Yes. And beyond this, it correlates perfectly with the treeview
problems we have been experiencing lately, so it does look like
the 'right' fix.

I'll let you know if a similar fix corrects the treeview issues.

-- 
Dimi.

Re: Listview WM_NOTIFYFORMAT and LVN_GETDISPINFO

[Dimitrie O. Paun]

On November 21, 2002 06:27 am, Dustin Navea wrote:
> Do you think that this patch will fix my treeview problem(s)?  Or should
> the same sort of thing be done to treeview as a test to see if it will?

Yes, the same sort of patch should be done for treeview. I'll try to
do one soon.

-- 
Dimi.

Re: Listview WM_NOTIFYFORMAT and LVN_GETDISPINFO

[Dustin Navea]

On Thu, 2002-11-21 at 11:13, Aric Stewart wrote:
> Yeah it is sort of amazing.
> 
> I have a test program under windows if you would like to see the Visual 
> studio project. It has _UNICODE defined in the project, I create a main 
> window with CreateWindowW Inside that window i do a DialogBoxW. That 
> dialog box has a listview which is OWNERDATA.
> 
> I look at WM_NOTIFYFORMAT and trace and return what is returned by 
> DefWindowProc (which conforms to wine and the docs by returning NFR_UNICODE)
> 
> then watching the notifies come in when i SetItemCount i see only the A 
> GetDispInfo notify..
> 
> i tried all sorts of variations on the W and A creations to see if i saw 
> any difference and I did not.
> 
> Also this patch fixes the bug in Outlook...
> 
> -aric
>

Dimi,

Do you think that this patch will fix my treeview problem(s)?  Or should
the same sort of thing be done to treeview as a test to see if it will?

-Dustin

Re: Listview WM_NOTIFYFORMAT and LVN_GETDISPINFO

[Aric Stewart]

Yeah it is sort of amazing.

I have a test program under windows if you would like to see the Visual 
studio project. It has _UNICODE defined in the project, I create a main 
window with CreateWindowW Inside that window i do a DialogBoxW. That 
dialog box has a listview which is OWNERDATA.

I look at WM_NOTIFYFORMAT and trace and return what is returned by 
DefWindowProc (which conforms to wine and the docs by returning NFR_UNICODE)

then watching the notifies come in when i SetItemCount i see only the A 
GetDispInfo notify..

i tried all sorts of variations on the W and A creations to see if i saw 
any difference and I did not.

Also this patch fixes the bug in Outlook...

-aric


Dimitrie O. Paun wrote:
On November 21, 2002 11:33 am, Aric Stewart wrote:


Here is a patch which preserves alot of your structure.
it works to correct my bug in Outlook.



Wow! It's hard to believe this is the case... WTF is this so?
I mean, did you find a reasonable explanation to this behaviour?
Did you have a chance to test with XP (comctrl 6.0)?

Re: Listview WM_NOTIFYFORMAT and LVN_GETDISPINFO

[Dimitrie O. Paun]

On November 21, 2002 11:33 am, Aric Stewart wrote:
> Here is a patch which preserves alot of your structure.
> it works to correct my bug in Outlook.

Wow! It's hard to believe this is the case... WTF is this so?
I mean, did you find a reasonable explanation to this behaviour?
Did you have a chance to test with XP (comctrl 6.0)?

-- 
Dimi.

Re: Listview WM_NOTIFYFORMAT and LVN_GETDISPINFO

[Aric Stewart]

Here is a patch which preserves alot of your structure.
it works to correct my bug in Outlook.

-aric

Dimitrie O. Paun wrote:

On November 21, 2002 10:19 am, Aric Stewart wrote:


  I wondered if you had found a counter example in your own tests, or
if you had just assumed that windows would act rationally. If it was an
assumption then I will happily make a patch that mimic the behavior of
my test program. If you have your own windows test program that shows
other behavior maybe you can send it to me and we can see what is wrong
with my test program.



Actually, I don't have a test for the WM_NOTIFYFORMAT. In fact, I was just
looking at it, trying to compare it to the Treeview case which doesn't work
at the moment, and I think the one in Listview is buggy, at least according
to the documentation. To cut a long story short: yeah, a patch is greatly
appreciated! :)

BTW, this is the problem with the Treeview as well, if I understand 
correctly. It is asked in WM_NOTIFYFORMAT to be Unicode, but when it
does, nothing works. So my question is: when is a control supposed to
be Unicode? WTF is going on here???



Index: dlls/comctl32/listview.c
===
RCS file: /home/wine/wine/dlls/comctl32/listview.c,v
retrieving revision 1.330
diff -u -r1.330 listview.c
--- dlls/comctl32/listview.c18 Nov 2002 19:51:11 -  1.330
+++ dlls/comctl32/listview.c21 Nov 2002 16:30:44 -
@@ -764,8 +764,10 @@
 }
 
 /*
-  Send notification. depends on dispinfoW having same
-  structure as dispinfoA.
+  With testing on Windows 2000 it looks like the notify format
+  has nothing to do with this message. It ALWAYS seems to be
+  in ansi format.
+
   infoPtr : listview struct
   notificationCode : *Unicode* notification code
   pdi : dispinfo structure (can be unicode or ansi)
@@ -774,61 +776,49 @@
 static BOOL notify_dispinfoT(LISTVIEW_INFO *infoPtr, INT notificationCode, 
LPNMLVDISPINFOW pdi, BOOL isW)
 {
 BOOL bResult = FALSE;
-BOOL convertToAnsi = FALSE, convertToUnicode = FALSE;
-INT realNotifCode;
+BOOL convertToAnsi = FALSE;
 INT cchTempBufMax = 0, savCchTextMax = 0;
 LPWSTR pszTempBuf = NULL, savPszText = NULL;
 
 if ((pdi->item.mask & LVIF_TEXT) && is_textT(pdi->item.pszText, isW))
-{
-   convertToAnsi = (isW && infoPtr->notifyFormat == NFR_ANSI);
-convertToUnicode = (!isW && infoPtr->notifyFormat == NFR_UNICODE);
-}
+   convertToAnsi = isW;
 
-if (convertToAnsi || convertToUnicode)
+if (convertToAnsi)
 {
-   if (notificationCode != LVN_GETDISPINFOW)
-   {
-   cchTempBufMax = convertToUnicode ?
-   MultiByteToWideChar(CP_ACP, 0, (LPCSTR)pdi->item.pszText, -1, NULL, 0):
-   WideCharToMultiByte(CP_ACP, 0, pdi->item.pszText, -1, NULL, 0, NULL, 
NULL);
+   if (notificationCode != LVN_GETDISPINFOW)
+   {
+cchTempBufMax = WideCharToMultiByte(CP_ACP, 0, pdi->item.pszText,
+-1, NULL, 0, NULL, NULL);
 }
-   else
-   {
-   cchTempBufMax = pdi->item.cchTextMax;
-   *pdi->item.pszText = 0; /* make sure we don't process garbage */
-   }
+   else
+   {
+   cchTempBufMax = pdi->item.cchTextMax;
+   *pdi->item.pszText = 0; /* make sure we don't process garbage */
+   }
 
-pszTempBuf = HeapAlloc(GetProcessHeap(), 0,
-(convertToUnicode ? sizeof(WCHAR) : sizeof(CHAR)) * cchTempBufMax);
+pszTempBuf = HeapAlloc(GetProcessHeap(), 0, sizeof(CHAR) *
+   cchTempBufMax);
 if (!pszTempBuf) return FALSE;
-if (convertToUnicode)
-   MultiByteToWideChar(CP_ACP, 0, (LPCSTR)pdi->item.pszText, -1,
-pszTempBuf, cchTempBufMax);
-else
-WideCharToMultiByte(CP_ACP, 0, pdi->item.pszText, -1, (LPSTR) pszTempBuf,
-cchTempBufMax, NULL, NULL);
+
+WideCharToMultiByte(CP_ACP, 0, pdi->item.pszText, -1, (LPSTR)
+ pszTempBuf, cchTempBufMax, NULL, NULL);
+
 savCchTextMax = pdi->item.cchTextMax;
 savPszText = pdi->item.pszText;
 pdi->item.pszText = pszTempBuf;
 pdi->item.cchTextMax = cchTempBufMax;
 }
 
-if (infoPtr->notifyFormat == NFR_ANSI)
-   realNotifCode = get_ansi_notification(notificationCode);
-else
-   realNotifCode = notificationCode;
-TRACE(" pdi->item=%s\n", debuglvitem_t(&pdi->item, infoPtr->notifyFormat != 
NFR_ANSI));
-bResult = notify_hdr(infoPtr, realNotifCode, (LPNMHDR)pdi);
+TRACE(" pdi->item=%s\n", debuglvitem_t(&pdi->item, infoPtr->notifyFormat !=
+   NFR_ANSI));
+
+bResult = notify_hdr(infoPtr, get_ansi_notification(notificationCode),
+(LPNMHDR)pdi);
 
-if (convertToUnicode || convertToAnsi)
+if (convertToAnsi)
 

Re: Listview WM_NOTIFYFORMAT and LVN_GETDISPINFO

[Dimitrie O. Paun]

On November 21, 2002 10:19 am, Aric Stewart wrote:
>I wondered if you had found a counter example in your own tests, or
> if you had just assumed that windows would act rationally. If it was an
> assumption then I will happily make a patch that mimic the behavior of
> my test program. If you have your own windows test program that shows
> other behavior maybe you can send it to me and we can see what is wrong
> with my test program.

Actually, I don't have a test for the WM_NOTIFYFORMAT. In fact, I was just
looking at it, trying to compare it to the Treeview case which doesn't work
at the moment, and I think the one in Listview is buggy, at least according
to the documentation. To cut a long story short: yeah, a patch is greatly
appreciated! :)

BTW, this is the problem with the Treeview as well, if I understand 
correctly. It is asked in WM_NOTIFYFORMAT to be Unicode, but when it
does, nothing works. So my question is: when is a control supposed to
be Unicode? WTF is going on here???

-- 
Dimi.

Re: listview: last column problem

[Rein Klazes]

On Wed, 30 Oct 2002 14:21:13 -0500, you wrote:

> On October 30, 2002 02:01 pm, Rein Klazes wrote:
> > Do you see any objections removing the test and error message?
> 
> Good catch. Please try this patch:
> 
> Index: dlls/comctl32/listview.c
> ===
> RCS file: /var/cvs/wine/dlls/comctl32/listview.c,v
> retrieving revision 1.325
> diff -u -r1.325 listview.c
> --- dlls/comctl32/listview.c  28 Oct 2002 21:21:42 -  1.325
> +++ dlls/comctl32/listview.c  30 Oct 2002 19:19:35 -
> @@ -6044,7 +6044,8 @@
>  
>  TRACE("(nColumn=%d, lpColumn=%s, isW=%d)\n", nColumn, debuglvcolumn_t(lpColumn, 
>isW), isW);
>  
> -if (!lpColumn || nColumn < 0 || nColumn > infoPtr->hdpaColumns->nItemCount) 
>return -1;
> +if (!lpColumn || nColumn < 0) return -1;
> +nColumn = min(nColumn, infoPtr->hdpaColumns->nItemCount);
>  
>  ZeroMemory(&hdi, sizeof(HDITEMW));
>  column_fill_hditem(infoPtr, &hdi, nColumn, lpColumn, isW);


Works fine.

Rein.
-- 
Rein Klazes
[EMAIL PROTECTED]

Re: listview: last column problem

[Dimitrie O. Paun]

On October 30, 2002 02:01 pm, Rein Klazes wrote:
> Do you see any objections removing the test and error message?

Good catch. Please try this patch:

Index: dlls/comctl32/listview.c
===
RCS file: /var/cvs/wine/dlls/comctl32/listview.c,v
retrieving revision 1.325
diff -u -r1.325 listview.c
--- dlls/comctl32/listview.c28 Oct 2002 21:21:42 -  1.325
+++ dlls/comctl32/listview.c30 Oct 2002 19:19:35 -
@@ -6044,7 +6044,8 @@
 
 TRACE("(nColumn=%d, lpColumn=%s, isW=%d)\n", nColumn, debuglvcolumn_t(lpColumn, 
isW), isW);
 
-if (!lpColumn || nColumn < 0 || nColumn > infoPtr->hdpaColumns->nItemCount) 
return -1;
+if (!lpColumn || nColumn < 0) return -1;
+nColumn = min(nColumn, infoPtr->hdpaColumns->nItemCount);
 
 ZeroMemory(&hdi, sizeof(HDITEMW));
 column_fill_hditem(infoPtr, &hdi, nColumn, lpColumn, isW);


-- 
Dimi.

Re: Listview Z8

[Shachar Shemesh]

Now you are touching on subjects tender to my purpose on this list :-)

Dimi wouldn't have to change anything. A BiDi aware engine which is 
complient enough (i.e. - not what we currently have in Wine)-: will 
display a logical aleph followed by a "1" as an aleph followed by a 1 
RTL (i.e. - the 1 will be on the aleph's left). There is a whole 
discussion here, but I'm afraid it is somewhat off topic for this 
presumably amusing thread. Contact me off list if you want to hear more.

As for studying Hebrew - בהצלחה. They say it's a difficult language to 
learn (I wouldn't really know, of course).

   Sh.


Jeff Smith wrote:

(note that I am presently at a computer *not* set up for i18n)

I think Hebrew was made to go RTL just to give programmers headaches.
Actually, I'm trying to learn Hebrew, and I keep catching myself
trying to write it LTR.  Now if Dimi went to the Hebrew alephbet,
would he have to change from Z1, Z2,... to 1{aleph}, 2{aleph},...

 -- Jeff S.



From: Shachar Shemesh <[EMAIL PROTECTED]>

That's why I included them here, so you can copy and paste

Just remeber to set your locale to either Iso-8859-8 or UTF-8, or 
you'll lose the special chars. Even more tricky, if your email client 
supports BiDi (Your'e using kmail, but only the one that came with 
KDE-3 did, and I don't know what version that was), then the first 
character, "א", is on the *right* `-)

   Shachar


Dimitrie O. Paun wrote:

On October 27, 2002 12:14 pm, Shachar Shemesh wrote:



"אבגדהוזחטיכלמנסעפצקרשת". Very useful `-)




Very cool man, but, ..., hmm, ..., I don't have a Hebrew keyboard. ;)





_
Get a speedy connection with MSN Broadband.? Join now! 
http://resourcecenter.msn.com/access/plans/freeactivation.asp

Re: Listview Z8

[Jeff Smith]

(note that I am presently at a computer *not* set up for i18n)

I think Hebrew was made to go RTL just to give programmers headaches.
Actually, I'm trying to learn Hebrew, and I keep catching myself
trying to write it LTR.  Now if Dimi went to the Hebrew alephbet,
would he have to change from Z1, Z2,... to 1{aleph}, 2{aleph},...

 -- Jeff S.



From: Shachar Shemesh <[EMAIL PROTECTED]>

That's why I included them here, so you can copy and paste

Just remeber to set your locale to either Iso-8859-8 or UTF-8, or you'll 
lose the special chars. Even more tricky, if your email client supports 
BiDi (Your'e using kmail, but only the one that came with KDE-3 did, and I 
don't know what version that was), then the first character, "א", is on 
the *right* `-)

   Shachar


Dimitrie O. Paun wrote:

On October 27, 2002 12:14 pm, Shachar Shemesh wrote:



"אבגדהוזחטיכלמנסעפצקרשת". Very useful `-)




Very cool man, but, ..., hmm, ..., I don't have a Hebrew keyboard. ;)



_
Get a speedy connection with MSN Broadband.  Join now! 
http://resourcecenter.msn.com/access/plans/freeactivation.asp

Re: Listview Z8

[Shachar Shemesh]

That's why I included them here, so you can copy and paste

Just remeber to set your locale to either Iso-8859-8 or UTF-8, or you'll 
lose the special chars. Even more tricky, if your email client supports 
BiDi (Your'e using kmail, but only the one that came with KDE-3 did, and 
I don't know what version that was), then the first character, "א", is 
on the *right* `-)

   Shachar


Dimitrie O. Paun wrote:

On October 27, 2002 12:14 pm, Shachar Shemesh wrote:
 

"אבגדהוזחטיכלמנסעפצקרשת". Very useful `-)
   


Very cool man, but, ..., hmm, ..., I don't have a Hebrew keyboard. ;)

 

Re: Listview Z8

[Jeff Smith]

Actually, I believe Klingon got rejected.  Some junk
about it not being a 'real' language or something.
Try telling that to all the people that speak it
though.  Probably more than some of the other
languages represented in Unicode.

Maybe we should continue through the ASCII character
set: 'X' 'Y' 'Z' '[' '\' ']' '^' '_' ...

-- Jeff S.



From: "David D. Hagood" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]

Andreas Mohr wrote:



What a weak and useless suggestion, this will run out of characters in
no time at all ;-)
Better use Chinese characters !


Bah! You are still weak! Better to use Klingon - I do beleive they've 
reserve some Unicode space for them!

_
Surf the Web without missing calls! Get MSN Broadband.  
http://resourcecenter.msn.com/access/plans/freeactivation.asp

Re: Listview Z8

[David D. Hagood]

Andreas Mohr wrote:



What a weak and useless suggestion, this will run out of characters in
no time at all ;-)
Better use Chinese characters !


Bah! You are still weak! Better to use Klingon - I do beleive they've 
reserve some Unicode space for them!

Re: Listview Z8

[Andreas Mohr]

On Sun, Oct 27, 2002 at 07:14:41PM +0200, Shachar Shemesh wrote:
> I can offer you the Hebrew alphabet. Except "à" (Aleph), which was used 
> to indicate the various infiinity levels, there are 21 brand new, never 
> before used, ready for your viewing pleasure letters (the number grows 
> to 26+aleph=27 if you want to count the different forms a letter may 
> take, depending on it's place in the word).
> 
> "àáâãäåæçèéëìîðñòôö÷øùú". Very useful `-)
What a weak and useless suggestion, this will run out of characters in
no time at all ;-)
Better use Chinese characters !
And if even those run out, then use Complex Chinese instead of Simplified
Chinese ;-))

-- 
The Declaration of Software Freedom:
http://freedevelopers.net/freedomdec/index.php

Re: Listview Z8

[Dan de Haan]

That's right. And we don't know what's going to happen, it's
uncharted territory. So if you have listview problems, speak
now!!! :)

 


The new listview patches cause WinMZ 3.3 to be unsable.  While the 
listview is being filled, you can it sort of flash some of the trext 
that is supposed to be there and then go black.  If you scroll up and 
down you cvan see patrs of the text.

There is a screenshot here: http://www.zeron.ca/~dan/wine/winmx1.png

All the listview patches up to Z8 have been applied.

   -Dan

Re: Listview Z8

[Dimitrie O. Paun]

On October 27, 2002 12:14 pm, Shachar Shemesh wrote:
> "àáâãäåæçèéëìîðñòôö÷øùú". Very useful `-)

Very cool man, but, ..., hmm, ..., I don't have a Hebrew keyboard. ;)

-- 
Dimi.

Re: Listview Z8

[Shachar Shemesh]

I can offer you the Hebrew alphabet. Except "à" (Aleph), which was used 
to indicate the various infiinity levels, there are 21 brand new, never 
before used, ready for your viewing pleasure letters (the number grows 
to 26+aleph=27 if you want to count the different forms a letter may 
take, depending on it's place in the word).

"àáâãäåæçèéëìîðñòôö÷øùú". Very useful `-)

   Shachar


Dimitrie O. Paun wrote:

On October 27, 2002 11:28 am, Dimitrie O. Paun wrote:
 

ChangeLog
 Mark immutable objects as const. Fix inconsisten *-style.
   


This one, of course, is Z7, not Z8. Hmm, now I have problems
with digits, on top of the alphabet... And NO, we used to do
a _lot_ of math in Romania! :P

 

Re: Listview Z8

[Dimitrie O. Paun]

On October 27, 2002 12:05 pm, Shachar Shemesh wrote:
> Oh my god!!! he is running out of alphabet letters!!! ;-)

That's right. And we don't know what's going to happen, it's
uncharted territory. So if you have listview problems, speak
now!!! :)

-- 
Dimi.

Re: Listview Z8

[Shachar Shemesh]

Oh my god!!! he is running out of alphabet letters!!! ;-)

   Shachar

Dimitrie O. Paun wrote:


ChangeLog
 Mark immutable objects as const. Fix inconsisten *-style.

--- dlls/comctl32/listview.c.Z6	2002-10-27 10:29:52.0 -0500
+++ dlls/comctl32/listview.c	2002-10-27 11:24:45.0 -0500
@@ -370,7 +370,7 @@
static void LISTVIEW_GetOrigin(LISTVIEW_INFO *, LPPOINT);
static BOOL LISTVIEW_GetViewRect(LISTVIEW_INFO *, LPRECT);
static void LISTVIEW_SetGroupSelection(LISTVIEW_INFO *, INT);
-static BOOL LISTVIEW_SetItemT(LISTVIEW_INFO *, LPLVITEMW, BOOL);
+static BOOL LISTVIEW_SetItemT(LISTVIEW_INFO *, const LVITEMW *, BOOL);
static void LISTVIEW_UpdateScroll(LISTVIEW_INFO *);
static void LISTVIEW_SetSelection(LISTVIEW_INFO *, INT);
static void LISTVIEW_UpdateSize(LISTVIEW_INFO *);
@@ -380,7 +380,7 @@
static INT LISTVIEW_GetStringWidthT(LISTVIEW_INFO *, LPCWSTR, BOOL);
static BOOL LISTVIEW_KeySelection(LISTVIEW_INFO *, INT);
static UINT LISTVIEW_GetItemState(LISTVIEW_INFO *, INT, UINT);
-static BOOL LISTVIEW_SetItemState(LISTVIEW_INFO *, INT, LPLVITEMW);
+static BOOL LISTVIEW_SetItemState(LISTVIEW_INFO *, INT, const LVITEMW *);
static LRESULT LISTVIEW_VScroll(LISTVIEW_INFO *, INT, INT, HWND);
static LRESULT LISTVIEW_HScroll(LISTVIEW_INFO *, INT, INT, HWND);
static INT LISTVIEW_GetTopIndex(LISTVIEW_INFO *);
@@ -469,7 +469,7 @@
/*
 * compares a Unicode to a Unicode/ANSI text string
 */
-static inline int textcmpWT(LPWSTR aw, LPWSTR bt, BOOL isW)
+static inline int textcmpWT(LPCWSTR aw, LPCWSTR bt, BOOL isW)
{
if (!aw) return bt ? -1 : 0;
if (!bt) return aw ? 1 : 0;
@@ -517,7 +517,7 @@
return buffers[index++ % DEBUG_BUFFERS];
}

-static inline char* debugrange(const RANGE* lprng)
+static inline char* debugrange(const RANGE *lprng)
{
if (lprng) 
{
@@ -527,7 +527,7 @@
} else return "(null)";
}

-static inline char* debugpoint(const POINT* lppt)
+static inline char* debugpoint(const POINT *lppt)
{
if (lppt) 
{
@@ -537,7 +537,7 @@
} else return "(null)";
}

-static inline char* debugrect(const RECT* rect)
+static inline char* debugrect(const RECT *rect)
{
if (rect) 
{
@@ -580,7 +580,7 @@
return text;
} 

-static char* debugnmlistview(LPNMLISTVIEW plvnm)
+static char* debugnmlistview(const NMLISTVIEW *plvnm)
{
if (plvnm)
{
@@ -593,7 +593,7 @@
} else return "(null)";
}

-static char* debuglvitem_t(LPLVITEMW lpLVItem, BOOL isW)
+static char* debuglvitem_t(const LVITEMW *lpLVItem, BOOL isW)
{
char* buf = debug_getbuf(), *text = buf;
int len, size = DEBUG_BUFFER_SIZE;
@@ -629,7 +629,7 @@
return text;
}

-static char* debuglvcolumn_t(LPLVCOLUMNW lpColumn, BOOL isW)
+static char* debuglvcolumn_t(const LVCOLUMNW *lpColumn, BOOL isW)
{
char* buf = debug_getbuf(), *text = buf;
int len, size = DEBUG_BUFFER_SIZE;
@@ -670,7 +670,7 @@
}


-static char* debuglvhittestinfo(LPLVHITTESTINFO lpht)
+static char* debuglvhittestinfo(const LVHITTESTINFO *lpht)
{
if (lpht) 
{
@@ -817,7 +817,7 @@
return bResult;
}

-static void customdraw_fill(NMLVCUSTOMDRAW *lpnmlvcd, LISTVIEW_INFO *infoPtr, HDC hdc, LPRECT rcBounds)
+static void customdraw_fill(NMLVCUSTOMDRAW *lpnmlvcd, LISTVIEW_INFO *infoPtr, HDC hdc, const RECT *rcBounds)
{
ZeroMemory(lpnmlvcd, sizeof(NMLVCUSTOMDRAW));
lpnmlvcd->nmcd.hdc = hdc;
@@ -1045,7 +1045,7 @@
/***
 * Creates an iterator over the items which intersect lprc.
 */
-static BOOL iterator_frameditems(ITERATOR* i, LISTVIEW_INFO* infoPtr, const RECT* lprc)
+static BOOL iterator_frameditems(ITERATOR* i, LISTVIEW_INFO* infoPtr, const RECT *lprc)
{
UINT uView = infoPtr->dwStyle & LVS_TYPEMASK;
RECT frame = *lprc, rcItem, rcTemp;
@@ -1130,7 +1130,7 @@
/***
 * Creates an iterator over the items which intersect the visible region of hdc.
 */
-static BOOL iterator_visibleitems(ITERATOR* i, LISTVIEW_INFO *infoPtr, HDC  hdc)
+static BOOL iterator_visibleitems(ITERATOR *i, LISTVIEW_INFO *infoPtr, HDC  hdc)
{
POINT Origin, Position;
RECT rcItem, rcClip;
@@ -1705,7 +1705,7 @@
 * RETURN:
 *   None.
 */
-static void LISTVIEW_GetItemMetrics(LISTVIEW_INFO *infoPtr, LVITEMW *lpLVItem,
+static void LISTVIEW_GetItemMetrics(LISTVIEW_INFO *infoPtr, const LVITEMW *lpLVItem,
LPRECT lprcBox, LPRECT lprcState, 
LPRECT lprcIcon, LPRECT lprcLabel)
{
@@ -2018,7 +2018,7 @@
 *   Success: TRUE
 *   Failure: FALSE
 */
-static BOOL LISTVIEW_MoveIconTo(LISTVIEW_INFO *infoPtr, INT nItem, LPPOINT lppt, BOOL isNew)
+static BOOL LISTVIEW_MoveIconTo(LISTVIEW_INFO *infoPtr, INT nItem, const POINT *lppt, BOOL isNew)
{
POINT old;

@@ -3039,7 +3039,7 @@
/***
 * Tests wheather the item is assignable to a list with style lStyle 
 */
-static inline BOOL is_assignable_item(LPLVITEMW lpLVItem, LONG lStyle)
+static inline BOOL is_assignable_item(const LVITEMW *lpLVItem, LONG lStyle)
{
if ( (lpLVItem->mask & LVIF_TEXT) && 
	(lpLVItem->pszText == LPSTR_TEXTCALLBACKW) &&
@@ -3064,7 +3064,7 @@
 *   SUCCESS : TRUE
 *   

Re: Listview Z8

[Dimitrie O. Paun]

On October 27, 2002 11:28 am, Dimitrie O. Paun wrote:
> ChangeLog
>   Mark immutable objects as const. Fix inconsisten *-style.

This one, of course, is Z7, not Z8. Hmm, now I have problems
with digits, on top of the alphabet... And NO, we used to do
a _lot_ of math in Romania! :P

-- 
Dimi.

Re: Listview Z0 (roll-up patch)

[David D. Hagood]

Well, a cvs up -C and rebuild, and things are find here at home. I'll 
have to see what is up with my machine at work Monday...

Re: Listview Z0 (roll-up patch)

[David D. Hagood]

Dimitrie O. Paun wrote:



The algorithm has been: start a new series when Alexandre has committed
the previous one. So, for example, because I've started the Z-series
last night, that means that Alexandre already committed the X-series.
So the only outstanding patch not committed to CVS is Z0. I don't see a
need for a roll-up patch ;)




That helps, but also leaves me with a conundrum - when I do a CVS update 
on my machine at work, and rebuild wine (make clean, make depend, make, 
su, wipe wine directories in /usr/local, make install, exit, run Mng4) I 
get the listview crash on "Along the way". I haven't been updating my 
machine at home, which had the patches applied, so I thought the patches 
were not in CVS.

I will do a cvs up -C and rebuild here at home, and see what I get.

Re: Listview Z0 (roll-up patch)

[Dimitrie O. Paun]

On October 25, 2002 04:31 pm, Michael Stefaniuc wrote:

> Well a "Y" is pretty much not used in the romanian language :)

Thank you Michael, this is it ;) Come to think of it, it's not
used at all... Honestly, I also hated that I to learn the alphabet,
and the multiplication table! :)))

-- 
Dimi.

Re: Listview Z0 (roll-up patch)

[Michael Stefaniuc]

On Fri, Oct 25, 2002 at 02:54:32PM -0400, Dimitrie O. Paun wrote:
> On October 25, 2002 02:55 pm, Francois Gouget wrote:
> > Hmmm, what happened to the Y series?
> 
> Doh! Now the cat is out of the bag: I don't know my
> alphabet!!! Oh, man...
> 
> Y: Y use Y?
Well a "Y" is pretty much not used in the romanian language :)

bye
michael
-- 
Michael Stefaniuc   Tel.: +49-711-96437-199
System Administration   Fax.: +49-711-96437-111
Red Hat GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart



msg12759/pgp0.pgp
Description: PGP signature

Re: Listview Z0 (roll-up patch)

[Francois Gouget]

On Fri, 25 Oct 2002, Dimitrie O. Paun wrote:
[...]
> The algorithm has been: start a new series when Alexandre has committed
> the previous one. So, for example, because I've started the Z-series
> last night, that means that Alexandre already committed the X-series.

Hmmm, what happened to the Y series?
You should conserve letters, they are pretty scarce :-)

-- 
Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/
May your Tongue stick to the Roof of your Mouth with the Force of a Thousand Caramels.

Re: Listview Z0 (roll-up patch)

[Dimitrie O. Paun]

On October 25, 2002 02:55 pm, Francois Gouget wrote:
> Hmmm, what happened to the Y series?

Doh! Now the cat is out of the bag: I don't know my
alphabet!!! Oh, man...

Y: Y use Y?

-- 
Dimi.

Re: Listview Z0 (roll-up patch)

[Dimitrie O. Paun]

On October 25, 2002 07:38 am, David D. Hagood wrote:
> For those of us who are a little behind on the patches, would it be
> possible to get a roll-up patch of all diffs from the CVS MAIN branch?
> Also, what is the status of CVS vs. the patches - what patches have been
> applied?

The algorithm has been: start a new series when Alexandre has committed
the previous one. So, for example, because I've started the Z-series
last night, that means that Alexandre already committed the X-series.
So the only outstanding patch not committed to CVS is Z0. I don't see a
need for a roll-up patch ;)


-- 
Dimi.

Re: Listview Z0 (roll-up patch)

[David D. Hagood]

For those of us who are a little behind on the patches, would it be 
possible to get a roll-up patch of all diffs from the CVS MAIN branch? 
Also, what is the status of CVS vs. the patches - what patches have been 
applied?

Re: Listview V15

[Bobby Bingham]

On Mon, Oct 21, 2002 at 04:29:42PM -0400, Dimitrie O. Paun wrote:
> > hmmm ... how about "LVN_BEGINFRAG, LVN_ENDDRAG"
> 
> How about you read the documentation :)
> 

ooops .. sorry ;-)

--
Bobby Bingham

Re: Listview V15

[Dimitrie O. Paun]

On October 21, 2002 04:20 pm, Bobby Bingham wrote:
> > + *   -- LVIS_ACTIVATING (not currently supported my comctl32.dll version
> > 6.0)
>
> you mean "by" comctl32.dll version 6.0 ?

;) indeed.

> > + *   -- LVN_BEGINDRAG, LVN_BEGINRDRAG
>
> hmmm ... how about "LVN_BEGINFRAG, LVN_ENDDRAG"

How about you read the documentation :)

-- 
Dimi.

Re: Listview regression

[Dimitrie O. Paun]

On October 20, 2002 09:35 am, David D. Hagood wrote:
> Better, but not all the way. It doesn't crash, and *some* of the items
> show up in the "along the way" box, but not all.

Please try V4, it should fix it. If not, a trace is appreciated,
as always. :)

-- 
Dimi.

Re: Listview regression

[David D. Hagood]

Dimitrie O. Paun wrote:


On October 19, 2002 11:34 am, David D. Hagood wrote:

>Second, when I do the "Along the way", the program cores out.


This one's tricky. Can you please retest (it will still crash),
and send me the log, after applying thing patch:


The patch is not applying - Is this supposed to apply to the current 
CVS, or to the current patch set (including V0)?

Re: Listview regression

[Dimitrie O. Paun]

On October 19, 2002 11:34 am, David D. Hagood wrote:
> Second, when I do the "Along the way", the program cores out.

This one's tricky. Can you please retest (it will still crash),
and send me the log, after applying thing patch:

--- dlls/comctl32/listview.c.V0 Sat Oct 19 17:49:34 2002
+++ dlls/comctl32/listview.cSat Oct 19 18:21:55 2002
@@ -5678,12 +5678,14 @@
 is_sorted = (lStyle & (LVS_SORTASCENDING | LVS_SORTDESCENDING)) &&
!(lStyle & LVS_OWNERDRAWFIXED) && (LPSTR_TEXTCALLBACKW != 
lpLVItem->pszText);

-nItem = DPA_InsertPtr( infoPtr->hdpaItems,
-  is_sorted ? infoPtr->nItemCount + 1 : lpLVItem->iItem,
-  hdpaSubItems );
+nItem = is_sorted ? infoPtr->nItemCount + 1 : lpLVItem->iItem;
+TRACE(" inserting at %d, sorted=%d, count=%d, iItem=%d\n", nItem, is_sorted, 
+infoPtr->nItemCount, lpLVItem->iItem);
+nItem = DPA_InsertPtr( infoPtr->hdpaItems, nItem, hdpaSubItems );
+TRACE(" result of insert is %d\n", nItem);
 if (nItem == -1) goto fail;
 /* the array may be sparsly populated, we can't just increment the count here */
 infoPtr->nItemCount = infoPtr->hdpaItems->nItemCount;
+TRACE(" item count is %d\n", infoPtr->nItemCount);

 /* set the item attributes */
 if (!set_main_item(infoPtr, lpLVItem, TRUE, isW, &has_changed)) goto undo;


-- 
Dimi.

Re: Listview regression

[Dimitrie O. Paun]

On October 19, 2002 11:34 am, David D. Hagood wrote:
> I've just applied/built/installed/tested the U series patches, and I
> have 2 regressions in the AAA MapNGo program:
>
> First, the first column of the directions window (which shows the type
> of road) is missing.

U3 should fix this, please give it a try.

> Second, when I do the "Along the way", the program cores out.

That's not a regression, it's a showcased bug! :))) I'll look into it.


-- 
Dimi.

Re: Listview U0

[Dimitrie O. Paun]

On October 19, 2002 03:45 am, Andreas Mohr wrote:
> On Sat, Oct 19, 2002 at 02:55:44AM -0400, Dimitrie O. Paun wrote:
> > ChangeLog
> >   U0: Better report mode.
>
> Hmm, I guess you better reach listview completion rather soon,
> otherwise you'll slowly run out of patch letters... ;-)))

I know, but there's no end in sight! :)))

> In other news: thanks a bunch for this incredible work !

You're most welcome! Like any OSS contributor, I certainly
enjoy that my efforts are not in vain. It's my little token
of appreciation for all the amazing work that everybody is
putting in lately.

But it's 4AM here, so I'll leave it at that... ;)

-- 
Dimi.

Re: Listview U0

[Andreas Mohr]

On Sat, Oct 19, 2002 at 02:55:44AM -0400, Dimitrie O. Paun wrote:
> 
> ChangeLog
>   U0: Better report mode.
Hmm, I guess you better reach listview completion rather soon,
otherwise you'll slowly run out of patch letters... ;-)))

In other news: thanks a bunch for this incredible work !

-- 
Andreas MohrStauferstr. 6, D-71272 Renningen, Germany
Tel. +49 7159 800604http://mohr.de.tt

Re: Listview N5

[Dimitrie O. Paun]

If you haven't checked in N5, please ignore it.
I'll resubmit it when I move all of the custom draw around.

-- 
Dimi.

Re: Listview

[Dimitrie O. Paun]

On October 9, 2002 05:00 am, Rein Klazes wrote:
> > Hm, I guess for that to work, the control must be LVS_OWNERDRAWFIXED,
> > in which case, it's the app that's failing. But since it works on
> > windows...
>
> It even works with wine and native comctl32...

Yeah, I though about it some more -- I think they are using custom draw,
but our is a bit broken now. Will fix. It's a minor nit, though.

> It is more difficult to explain then to see. I try another way:
>
> There are several listview controls in the main windowpane, you can
> select one using a tab control. This should make all the listviews
> exept the one that is at the front tab invisible. They are not: if one
> of the hidden listviews changes, the refresh is painted anyway.

It doesn't sound like a listview problem. More like somethig for
Alexandre to look at .

> - in the left pane you should be able to drag and drop the subscribed
> news groups to re-order them. That does not work.

I haven't looked at all at drag and drop. Not at the top of my TODO list.

> - mouse wheel does not work. It doesn't work with native comctl32
> either, it may not be listview related at all.

Think so to, there is support for it in the code, IIRC.

-- 
Dimi.

Re: Listview

[Rein Klazes]

On Tue, 8 Oct 2002 21:52:44 -0400, you wrote:

> On October 8, 2002 08:46 am, Rein Klazes wrote:
> > I am trying out newsbin. There was a request ("wine ui control
> > hacker?") two months ago on this list to work on this. The program can
> > be downloaded from www.newsbin.com and used for a short trial period.
> > The makers have expressed that the would be willing to donate a
> > license for tyhe purpose to get their program work under wine.
> 
> Can you get me one? I'd like to have another app to test with.

I haven't had contact with them yet (the offer is on their web forum),
but I will ask. In the mean time you can use the program, it is fully
functional for 8 days. Install works fine under wine. Runs fine with
all builtin dlls + native comctl32.

> 
> > - new messages should be highlighted using a green background: that
> > doesn't work
> 
> Hm, I guess for that to work, the control must be LVS_OWNERDRAWFIXED,
> in which case, it's the app that's failing. But since it works on 
> windows...

It even works with wine and native comctl32...

> > Perhaps not a listview bug but:
> >
> > - there are several listviews for messages, messages selected for
> > download, downloaded messages amd failed messages. With tabs these can
> > be veiwed. If one listview is updated it updates regardless of the
> > selected tab.
> 
> Not sure I follow this one...

It is more difficult to explain then to see. I try another way:

There are several listview controls in the main windowpane, you can
select one using a tab control. This should make all the listviews
exept the one that is at the front tab invisible. They are not: if one
of the hidden listviews changes, the refresh is painted anyway.

> 
> Thanks for the info! Bug reports are always welcomed.

Two more things:

- in the left pane you should be able to drag and drop the subscribed
news groups to re-order them. That does not work.

- mouse wheel does not work. It doesn't work with native comctl32
either, it may not be listview related at all.

Rein.
-- 
Rein Klazes
[EMAIL PROTECTED]

Re: Listview

[Dimitrie O. Paun]

On October 8, 2002 08:46 am, Rein Klazes wrote:
> I am trying out newsbin. There was a request ("wine ui control
> hacker?") two months ago on this list to work on this. The program can
> be downloaded from www.newsbin.com and used for a short trial period.
> The makers have expressed that the would be willing to donate a
> license for tyhe purpose to get their program work under wine.

Can you get me one? I'd like to have another app to test with.

> Indeed the changes in the last weeks have improved things considerable.

Excellent!

> At this moment (current cvs) the biggest problems are:
>
> - only the first column displays any text

That's strange. In LVS_REPORT mode, I guess? That works very well
now, I'm very curious why it doesn't in your case.

> - new messages should be highlighted using a green background: that
> doesn't work

Hm, I guess for that to work, the control must be LVS_OWNERDRAWFIXED,
in which case, it's the app that's failing. But since it works on 
windows...

> - during filling the listview the screen keeps updating.

Yes, I've added a bunch of FIXMEs to eliminate all those screen 
Invalidates, when we can do better. Now it's just a matter of
implementing it. :)

> Perhaps not a listview bug but:
>
> - there are several listviews for messages, messages selected for
> download, downloaded messages amd failed messages. With tabs these can
> be veiwed. If one listview is updated it updates regardless of the
> selected tab.

Not sure I follow this one...

Thanks for the info! Bug reports are always welcomed.

-- 
Dimi.

Re: Listview

[Rein Klazes]

On Thu, 3 Oct 2002 03:03:56 -0400, you wrote:


> If you are experience problems with the listview, I'd like to hear
> from you. If you want to help, some test cases will help quite a bit.

I am trying out newsbin. There was a request ("wine ui control
hacker?") two months ago on this list to work on this. The program can
be downloaded from www.newsbin.com and used for a short trial period.
The makers have expressed that the would be willing to donate a
license for tyhe purpose to get their program work under wine. 

Indeed the changes in the last weeks have improved things
considerable. At this moment (current cvs) the biggest problems are:

- only the first column displays any text
- new messages should be highlighted using a green background: that
doesn't work
- during filling the listview the screen keeps updating. 


Perhaps not a listview bug but:

- there are several listviews for messages, messages selected for
download, downloaded messages amd failed messages. With tabs these can
be veiwed. If one listview is updated it updates regardless of the
selected tab. 

Rein.
-- 
Rein Klazes
[EMAIL PROTECTED]

Re: Listview L10

[Dimitrie O. Paun]

On October 7, 2002 07:35 pm, Alexandre Julliard wrote:
> Yes I'm seeing this too. The following patch fixes it for me, but I
> guess that line was added for a reason...

Braindamage. Thanks for spotting it. Should be:

Index: dlls/comctl32/listview.c
===
RCS file: /opt/cvs-commit/wine/dlls/comctl32/listview.c,v
retrieving revision 1.186
diff -u -r1.186 listview.c
--- dlls/comctl32/listview.c7 Oct 2002 22:43:42 -   1.186
+++ dlls/comctl32/listview.c7 Oct 2002 23:34:11 -
@@ -596,7 +596,6 @@
else
{
cchTempBufMax = pdi->item.cchTextMax;
-   pdi->item.pszText = 0; /* make sure we don't process garbage */
+   *pdi->item.pszText = 0; /* make sure we don't process garbage */
}
 pszTempBuf = HeapAlloc(GetProcessHeap(), 0,

I'll include the fix in the next set of patches.

-- 
Dimi.

Re: Listview L10

[Alexandre Julliard]

Paul Rupe <[EMAIL PROTECTED]> writes:

> One thing I noticed is that File Open/Save As dialogs in any app now show 
> only icons (the filenames are all blank).  I think this must have happened 
> somewhere in the L-series of patches, but I haven't delved in to figure out 
> which one yet.

Yes I'm seeing this too. The following patch fixes it for me, but I
guess that line was added for a reason...

Index: dlls/comctl32/listview.c
===
RCS file: /opt/cvs-commit/wine/dlls/comctl32/listview.c,v
retrieving revision 1.186
diff -u -r1.186 listview.c
--- dlls/comctl32/listview.c7 Oct 2002 22:43:42 -   1.186
+++ dlls/comctl32/listview.c7 Oct 2002 23:34:11 -
@@ -596,7 +596,6 @@
else
{
cchTempBufMax = pdi->item.cchTextMax;
-   pdi->item.pszText = 0; /* make sure we don't process garbage */
}
 
 pszTempBuf = HeapAlloc(GetProcessHeap(), 0,

-- 
Alexandre Julliard
[EMAIL PROTECTED]

Re: Listview L10

[Paul Rupe]

On 07 Oct 2002, [EMAIL PROTECTED] wrote:

> This one fixes a lot of nasty bugs. It also fixes Xnews,
> among other things.

Yeah, it works great now.  Cool. :)

> This one should bring the listview to a decent state.
> I am interested to hear about outstanding problems.

One thing I noticed is that File Open/Save As dialogs in any app now show 
only icons (the filenames are all blank).  I think this must have happened 
somewhere in the L-series of patches, but I haven't delved in to figure out 
which one yet.


-- 
Paul Rupe"She smiled, in the end."
p r u p e @ m y r e a l b o x . c o m

| Oppose government police-ware on your PC!
| Stop the Consumer Broadband and Digital Television Promotion Act!
| 

Re: Listview L2

[Dimitrie O. Paun]

On October 7, 2002 11:13 am, Paul Rupe wrote:
> Highlighting one and hitting Enter gives me an error from the app "List
> index (-1) out of bounds," suggesting that it doesn't know that anything is
> focused/selected.

I know, the rectangle handling are getting a well deserved, and much 
required cleanup. Patch is in the works.

-- 
Dimi.

Re: Listview L2

[Paul Rupe]

On 06 Oct 2002, [EMAIL PROTECTED] wrote:

> Another rounds of cleanups
> 
> ChangeLog
>   -- Cleanup of the way we maintain/lookup the item count
>   -- Rename GetItemWidth to CalculateMaxWidth
>   -- Misc trivial changes.

It looks like this one breaks Xnews again.  With CVS+L0+L1+L2+my patch, the 
listviews all display as blank.  A later patch adds a missing line 
"infoPtr->nItemCount = nItems;" in LISTVIEW_SetItemCount.  This fixes the 
display problem, but I am still unable to open any newsgroups.  
Highlighting one and hitting Enter gives me an error from the app "List 
index (-1) out of bounds," suggesting that it doesn't know that anything is 
focused/selected.

L0 and L1 appear to be fine, but L2-L8 all have this behavior.


-- 
Paul Rupe"She smiled, in the end."
p r u p e @ m y r e a l b o x . c o m

| Oppose government police-ware on your PC!
| Stop the Consumer Broadband and Digital Television Promotion Act!
| 

Re: Listview

[Dimitrie O. Paun]

On October 4, 2002 01:01 pm, Paul Rupe wrote:
> When I open the 50,000 one the window is blank, but if I hit the "All" 

Excellent! 50,000 -- that's what I'm talking about. The listview should
feel nice, and snappy, even with 10 or 100 times that number of items...

> button at the bottom (toggles between showing all newsgroups and only
> subscribed ones) everything displays fine.  Hit it again to show only 
> subscribed groups and the window goes blank.

Yeah, that's a different problem, probably related to the broken
selection... I'll investigate.

-- 
Dimi.

Re: Listview

[Paul Rupe]

On 04 Oct 2002, [EMAIL PROTECTED] wrote:

> On October 4, 2002 11:10 am, Paul Rupe wrote:
>> If you mean the way it redraws only the part covered by the previous
>> menu and blanks the rest of the window, that is new. 
> 
> Fixed in K6. Give it a try.

That fixed it.  Now I notice another problem.  I have two newsservers set 
up.  One has 26 groups all of which are subscribed.  The other has about 
50,000 with only 13 subscribed.  When I open the 50,000 one the window is 
blank, but if I hit the "All" button at the bottom (toggles between showing 
all newsgroups and only subscribed ones) everything displays fine.  Hit it 
again to show only subscribed groups and the window goes blank.  No amount 
of redrawing seems to fix it this time.  The other server with only 26 
newsgroups is fine either way though.  This looks like a different problem, 
maybe having to do with the presence of a scrollbar or just having such a 
large number of rows.

> We're not gonna feel as fast as Windows, that's that. But we shouldn't
> be dogs either. Please let me know if you find some things sluggish,
> or just plain broken.

Thanks, I'll keep playing with it.


-- 
Paul Rupe"She smiled, in the end."
p r u p e @ m y r e a l b o x . c o m

| Oppose government police-ware on your PC!
| Stop the Consumer Broadband and Digital Television Promotion Act!
| 

Re: Listview

[Dimitrie O. Paun]

On October 4, 2002 11:10 am, Paul Rupe wrote:
> If you mean the way it redraws only the part covered by the previous menu
> and blanks the rest of the window, that is new.

Fixed in K6. Give it a try.

>  Also switching to and from virtual desktops (so the whole app is redrawn) 
> sometimes gives you a blank window, but not always.

Most likely the same bug. Scrolling was also affected.

> I'm eager to see if the performance improves after all your changes too.
> The app draws itself nearly instantaneously in Win98, but has always been
> sluggish in Wine and I could never figure out where the bottleneck was.

I think you'll be pleasantly surprised (once the bugs get fixed :)).

Try this: get listview 1.138. Now, get a lot of newsgroups 
(like All of them), and scroll by continuously pressing the up or down
arrow on the scroll bar. Watch the flickering. Now to the same with
the latest patches. Also, notice how snappy the newsgroup windows shows 
up now. Refreshes should be faster now as well. 

We're not gonna feel as fast as Windows, that's that. But we shouldn't 
be dogs either. Please let me know if you find some things sluggish,
or just plain broken.

-- 
Dimi.

Re: Listview

[Paul Rupe]

On 04 Oct 2002, [EMAIL PROTECTED] wrote:

> Excellent! I've downloaded Xnews, it's perfect. Even more so that it
> stresses the heck out of REPORT mode, which I've worked quite a bit
> to optimize. Do you get the weird drawing problems when you browse
> the menus? Did you encounter it before?

If you mean the way it redraws only the part covered by the previous menu 
and blanks the rest of the window, that is new.  Also switching to and from 
virtual desktops (so the whole app is redrawn) sometimes gives you a blank 
window, but not always.  If you replace just listview.c with version 1.143, 
it should work normally.  It looks like LISTVIEW_InvalidateRect is doing 
the right thing, but something before it blanks the entire window first.  
To better see it, it may help to add this to xnews.ini under [Display]:
  Line1Color=$CFEBF2
  Line2Color=$C6E9CE
I'm eager to see if the performance improves after all your changes too.  
The app draws itself nearly instantaneously in Win98, but has always been 
sluggish in Wine and I could never figure out where the bottleneck was.


-- 
Paul Rupe"She smiled, in the end."
p r u p e @ m y r e a l b o x . c o m

| Oppose government police-ware on your PC!
| Stop the Consumer Broadband and Digital Television Promotion Act!
| 

Re: Listview

[Dimitrie O. Paun]

On October 3, 2002 07:31 pm, Paul Rupe wrote:
> I don't know if you've looked at it already, but I filed this earlier:
> .  Xnews seems to be a pretty
> good app for stressing listview controls in general too.

Excellent! I've downloaded Xnews, it's perfect. Even more so that it
stresses the heck out of REPORT mode, which I've worked quite a bit
to optimize. Do you get the weird drawing problems when you browse
the menus? Did you encounter it before?

I'll look into the selection problem tomorrow. Thanks for the app!

-- 
Dimi.

Re: Listview

[Paul Rupe]

On 03 Oct 2002, [EMAIL PROTECTED] wrote:

> If you are experience problems with the listview, I'd like to hear
> from you. If you want to help, some test cases will help quite a bit.

I don't know if you've looked at it already, but I filed this earlier:  
.  Xnews seems to be a pretty 
good app for stressing listview controls in general too.


-- 
Paul Rupe"She smiled, in the end."
p r u p e @ m y r e a l b o x . c o m

| Oppose government police-ware on your PC!
| Stop the Consumer Broadband and Digital Television Promotion Act!
| 

Re: Listview updates (G0)

[Dimitrie O. Paun]

On September 29, 2002 03:42 pm, Sylvain Petreolle wrote:
> Thus can we consider the result of :
> grep ZeroMemory `find . -name '*.c'` and say "there are probably bugs
> here " ?

I would like to say that that's the case, but I'm a little worried
that will not hold for notification messages. You see, notifications
messages are special in that they go *to* the application, that is,
to code we do not control. And if that code breaks because we push it
to the limit, there's nothing we can do. So I think it's better to
follow the network protocol: be very strict in what we send, and very
liberal in what we receive.

-- 
Dimi.

Re: Listview updates (G0)

[Sylvain Petreolle]

Thus can we consider the result of :
grep ZeroMemory `find . -name '*.c'` and say "there are probably bugs
here " ?

> Which means that notify_dispinfoT is broken. This way we find the
> bug,
> which is my point exactly against adding this zero memory calls. Not
> only
> they bloat the code, making it slower, harder to read, etc., but most
> importantly they hide exactly this types of bugs. We can not go


___
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

Re: Listview updates (G0)

[Dimitrie O. Paun]

On September 28, 2002 03:19 pm, Paul Rupe wrote:
> With these two ZeroMemory calls removed, I'm getting crashes in Xnews due
> to the uninitialized pszText member.  In both cases, it happens when
> LISTVIEW_GetItemT gets the LVITEMW structure and calls notify_dispinfoT

Which means that notify_dispinfoT is broken. This way we find the bug,
which is my point exactly against adding this zero memory calls. Not only
they bloat the code, making it slower, harder to read, etc., but most
importantly they hide exactly this types of bugs. We can not go "easy" on
our functions by zeroing the memory first, because the exact same functions
will be called by app code, and there we have no guarantees that the app
will clear the memory before hand. We have to make our functions work 
properly in the most harsh, documented environment.

Thanks for spotting it. Here's the fix (relative to H0):

--- dlls/comctl32/listview.c.H0 Fri Sep 27 15:58:32 2002
+++ dlls/comctl32/listview.cSat Sep 28 16:43:12 2002
@@ -601,7 +601,7 @@
   else
 realNotifCode = notificationCode;

-  if (is_textT(pdi->item.pszText, isW))
+  if ((pdi->item.mask & LVIF_TEXT) && is_textT(pdi->item.pszText, isW))
   {
 if (isW && infoPtr->notifyFormat == NFR_ANSI)
 convertToAnsi = TRUE;


-- 
Dimi.

Re: Listview updates (G0)

[Paul Rupe]

On 27 Sep 2002, [EMAIL PROTECTED] wrote:

> @@ -3564,7 +3604,6 @@
>  dis.rcItem.bottom = dis.rcItem.top +
>  infoPtr->nItemHeight; OffsetRect(&dis.rcItem, ptOrig.x,
>  0); 
>  
> -ZeroMemory(&item, sizeof(item));
>  item.iItem = nItem;
>   item.iSubItem = 0;
>  item.mask = LVIF_PARAM;

> @@ -,7 +5584,6 @@
>{
>  LVITEMW lvItem;
>  
> -ZeroMemory(&lvItem, sizeof(lvItem));
>  lvItem.mask = LVIF_INDENT;
>  lvItem.iItem = nItem;
>  lvItem.iSubItem = 0;

With these two ZeroMemory calls removed, I'm getting crashes in Xnews due 
to the uninitialized pszText member.  In both cases, it happens when 
LISTVIEW_GetItemT gets the LVITEMW structure and calls notify_dispinfoT 
(line 5186 or so).


-- 
Paul Rupe"She smiled, in the end."
p r u p e @ m y r e a l b o x . c o m

| Oppose government police-ware on your PC!
| Stop the Consumer Broadband and Digital Television Promotion Act!
| 

Re: Listview Large Icon (LVS_ICON) rewrite.

[Guy L. Albertelli]

- Original Message -
From: "Dimitrie O. Paun" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "Guy L. Albertelli" <[EMAIL PROTECTED]>
Sent: Tuesday, September 24, 2002 12:25 AM
Subject: Re: Listview Large Icon (LVS_ICON) rewrite.


> On September 24, 2002 12:07 am, Guy L. Albertelli wrote:
> > This is a major rewrite of the LVS_ICON (large icon) code. Not everything
> > is working correctly yet. Known problems:
> > 1. Focus rectangles are left drawn incorrectly when scrolling window.
>
> I think I know what the problem is, I'll try to fix it.

OK.

> > 2. Background is incorrect for at least Outlook (white instead of grey).
>
> Hm, I don't have Outlook. Any pointers and/or ideas?

It seems to be related to the brush changes. The symptom is that the background is 
white not the grey that is expected.

> > 3. Scrolling in Outlook is not correct.
>
> What's the problem with this one? I might be able to fix it...

Outlook has its own scrolling process (separate top and bottom arrows drawn). The 
problem is that the native control makes the item
spacing (not height) is related to the number of lines of text. The rewrite that I did 
does not do that yet, the item spacing is
constant and at two lines. This makes the size of the item list larger than the 
separate scrolling expects. So when Outlook "knows"
the last item is displayed and removes the arrow, our last item is only partially 
displayed.

The internal scrolling seems ok.

I'm going to start looking into these two items this week.

Guy

Re: Listview Large Icon (LVS_ICON) rewrite.

[Dimitrie O. Paun]

On September 24, 2002 12:07 am, Guy L. Albertelli wrote:
> This is a major rewrite of the LVS_ICON (large icon) code. Not everything
> is working correctly yet. Known problems: 
> 1. Focus rectangles are left drawn incorrectly when scrolling window. 

I think I know what the problem is, I'll try to fix it.

> 2. Background is incorrect for at least Outlook (white instead of grey). 

Hm, I don't have Outlook. Any pointers and/or ideas?

> 3. Scrolling in Outlook is not correct.

What's the problem with this one? I might be able to fix it...

-- 
Dimi.

Re: Listview updates

[Dmitry Timoshkov]

"Dimitrie O. Paun" <[EMAIL PROTECTED]> wrote:

> @@ -1034,13 +1035,13 @@
>/* Update Vertical Scrollbar */
>nListHeight = infoPtr->rcList.bottom - infoPtr->rcList.top;
>scrollInfo.fMask = SIF_POS;
> -  if (GetScrollInfo(infoPtr->hwndSelf, SB_VERT, &scrollInfo) == FALSE
> +  if (GetScrollInfo(infoPtr->hwndSelf, SB_VERT, &scrollInfo)

Exclamation mark (!) is missing...

-- 
Dmitry.

Re: ListView Issues

[Guy L. Albertelli]

- Original Message -
From: "Steve Whine" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 14, 2002 10:14 AM
Subject: ListView Issues


> Hi,
>
> I've just started looking into getting a project of
> wine running on Linux via Wine, and I'm very impressed
> so far! However, there are a few (mostly minor)
> problems with the ListView control:
>
> - When using icons bigger than the sizes returned by
> SystemParametersInfo(SPI_GETICONMETRICS), the text for
> the items is not displayed correctly at the bottom of
> the icon.
>
> - When running a program created by C++ Builder 5,
> clicking on an item in the listview causes an access
> violation in C++ Builder's VCL library code - it is
> obviously getting passed an unexpected value.
>
> - The amount of text displayed is often far less than
> is displayed in Windows, making the listbox difficult
> to use.
>
> I have been looking into the ListView code and have
> hacked a fix for the first and third problem, but I am
> having a little difficulty understanding the code -
> the LISTVIEW_INFO struct has both an
> nItemWidth/nItemHeight pair describing the
> width/height of each item, and an iconSpacing SIZE
> struct that seems to do the same. What is the
> difference in these, where should one be used and
> where should the other be used?
>
> Is anyone actively maintaining the listview code, or
> should I just carry on hacking until I'm happy with
> it, and post the changes here? I have created a small
> test program to demonstrate these problems which I can
> post if anyone is interested.
>
> I must say it's very nice to be able to wade into the
> code to fix these problems myself rather than waiting
> for someone else (not) to do it!
>

Yes, Listview is very confusing. I am working on bug #676 which deals with
listview issues in the LVS_ICON style. The display issues are also tied up
with the LVM_GETITEMRECT (of all types). It also is tied up with
inconsistant computation of the actual size of the text area. There is a
prototype patch attached to bug #676. It will not be the final patch but it
is a start.

Guy

Re: ListView Issues

[Dimitrie O. Paun]

On August 14, 2002 10:14 am, Steve Whine wrote:

> Is anyone actively maintaining the listview code, or
> should I just carry on hacking until I'm happy with
> it, and post the changes here? I have created a small
> test program to demonstrate these problems which I can
> post if anyone is interested.

I think your best bet is 'keep on hacking'! :)

-- 
Dimi.

Re: Listview Unicodification (part 2)

[Alexandre Julliard]

"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:

> Alexandre, let me know if you like the patch better in this format.

Yes, it's much better that way, thanks.

-- 
Alexandre Julliard
[EMAIL PROTECTED]

Re: Listview Unicodification (take 3) (fwd)

[Dimitrie O. Paun]

On Tue, 15 Jan 2002, Gerard Patel wrote:

> At 01:58 PM 1/15/02 -0500, you wrote:
> >[once again, I attached the patch by mistake, and the mail did not go
> >through...oh well, that happens if you don't sleep at night:) ]
> 
> I think that by zipping the patch it should be below 64K and
> be fine.

Apparently, the limit is 64K. But there's no much point in gzipping it,
such patches are sooo hard to read from the mailer (save attachment,
ungzip, etc). I hate them. Much simpler if I dump them on the web site,
it's just I did the attachment as an automatism...
 
> >Here is the latest version of the Unicode ListView control:
> >http://www.cs.toronto.edu/~dimi/listview-unicode-3.diff
> 
> Better - all columns have something now - but only
> the first character.
> This fixes it :

Thanks. That was a tricky one. I think the nicer thing is for the
textcpynT function to correctly handle all cases, so I did that in the
(take 4) version of the patch. It didn't receive any testing, as I don't
have your test case which trigger that condition, so I hope everything is
OK now.

> I'll let you turn into something correct since it's now more than 2 in
> the morning and I need some sleep even if you don't.

Sleep tight, I'm off to bed too!

--
Dimi.

Re: Listview Unicodification (take 3) (fwd)

[Gerard Patel]

At 01:58 PM 1/15/02 -0500, you wrote:
>[once again, I attached the patch by mistake, and the mail did not go
>through...oh well, that happens if you don't sleep at night:) ]

I think that by zipping the patch it should be below 64K and
be fine.

>Here is the latest version of the Unicode ListView control:
>http://www.cs.toronto.edu/~dimi/listview-unicode-3.diff

Better - all columns have something now - but only
the first character.
This fixes it :

@@ -5075,7 +5076,14 @@
   else if (lpLVItem->mask & LVIF_TEXT)
   {
 if (internal) lpLVItem->pszText = *ppszText;
-else textcpynT(lpLVItem->pszText, *ppszText, lpLVItem->cchTextMax, isW);
+else
+{
+   if (isW)
+  textcpynT(lpLVItem->pszText, *ppszText, lpLVItem->cchTextMax, isW);
+   else
+  WideCharToMultiByte(CP_ACP,0,*ppszText,-1,lpLVItem->pszText,
+  lpLVItem->cchTextMax,NULL,NULL);
+}
   }
 
   if (lpLVItem->iSubItem == 0)

I'll let you turn into something correct since it's now more than 2 in the
morning
and I need some sleep even if you don't.

Gerard

Re: Listview ctrl

[Alexandre Julliard]

"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:

> Good point. I'm convinced. But since we are on the subject, why did you
> prefer the use of the WideToXXX function instead of the
> RtlCreateUnicode...Asciiz?

No real reason, mostly laziness. It was easier to simply copy the 3
lines from HEAP_strdup into the code than to change it to use the Rtl*
functions. But if you feel like changing that you are most welcome to
do it.

-- 
Alexandre Julliard
[EMAIL PROTECTED]

Re: Listview ctrl

[Dimitrie O. Paun]

On Tue, 8 Jan 2002, Alexandre Julliard wrote:

> The W->A case is not a strdup, it's a simple WideCharToMultiByte.
> 
> Probably at least 90% of the existing calls to HEAP_strdupWtoA are
> because of a W function calling a A function, which is precisely what
> should be discouraged.

Good point. I'm convinced. But since we are on the subject, why did you
prefer the use of the WideToXXX function instead of the
RtlCreateUnicode...Asciiz?

--
Dimi.

Re: Listview ctrl

[Alexandre Julliard]

"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:

> Applied to our case, if we have fooW and fooA, then typically fooA looks
> as such:
> 
> fooA()
> {
>   strdupAtoW
>   fooW
>   strdupWtoA
> }
> 
> So, even if we do go only from A->W at the API level, the actual string
> conversions do go both ways.

Very few functions would need something like that. The normal case
would be:

fooA()
{
  strdupAtoW
  fooW
  copy W back into A if needed
}

The W->A case is not a strdup, it's a simple WideCharToMultiByte.

Probably at least 90% of the existing calls to HEAP_strdupWtoA are
because of a W function calling a A function, which is precisely what
should be discouraged.

-- 
Alexandre Julliard
[EMAIL PROTECTED]

Re: Listview ctrl

[Dimitrie O. Paun]

On Tue, 8 Jan 2002, Alexandre Julliard wrote:

> That's just as much pollution. We must not introduce incompatibilities
> except where there's clearly no other possibility. In this case there
> are tons of other options.

If you insist... :)
 
> > Indeed. MultiByteToWideChar is just brutal IMO. But many times if we need
> > to go W->A we also need to go A->W, and hence my proposal for symetrical
> > functions.
> 
> The asymmetry could be considered a feature, since people should be
> encouraged to go A->W instead of W->A wherever possible.

In theory, yes. But you know what Larry McVoy once said:

The difference between theory and practice is that in theory there is no
difference, while in practice there is.

Applied to our case, if we have fooW and fooA, then typically fooA looks
as such:

fooA()
{
  strdupAtoW
  fooW
  strdupWtoA
}

So, even if we do go only from A->W at the API level, the actual string
conversions do go both ways.

--
Dimi.

Re: Listview ctrl

[Francois Gouget]

On Tue, 8 Jan 2002, Dimitrie O. Paun wrote:
[...]
> The bad news is that I have no
> idea how to test it. So any suggestions on how to test the listview
> control, or any help with the testing is greatly appreciated, as well as
> any comments on the patch itself.


   I believe you will find the 'Common Control Spy Samples' very useful
in testing common controls. You can download them from Microsoft's web
site:

   http://www.microsoft.com/msj/0998/code/controlspy.exe

You may also want to read the following article:
   "Control Spy Exposes the Clandestine Life of Windows Common Controls"
 * Part I
   http://www.microsoft.com/msj/0798/controlspy.htm
 * Part II
   http://www.microsoft.com/msj/0998/control/control.htm
 * Part III
   http://www.microsoft.com/msj/1298/controlspy3/controlspy3.htm



   (from http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=239)

--
Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/
   La terre est une bêta...