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+
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).
Dimitrie O. Paun wrote:
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...)
no
-- LVS_SORTASCENDING or LVS_SORTDESCENDING?
ascending
-- LVS_OWNERDRAWFIXED?
no
-- Do you use LPSTR_TEXTCALLBACK for the item text?
no
-- Does a refresh fix the problem?
no
-- Any pattern to the "some cases"?
see below
-- Do you use any callbacks?
no
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).
here's a snapshot of a code that breaks the listview... native lv let '2' be selected current builtin end up with 3 being selected A+
LVITEM lvi; int index;
memset(&lvi, 0, sizeof(lvi)); lvi.mask = LVIF_TEXT; lvi.pszText = "3"; index = ListView_InsertItem(hLV, &lvi);
memset(&lvi, 0, sizeof(lvi)); lvi.mask = LVIF_TEXT | LVIF_STATE; lvi.pszText = "2"; lvi.state = LVIS_SELECTED; lvi.stateMask = LVIS_SELECTED; index = ListView_InsertItem(hLV, &lvi);
memset(&lvi, 0, sizeof(lvi)); lvi.mask = LVIF_TEXT; lvi.pszText = "1"; index = ListView_InsertItem(hLV, &lvi);
On Tue, 2 Sep 2003, Eric Pouech wrote:
A few questions: -- LVS_OWNERDATA? (I guess not...)
no
-- LVS_SORTASCENDING or LVS_SORTDESCENDING?
ascending
This is the problem, I'll bet you. Sorting is currently kind of busted. It's one area I wanted to redo, but did not have time to look into it just yet. It's on my TODO :)
Can you remove the sorting and see if that fixes it?
Can you remove the sorting and see if that fixes it?
still the same bug around without sorting the snipnet I sent in previous mail still fails here (insertion is forced at position 0, which is what should happen anyway with sorting being turn on).
A+
On Tue, 2 Sep 2003, Eric Pouech wrote:
still the same bug around without sorting the snipnet I sent in previous mail still fails here (insertion is forced at position 0, which is what should happen anyway with sorting being turn on).
OK, this is tricky, I'll look at it when I get home.
-
Dimitrie O. Paun -
Dimitrie O. Paun -
Eric Pouech