Re: listview expert required (again)
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.
listview expert required (again)
another bug description for listview (native listview works as expected here) 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+ -- Eric Pouech
Re: listview expert required
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
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 blushIt's my patch, mea culpa/blush. 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
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
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
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
blushIt's my patch, mea culpa/blush.
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
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
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 blushIt's my patch, mea culpa/blush. 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 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
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
implements what you described. thanks... works like a charm now impressive turn around time btw!! A+ -- Eric Pouech
listview expert required
some apps of mine needs this to get going: can someone with good listview knowledge confirm ? (or find the correct fix) TIA -- Eric Pouech Index: dlls/comctl32/listview.c === RCS file: /home/cvs/cvsroot/wine/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.c22 Aug 2003 20:30:27 - @@ -5822,11 +5822,11 @@ 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 /* (infoPtr-dwLvExStyle LVS_EX_FULLROWSELECT)*/) rcBounds = rcBox; else UnionRect(rcBounds, rcIcon, rcLabel); TRACE(rcBounds=%s\n, debugrect(rcBounds)); if (!PtInRect(rcBounds, opt)) return -1; if (PtInRect(rcIcon, opt))
Re: listview expert required
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.
ListView
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 shouldnever 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 patchUltimateZip and Starbase StarTeamwork (our patchusesfirst option, deletes last column). http://www.winehq.com/hypermail/wine-patches/2003/02/0212.html Matej Spiller-Muys
Re: ListView
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
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
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 - add CACHEHINT notification in OwnerData mode
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)
+{
+ RANGE range = iterator_range(i);
+
Re[2]: ListView - add CACHEHINT notification in OwnerData mode
Looks good to me. Thank you. Sunday, March 23, 2003, 10:02:10 AM, you wrote: 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 - [snip]
shell + listview + imagelist great test program
Hi there, I think I struck gold! I found pretty simple yet _RELY_ broken program. Here are screen shots: http://www.kievinfo.com/snapshot1.png http://www.kievinfo.com/snapshot2.png It's one of the demo programs from Delphi 5. Source included. To download executable use this link: http://www.kievinfo.com/virtuallistview.exe -- Best regards, Vitaliy Virtual_Listview.tar.bz2 Description: Binary data
Re: ListView Part2
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: Re[4]: Anyone working on ListView?
On March 12, 2003 12:40 am, Vitaliy Margolen wrote: I got it figured out. At least for simplified case. I got a question: tagLISTVIEW_INFO is our structure or it's MS defined one? If former, I can add few more variables to it : maxHight and maxWidth - to track dimensions of ListView. And update it every time on inserts and refreshes. Yes, it is our structure. But before you add them, why is it that LISTVIEW_GetAreaRect() does not work for you? It should compute the maxHeight and maxWidth correctly. If it doesn't, I'd rather prefer that we fix it (we may need the maxHeight and maxWidth variables to fix it properly, but I'd like to know why). Yes missing names are always the same one. One more interesting fact: if directory missing name - all files in it don't have them neither. Some tracing here would be good. Somehow we probably don't do the callback right, but you have to investigate what the app expects. -- Dimi.
Re: Few fixes for ListView
On March 13, 2003 01:53 am, Vitaliy Margolen wrote: - y = (LONG)DPA_GetPtr(infoPtr-hdpaPosX, i); + y = (LONG)DPA_GetPtr(infoPtr-hdpaPosY, i); Duh! Good spotting, I just looked at it yesterday, and I did not see it. Funny how you see what you want to see... :) -- Dimi.
Re[6]: Anyone working on ListView?
Wednesday, March 12, 2003, 5:57:56 AM, you wrote: On March 12, 2003 12:40 am, Vitaliy Margolen wrote: I got it figured out. At least for simplified case. I got a question: tagLISTVIEW_INFO is our structure or it's MS defined one? If former, I can add few more variables to it : maxHight and maxWidth - to track dimensions of ListView. And update it every time on inserts and refreshes. Yes, it is our structure. But before you add them, why is it that LISTVIEW_GetAreaRect() does not work for you? It should compute the maxHeight and maxWidth correctly. If it doesn't, I'd rather prefer that we fix it (we may need the maxHeight and maxWidth variables to fix it properly, but I'd like to know why). Never mind. I thought it was calling GetItem for every item in a ListView to get it's position. Rather it accessing them directly. I was thinking to optimize this part. If we store and update these variables in the right places... But this gonna be a mess. Too many places that can change position of an item. And what if it's removed? You were right - I found the bug there. ;-) Yes missing names are always the same one. One more interesting fact: if directory missing name - all files in it don't have them neither. Some tracing here would be good. Somehow we probably don't do the callback right, but you have to investigate what the app expects. So far no luck here. It could be related to TreeView. For whatever reason ACDSee can't set proper path in TreeView. On Windows it opens up correct directory, even if it's a network path. Next thing: big icons. Something very screwy going on there. Looks to me like each icon somehow gets huge. Even with scrolls fixed, I have both horvert bars set to ridiculously big ranges.
Re: Re[6]: Anyone working on ListView?
On March 13, 2003 02:15 am, Vitaliy Margolen wrote: Never mind. I thought it was calling GetItem for every item in a ListView to get it's position. Rather it accessing them directly. I was thinking to optimize this part. If we store and update these variables in the right places... But this gonna be a mess. Too many places that can change position of an item. And what if it's removed? See? You can't really maintain it in a sane manner, I did think about it several times. But regardless, this will get super optimized when we properly support large numbers of items in ICON mode. I have the idea in my head, it's just a matter of coding it... :) I just can't find the time to do it! :( So far no luck here. It could be related to TreeView. For whatever reason ACDSee can't set proper path in TreeView. On Windows it opens up correct directory, even if it's a network path. Maybe it's setting the names it gets from the TreeView, and if that is broken, then the problem will get propagated to the listview (even if the listview works correctly). Next thing: big icons. Something very screwy going on there. Looks to me like each icon somehow gets huge. Even with scrolls fixed, I have both horvert bars set to ridiculously big ranges. This should be easy to trace. As you've seen, to get the scroll range we just get the max of all the origins of all the icons... -- Dimi.
Re: Re[2]: Anyone working on ListView?
On March 11, 2003 01:41 am, Vitaliy Margolen wrote: 1. Vertical Scroll boundaries are not set properly in Icon and SmallIcon modes. I hacked this one but it's not correct - still missing about 10-20 pixels. Not sure why. I know, there was on previous bug report about it. Feel free to submit a patch. In general, Icon and SmallIcon modes have more problems than the Report and List modes :( 2. ACDSee's Big Icons mode doesn't show anything at all. Not sure what the problem here. It looks like it is possible to select something with keyboard. But still nothing on on the screen. Odd -- you'll need to debug this a little. Remember, the listview can't gracefully handle more than 3 or so items in Icon and SmallIcon mode, so please test with lists smaller than that. 3. ToolTips not implemented. Not that it's so important. But ACDSee using them for additional info about images. Known -- it's in the TODO. I guess this one can wait, there are other burning problems to solve first :) 4. Keyboard navigation in Icon mode is broken. Only right key sorta works. I know -- keyboard handling has been on my TODO list for some time, but I did not have the time to investigate. Feel free to work on it. 5. Resizing window does not rearrange icons. Only doing refresh - F5 rearranges icons in the proper fashion. It should. Can you capture a +listview trace of a resizing event? 6. Biggest mystery to me - some items missing image names. This happens in all modes. ACDSee is using callbacks for text/images. So I'm not sure where the problem is. There are some activity going on with all file names according to trace:string. But GetDispInfo returns blanks. Although thumbnails and preview are displayed properly. Hmmm. This is strange, it shouldn't do that. Are the missing names always the same? 7. In Icon SmallIcon mouse wheel is reversed. Try the obvious fix, see if that works :) Basically (1)(6) are major show stoppers. (4)(5) needs to be there to make it usable. True. If you have patches, post them to the list, so we can discuss them. There is two more mysteries in ACDSee - TreeView. It's entries are not sorted! But they are under Win. And those folders that don't have names in ListView shown properly in TreeView. Our treeview is not perfect :) Let's deal with the listview first, it's enough to keep us busy for a while ;). -- Dimi.
Re[4]: Anyone working on ListView?
Tuesday, March 11, 2003, 6:14:22 AM, Dimitrie O. Paun wrote: On March 11, 2003 01:41 am, Vitaliy Margolen wrote: 1. Vertical Scroll boundaries are not set properly in Icon and SmallIcon modes. I hacked this one but it's not correct - still missing about 10-20 pixels. Not sure why. I know, there was on previous bug report about it. Feel free to submit a patch. In general, Icon and SmallIcon modes have more problems than the Report and List modes :( I got it figured out. At least for simplified case. I got a question: tagLISTVIEW_INFO is our structure or it's MS defined one? If former, I can add few more variables to it : maxHight and maxWidth - to track dimensions of ListView. And update it every time on inserts and refreshes. 2. ACDSee's Big Icons mode doesn't show anything at all. Not sure what the problem here. It looks like it is possible to select something with keyboard. But still nothing on on the screen. Odd -- you'll need to debug this a little. Remember, the listview can't gracefully handle more than 3 or so items in Icon and SmallIcon mode, so please test with lists smaller than that. It's mach smaller than that. I had just 10-20 items. I might try with something less sophisticated than ACDSee. Somewhere I have explorer like program written in Delphi. Should be perfect for this. 5. Resizing window does not rearrange icons. Only doing refresh - F5 rearranges icons in the proper fashion. It should. Can you capture a +listview trace of a resizing event? So far it reacts when size get's too small to fit right most column of icons. But nothing when size gets bigger enough for one more column. I will try to get some meaningful logs out of it. 6. Biggest mystery to me - some items missing image names. This happens in all modes. ACDSee is using callbacks for text/images. So I'm not sure where the problem is. There are some activity going on with all file names according to trace:string. But GetDispInfo returns blanks. Although thumbnails and preview are displayed properly. Hmmm. This is strange, it shouldn't do that. Are the missing names always the same? Yes missing names are always the same one. One more interesting fact: if directory missing name - all files in it don't have them neither. Vitaliy Margolen
Re: Anyone working on ListView?
yes, see many patches onto wine-patches... --- Vitaliy Margolen [EMAIL PROTECTED] a écrit : I was wondering is there is anyone working on ListView? The reason I ask? I got ACDSee 3.1 installed (see my last patch about typo) working (well, sort of). It looks like ACDSee depends heavily relies on functionality which is missing from ListView. My question is: if I'll start hacking ListView will I be interfering with someone else's work? FYI: ACDSee - if not the best, for sure one of the best image viewers. Version 3.1 could be ran in Sponsored mode indefinitely as long as it connects to the I-net to get messages banners. -- Best regards, Vitaliy Margolen = Sylvain Petreolle [EMAIL PROTECTED] Fight Spam ! EuroCauce: http://www.euro.cauce.org/en/index.html ICQ #170597259 Don't think you are. Know you are. Morpheus, in Matrix. ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Re: Anyone working on ListView?
On March 10, 2003 11:42 am, Vitaliy Margolen wrote: My question is: if I'll start hacking ListView will I be interfering with someone else's work? I did a lot of work on the listview recently, but due to new job responsibilities, it's on the backburner ATM. So if you want to work on it, you're welcome! Feel free to ask questions, I'll try to help. BTW, what features does ACDSee need from the listview that are not implemented? -- Dimi.
Re[2]: Anyone working on ListView?
Monday, March 10, 2003, 9:46:27 PM, you wrote: On March 10, 2003 11:42 am, Vitaliy Margolen wrote: My question is: if I'll start hacking ListView will I be interfering with someone else's work? I did a lot of work on the listview recently, but due to new job responsibilities, it's on the backburner ATM. So if you want to work on it, you're welcome! Feel free to ask questions, I'll try to help. BTW, what features does ACDSee need from the listview that are not implemented? Well, in few words: ListView is badly broken. Here is a list of thing which doesn't work at all, badly broken or missing: 1. Vertical Scroll boundaries are not set properly in Icon and SmallIcon modes. I hacked this one but it's not correct - still missing about 10-20 pixels. Not sure why. 2. ACDSee's Big Icons mode doesn't show anything at all. Not sure what the problem here. It looks like it is possible to select something with keyboard. But still nothing on on the screen. 3. ToolTips not implemented. Not that it's so important. But ACDSee using them for additional info about images. 4. Keyboard navigation in Icon mode is broken. Only right key sorta works. 5. Resizing window does not rearrange icons. Only doing refresh - F5 rearranges icons in the proper fashion. 6. Biggest mystery to me - some items missing image names. This happens in all modes. ACDSee is using callbacks for text/images. So I'm not sure where the problem is. There are some activity going on with all file names according to trace:string. But GetDispInfo returns blanks. Although thumbnails and preview are displayed properly. 7. In Icon SmallIcon mouse wheel is reversed. Basically (1)(6) are major show stoppers. (4)(5) needs to be there to make it usable. There is two more mysteries in ACDSee - TreeView. It's entries are not sorted! But they are under Win. And those folders that don't have names in ListView shown properly in TreeView. Vitaliy Margolen
Re: PATCH: Inserting an item in a listview sometimes generates incorrect messages
On March 6, 2003 06:04 am, Adam Gundy wrote: [wine-devel Cc:ed to keep people in the loop] Is a listview guaranteed to be single threaded? I assume it is because it is all message driven - so some flag in the LISTVIEW_INFO structure could be set. I'd say that is even more opaque. I think this would be better. It's localized in two points (where we set it, and where we use it), and it's easier to follow. The rest of the code should be unaware of this problem, so hiding it is the right thing to do IMO. The reason it's easier to follow is that if I don't see it, I don't care about it, which is what we want, and 99% of people looking at the code will fall in this category. If you do happen to stumble upon it, you can search for the infoPtr-blah thing that we're setting to see where and how this thing is used. You can't easily search with the current flag solution. Actually, there is the rather unhelpful comment But we are not supposed to modify nHotItem!* in LISTVIEW_ShiftIndices() - does 'real' Windows maintain the focus after an insertion? Perhaps that's why they don't send the messages - you know how they work: write the code then document its broken behaviour after the fact ;-) Yes, I know. This is why I think it should just result from some other behavior naturally, I don't think MS went through the trouble of passing a boolean around all over the place just to not send this notification. One more reason to not uglify our interfaces, as it will just get fixed automatically when we properly support the HotItem. -- Dimi.
Re: PATCH: Inserting an item in a listview sometimes generates incorrect messages
On Thu, 6 Mar 2003, Adam Gundy wrote: fine by me. you want me to do it? If you don't mind... :) -- Dimi.
Re: PATCH: Inserting an item in a listview sometimes generates incorrect messages
At 10:17 06/03/03 -0500, Dimitrie O. Paun wrote: On March 6, 2003 06:04 am, Adam Gundy wrote: [wine-devel Cc:ed to keep people in the loop] Is a listview guaranteed to be single threaded? I assume it is because it is all message driven - so some flag in the LISTVIEW_INFO structure could be set. I'd say that is even more opaque. I think this would be better. It's localized in two points (where we set it, and where we use it), and it's easier to follow. The rest of the code should be unaware of this problem, so hiding it is the right thing to do IMO. The reason it's easier to follow is that if I don't see it, I don't care about it, which is what we want, and 99% of people looking at the code will fall in this category. If you do happen to stumble upon it, you can search for the infoPtr-blah thing that we're setting to see where and how this thing is used. You can't easily search with the current flag solution. fine by me. you want me to do it? Seeya, Adam -- Real Programmers don't comment their code. If it was hard to write, it should be hard to read, and even harder to modify. These are all my own opinions.
Re: PATCH: Inserting an item in a listview sometimes generates incorrect messages
On March 5, 2003 09:28 am, Adam Gundy wrote: When shifting the list's indices, we must not send notify messages if we have to refocus. Item modification handlers are not supposed to be called here. I'm not too hot about passing that boolean around... I'd rather have a special way to avoid the notification in the case of shifting items, rather than clutter the interface that's used all over the place to pass a strange TRUE that's rather opaque. I've tried hard to not extend the interface beyond what's documented for the messages. It makes the code simpler to follow. -- Dimi.
Problem in listview with LVM_OWNERDATA set too late
The test program http://www.kegel.com/ownerdata.exe shows a problem with OWNERDATA listview controls which pick up that attribute after being created. (No, this is not per the spec. Yes, a real program does that.) To see the problem, run ownerdata.exe, and select View / Capture View. The window should NOT be blank. Methinks it's a bug, or at least a missing feature, in our listview. Dimi Paun thinks so, too, and wants me to file a bug about it. I will when I'm less swamped... - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Re: Listview delete column zero
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 g. 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
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 g. Why not just use LVM_DELETEALLITEMS? -- Dimi.
Re: Listview problems
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
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.
Listview problems
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. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Re: Listview problems
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: Initialize listview item size.
Dimitrie O. Paun wrote: On February 3, 2003 11:58 am, Duane Clark wrote: This is a separate bug from the other listview patches. If an app sends a LISTVIEW_Paint to a new listview before adding any items (which an app was :-) the item size was not getting set, causing subsequent LISTVIEW_Paint calls to clip the painting. Changelog: Make sure item size is initialized when the first item is added. This is an optimization I've put in to avoid a lot of complex calculations while the listview is initially populated (typically before it's being painted). You are right, we have to detect the change nItemCount from 0 to 1, to do all those calculations. But since we don't actually need them until we paint, I'd like to defer them as much as possible. Moreover, with your patch, we don't catch the SetItemCount case. What about this patch instead: Last night almost the same solution occured to me, so yes I would agree this is better.
Re: Initialize listview item size.
On February 3, 2003 11:58 am, Duane Clark wrote:
This is a separate bug from the other listview patches. If an app sends
a LISTVIEW_Paint to a new listview before adding any items (which an app
was :-) the item size was not getting set, causing subsequent
LISTVIEW_Paint calls to clip the painting.
Changelog:
Make sure item size is initialized when the first item is added.
This is an optimization I've put in to avoid a lot of complex calculations
while the listview is initially populated (typically before it's being
painted). You are right, we have to detect the change nItemCount from 0
to 1, to do all those calculations. But since we don't actually need them
until we paint, I'd like to defer them as much as possible. Moreover,
with your patch, we don't catch the SetItemCount case. What about this
patch instead:
Index: dlls/comctl32/listview.c
===
RCS file: /var/cvs/wine/dlls/comctl32/listview.c,v
retrieving revision 1.338
diff -u -r1.338 listview.c
--- dlls/comctl32/listview.c24 Jan 2003 00:54:59 - 1.338
+++ dlls/comctl32/listview.c5 Feb 2003 06:48:41 -
@@ -7850,7 +7850,7 @@
{
TRACE((hdc=%p)\n, hdc);
-if (infoPtr-bFirstPaint)
+if (infoPtr-bFirstPaint infoPtr-nItemCount)
{
UINT uView = infoPtr-dwStyle LVS_TYPEMASK;
--
Dimi.
Re: Initialize listview item size.
On Mon, 3 Feb 2003, Duane Clark wrote: This is a separate bug from the other listview patches. If an app sends a LISTVIEW_Paint to a new listview before adding any items (which an app was :-) the item size was not getting set, causing subsequent LISTVIEW_Paint calls to clip the painting. Sorry Duane, maybe it's just Monday morning, but I don't understand this. If the listview has no items, what is it supposed to paint? Also, this just doesn't seem like the right place to place this check. What if the app doesn't call LVM_SETITEMCOUNT? -- Dimi.
Re: Initialize listview item size.
Dimitrie O. Paun wrote:
On Mon, 3 Feb 2003, Duane Clark wrote:
This is a separate bug from the other listview patches. If an app sends
a LISTVIEW_Paint to a new listview before adding any items (which an app
was :-) the item size was not getting set, causing subsequent
LISTVIEW_Paint calls to clip the painting.
Sorry Duane, maybe it's just Monday morning, but I don't understand this.
If the listview has no items, what is it supposed to paint?
It paints the headers. And the problem comes about because in
LISTVIEW_Paint, a test is made for the first paint, and if it is the
first paint, the item size is updated.
if (infoPtr-bFirstPaint)
{
UINT uView = infoPtr-dwStyle LVS_TYPEMASK;
infoPtr-bFirstPaint = FALSE;
LISTVIEW_UpdateItemSize(infoPtr);
...
Also, this just doesn't seem like the right place to place this check.
What if the app doesn't call LVM_SETITEMCOUNT?
It has nothing to do with LVM_SETITEMCOUNT that I know, or am I missing
something? This bug is not related to the other bug.
Re: Initialize listview item size.
Duane Clark wrote: It paints the headers. And the problem comes about because in LISTVIEW_Paint, a test is made for the first paint, and if it is the first paint, the item size is updated. I guess I should have said something like ...and only if it is the first paint Hopefully that was reasonably obvious anyway.
Re: Initialize listview item size.
On Mon, 3 Feb 2003, Duane Clark wrote: It has nothing to do with LVM_SETITEMCOUNT that I know, or am I missing something? This bug is not related to the other bug. Sorry, my mistake, I registered it automatically as part of SetItemCount when you send it bundled with the other stuff. I'll review it when I get home. -- Dimi.
Re: Listview scroll patch
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
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 scroll patch
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 report mode tweaks
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 #2
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
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.
Listview WM_NOTIFYFORMAT and LVN_GETDISPINFO
Hi Dimi, I have been doing some work on OWNERDATA listviews with Outlook and have found something with my test programs. Even if i create a Dialog with DialogBoxW to contain the listview, and return NFR_UNICODE for WM_NOTIFYFORMAT my windows 2000 box still calls notifies with LVN_GETDISPINFOA and NOT LVN_GETDISPINFOW. 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. thanks -aric
Re: Listview WM_NOTIFYFORMAT and LVN_GETDISPINFO
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 WM_NOTIFYFORMAT and LVN_GETDISPINFO
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)
{
- if (convertToUnicode
Re: Listview WM_NOTIFYFORMAT and LVN_GETDISPINFO
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
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
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
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
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.
listview: last column problem
Dimitri, The missing last column in newsbin seems to be caused by this line: | if (!lpColumn || nColumn 0 || nColumn infoPtr-hdpaColumns-nItemCount) |return -1; | ^ removing the marked part of the test result in a couple of error messages: | err:listview:LISTVIEW_InsertColumnT nColumn=4, nNewColumn=3 | err:listview:LISTVIEW_InsertColumnT nColumn=4, nNewColumn=3 | err:listview:LISTVIEW_InsertColumnT nColumn=4, nNewColumn=3 but otherwise runs fine. Do you see any objections removing the test and error message? Rein. -- Rein Klazes [EMAIL PROTECTED]
Re: listview: last column problem
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: last column problem
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]
recent ListView problems
Hi, I'm using WinMX (www.winmx.com) rather frequently, currently version 3.30. Some two weeks ago, Wine HEAD displayed the ListView components from the search and transfer tabs perfectly, now the refresh/redrawing is messed up. The application documented the changes ListView has undergone in the recent months quite well, though (I'm updating Wine from CVS almost every day). Congratulations for implementing that rather complex control (almost) perfectly! Take care, -Maik
Re: recent ListView problems
On October 29, 2002 06:30 am, [EMAIL PROTECTED] wrote: I'm using WinMX (www.winmx.com) rather frequently, currently version 3.30. Some two weeks ago, Wine HEAD displayed the ListView components from the search and transfer tabs perfectly, now the refresh/redrawing is messed up. Please, file bug in Bugzilla: 1. assign it to me ([EMAIL PROTECTED]) 2. find which revision broke it, and note it in there 3. attach trace log 4. attach screenshots -- Dimi.
Re: Known listview bugs (take 2)
On October 24, 2002 02:12 pm, Paul Rupe wrote: - This is something that never worked in the old code either so it may not be listview-related. An obscure Xnews feature is that you can right-click the read column in the newsgroup listing and edit its contents. Instead the standard context menu for that window appears. Looked at this. Our notifications seems correct, Xnews does very strange things with mouse input. Please write the author, and ask him what he needs to get this working. -- Dimi.
Re: Listview Z8
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
(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
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
Listview: what next?
Folks, I now consider the listview rewrite complete. What this means: -- current revision (1.325) may become a reference rev for a while -- bugs for the listview should be submitted through Bugzilla NOw, I know there are outstanding bugs. Most likely, there would always be. But i have to draw the line somewhere. I would like everybody that submitted bugs/feature requests/etc. to retest with the latest code in CVS, and submit a bug at http://bugs.winehq.org: 1. assign it to me ([EMAIL PROTECTED]) 2. try to find the revision that caused it 3. screenshots of visual problems help alot Due to my hand problems, I will not be as active these days. But I will be glad to review problems, and think about solving them, so please fill out those bug reports! :) Again, having the bugs in Bugzilla will help me greatly in managing them. -- Dimi.
Re: Known listview bugs (take 2)
The fix in http://bugs.winehq.com/show_bug.cgi?id=924 looks good. Could sbd send it as a patch ? Thanks Juergen On Thu, 24 Oct 2002, Dimitrie O. Paun wrote: On October 24, 2002 04:00 pm, Francois Gouget wrote: Argh! I cheated. I used a slightly older Wine and copied the comctl32 dll there. Today I retested with CVS Wine plus the latest X11 patch and got it to work by just replacing the shell32 library with an older one Can you please search what broke shell32? This is Not Good (TM) Winzip was broken on 2002/07/23 by one of the following two patches: * http://cvs.winehq.com/patch.py?id=1027475763780155356581421 Juergen Schmied [EMAIL PROTECTED] - Cleaned up the implementation of shell folders and put them into separate files - Fixed some memory leaks - Some more fixes * http://cvs.winehq.com/patch.py?id=102747584224009388063951 Fixed duplication of definitions between shlwapi.h and obj_queryassociations.h I cannot compile Wine if I only apply the first one. I suspect there is a problem in the first one but unfortunately it is pretty large: ~4000 lines -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0 --- [EMAIL PROTECTED]
Re: Known listview bugs (take 2)
El dom, 27 de oct de 2002, a las 13:14, Jürgen Schmied escribio: The fix in http://bugs.winehq.com/show_bug.cgi?id=924 looks good. Could sbd send it as a patch ? My patch with subject: (Day 26 oct) SHGFI_USEFILEATTRIBUTES support in SHGetFileInfoA fixes this problem (winzip is working again and really nice!!!) and some different issues relative to SHGFI_USEFILEATTRIBUTES. Regards, Carlos. -- ___ _ \ | / Infraestructuras | . |._ _ _| | ___ ___ ___http://www.andago.com | || ' |/ . |_ |/ . |/ . \__ GNU/Linux |_|_||_|_|\___|___|\_. |\___/ _ \ __|\ \ / Carlos A. Lozano ___'/ | \ -_) __/\__ \ -_) [ [EMAIL PROTECTED] ]\___|_| / _/\_\___| [ [EMAIL PROTECTED] ] http://www.epsxe.com
Re: Listview Z8
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 Z8
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
* FAILURE : FALSE
*/
-static BOOL set_main_item(LISTVIEW_INFO *infoPtr, LPLVITEMW
Re: Listview Z8
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
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
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
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
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: Known listview bugs (take 2)
On Thu, 24 Oct 2002, Dimitrie O. Paun wrote: On October 24, 2002 04:00 pm, Francois Gouget wrote: Argh! I cheated. I used a slightly older Wine and copied the comctl32 dll there. Today I retested with CVS Wine plus the latest X11 patch and got it to work by just replacing the shell32 library with an older one. Can you please search what broke shell32? This is Not Good (TM). Winzip was broken on 2002/07/23 by one of the following two patches: * http://cvs.winehq.com/patch.py?id=1027475763780155356581421 Juergen Schmied [EMAIL PROTECTED] - Cleaned up the implementation of shell folders and put them into separate files. - Fixed some memory leaks. - Some more fixes. * http://cvs.winehq.com/patch.py?id=102747584224009388063951 Fixed duplication of definitions between shlwapi.h and obj_queryassociations.h. I cannot compile Wine if I only apply the first one. I suspect there is a problem in the first one but unfortunately it is pretty large: ~4000 lines. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0
Re: Known listview bugs (take 2)
Francois Gouget wrote: Winzip was broken on 2002/07/23 by one of the following two patches: * http://cvs.winehq.com/patch.py?id=1027475763780155356581421 Juergen Schmied [EMAIL PROTECTED] - Cleaned up the implementation of shell folders and put them into separate files. - Fixed some memory leaks. - Some more fixes. * http://cvs.winehq.com/patch.py?id=102747584224009388063951 Fixed duplication of definitions between shlwapi.h and obj_queryassociations.h. See the bug: http://bugs.winehq.com/show_bug.cgi?id=924
Re: Known listview bugs (take 2)
So, I know this has been discussed before... but I can't recall: is native (W98) regedit expected to work right now? For me, it doesn't. It's better with the latest CVS than yesterday (died on an assertion), but now it's back to blank. The listview shows correct headers, but no actual line-items. Native commctrl/comctl32 works OK. -- gmt Oh, and of course, the fastest way to dig a tunnel is to dig at both sides. -- The Linux Advanced Routing HOWTO
Re: Listview Z0 (roll-up patch)
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: Known listview bugs (take 2)
On October 25, 2002 02:36 am, Greg Turner wrote: So, I know this has been discussed before... but I can't recall: is native (W98) regedit expected to work right now? For me, it doesn't. It's better with the latest CVS than yesterday (died on an assertion), but now it's back to blank. The listview shows correct headers, but no actual line-items. Native commctrl/comctl32 works OK. Well, I don't have that application, so you'll need to help debug it if you want it working :). First step is a --debugmsg +listview. If you think that's relevant, a screenshot too. -- Dimi.
Re: Known listview bugs (take 2)
On October 25, 2002 11:34 am, Rein Klazes wrote: It is a bit too much. The flashing is gone, great. But when the message listview is filled and the display updates, of the perhaps 10 new items that are added to the bottom only the last 2 or 3 are displayed. That leaves white gaps in the listview which will update when the display is minimized/restored or some similar action. This is quite odd, I don't see that here. Can you please send me some screenies? -- Dimi.
Re: Known listview bugs (take 2)
On Thu, 24 Oct 2002 19:20:44 -0400, you wrote: On October 24, 2002 07:34 am, Rein Klazes wrote: - Updating/refreshing the messages listview (when downloading headers) is far less efficient then with native comctl32. The whole listview gets refreshed instad of just the visible update. This is especially noticable when the updates are not in the visible part of the listview: builtin keeps flashing while native is completely still. Fixed by X12. Take it for a spin, and let me know. It is a bit too much. The flashing is gone, great. But when the message listview is filled and the display updates, of the perhaps 10 new items that are added to the bottom only the last 2 or 3 are displayed. That leaves white gaps in the listview which will update when the display is minimized/restored or some similar action. Rein. -- Rein Klazes [EMAIL PROTECTED]
Re: Known listview bugs (take 2)
On Fri, 25 Oct 2002 11:38:23 -0400, you wrote: On October 25, 2002 11:34 am, Rein Klazes wrote: It is a bit too much. The flashing is gone, great. But when the message listview is filled and the display updates, of the perhaps 10 new items that are added to the bottom only the last 2 or 3 are displayed. That leaves white gaps in the listview which will update when the display is minimized/restored or some similar action. This is quite odd, I don't see that here. Can you please send me some screenies? www.xs4all.nl/~rklazes/temp/nb2.png shows the problem quit well, only two items are displayed where there should have been much more; www.xs4all.nl/~rklazes/temp/nb3.png same window after it was temporary partly obscured by another window showing the missing items. Rein. -- Rein Klazes [EMAIL PROTECTED]
Re: Known listview bugs (take 2)
Just a couple of days ago, the problem with native (W95-OSR2.1) regedit was that changing keys in the tree kept piling up new items in the listview. It was quite interesting seeing multiple (Default) values for a key :-). Now (12 hours ago anyways) it is always blank. When I click on where the values should be (highlight them), sometimes they will show up then. It seems something is not being refreshed that should be. Maybe I'll get a chance to dig in later today if nothing has been uncovered by then. -- Jeff S. From: Greg Turner [EMAIL PROTECTED] On Friday 25 October 2002 07:35 am, Dimitrie O. Paun wrote: On October 25, 2002 02:36 am, Greg Turner wrote: So, I know this has been discussed before... but I can't recall: is native (W98) regedit expected to work right now? For me, it doesn't. Well, I don't have that application, so you'll need to help debug it if you want it working :). First step is a --debugmsg +listview. If you think that's relevant, a screenshot too. ok, I'll do this tonight, and maybe even try to drill in a little deeper if I can figure anything interesting out. FYI, I think this problem existed before your listvew work started, so its probably not your doing. BTW, thanks for your ongoing work, listviews feel much better lately! -- gmt _ Unlimited Internet access -- and 2 months free! Try MSN. http://resourcecenter.msn.com/access/plans/2monthsfree.asp
Re: Listview Z0 (roll-up patch)
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)
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: Known listview bugs (take 2)
On Fri, 25 Oct 2002 14:47:14 -0400, you wrote: On October 25, 2002 12:16 pm, Rein Klazes wrote: www.xs4all.nl/~rklazes/temp/nb2.png shows the problem quit well, only two items are displayed where there should have been much more; www.xs4all.nl/~rklazes/temp/nb3.png same window after it was temporary partly obscured by another window showing the missing items. Thank you, please try Z5. Now it is visually back to the situation before X12, lots of flickering. Rein. -- Rein Klazes [EMAIL PROTECTED]
Re: Known listview bugs (take 2)
On October 25, 2002 03:24 pm, Rein Klazes wrote: Now it is visually back to the situation before X12, lots of flickering. I beg to differ. I've tried it, and it *sometimes* flickers *once* (that is, at the end of the download, it refreshes again, even if it shouldn't). Problem is, that the _app_ requires that behaviour! That is, it depends on WM_SETREDRAW(TRUE) to invalidate the list, and it's issuing one at the end... -- Dimi.
Re: Known listview bugs (take 2)
On October 25, 2002 02:33 pm, Jeff Smith wrote: Now (12 hours ago anyways) it is always blank. When I click on where the values should be (highlight them), sometimes they will show up then. It seems something is not being refreshed that should be. Try Z5 -- hopefully it should fix it. -- Dimi.
Re: Listview Z0 (roll-up patch)
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: Known listview bugs (take 2)
On October 25, 2002 04:18 pm, Rein Klazes wrote: What I see different from native comcontrol is that 1- during a refresh everything is redrawn, including the header control; This is fixable, and it will get fixed soon. 2- the refreshing continues about once every second until the download is finished, certainly not sometimes or only at the end. Hm, maybe I didn't look at newsgroups that took many seconds. In fact, I've seen similar behavior (but not generated by WM_SETREDRAW, the app itself would invalidate the entire window from outside), in other apps (e.g. All-SeeingEye: http://www.udpsoft.com/eye/) I will investigate the WM_SETREDRAW messages, perhaps they appear too often in my situation. That still does not explain why a refresh with native dll manages only to repaint the updated part, which is nill at the end of the download. I think the native does double buffering to avoid that flicker. I will eventually add that too, but I want to make sure, before I do, that we do have the most optimal invalidating/painting code that's possible. Once we're satisfied with that, I'll try to eliminate the rest of the flicker by rendering to an off-screen buffer. I did this in the Trackbar control, and it works quite well. -- Dimi.
Re: Listview Z0 (roll-up patch)
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)
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...
Known listview bugs (take 2)
Folks, After my latest X-series patches (currently at X6), I am aware of the following listview bugs: Yes, you read correctly: NONE. :) So I ask you for one of two things: -- bug reports or -- success stories Otherwise, I'm gonna declare listview the coolest, nicest, most huggable piece of code out there g. -- Dimi.
