Which is bester , LVS_OWNERDATA or LPSTR_TEXTCALLBACK ?

Hello , everyone.

I see two approach that make application maintain data rather than the
control.

1)  Use LVS_OWNERDATA style:

    m_list.Create(WS_CHILD|WS_VISIBLE|LVS_REPORT|LVS_OWNERDATA,...);

   then handle the LVN_GETDISPINFO message.


2)  NO LVS_OWNERDATA ! But set pszText member of LV_ITEM to
LPSTR_TEXTCALLBACK, and handle LVN_GETDISPINFO message.
    like:

    LV_ITEM Item;
    Item.lParam   = (LPARAM) pItem;    // Store the pointer to the object
    Item.pszText  = LPSTR_TEXTCALLBACK;         // using callbacks to get
the text
    Item.mask     = LVIF_TEXT | LVIF_PARAM;     // lParam and pszText fields
active
    Item.iItem    = nInsertPos;                 // position to insert new
item
    Item.iSubItem = 0;

    VERIFY(InsertItem(&Item)


I wonder what is the difference between these two method.

Which one would you prefer? Is there any difference?


Thanks in advance!
youhua wang


0
12/11/2004 6:21:34 AM
vc.mfc 33608 articles. 0 followers. Follow

6 Replies
1334 Views

Similar Articles

[PageSpeed] 25

youhua.wang wrote:

>Hello , everyone.
>
>I see two approach that make application maintain data rather than the
>control.
>
>1)  Use LVS_OWNERDATA style:
>
>    m_list.Create(WS_CHILD|WS_VISIBLE|LVS_REPORT|LVS_OWNERDATA,...);
>
>   then handle the LVN_GETDISPINFO message.
>
>
>2)  NO LVS_OWNERDATA ! But set pszText member of LV_ITEM to
>LPSTR_TEXTCALLBACK, and handle LVN_GETDISPINFO message.
>    like:
>
>    LV_ITEM Item;
>    Item.lParam   = (LPARAM) pItem;    // Store the pointer to the object
>    Item.pszText  = LPSTR_TEXTCALLBACK;         // using callbacks to get
>the text
>    Item.mask     = LVIF_TEXT | LVIF_PARAM;     // lParam and pszText fields
>active
>    Item.iItem    = nInsertPos;                 // position to insert new
>item
>    Item.iSubItem = 0;
>
>    VERIFY(InsertItem(&Item)
>
>
>I wonder what is the difference between these two method.
>
>Which one would you prefer? Is there any difference?

There's a big difference. When you use the LVS_OWNERDATA style, the listview
doesn't maintain the list of items beyond the information necessary to
record which items are selected. This means that to add and delete items,
you update your own data structure and use the LVM_SETITEMCOUNT message to
tell the listview how many items there are. In addition, you need to figure
out which part of the list display needs updating, if any. When you don't
use LVS_OWNERDATA, the listview maintains its own list of the items, and you
use messages like LVM_INSERTITEM and  LVM_DELETEITEM to add and delete
items, respectively. If you're not maintaining an array of items but
allocating each individually, as you seem to be doing, and using the
listview as your container data structure, then the approach (2) is fine. If
you were maintaining your own array, such that the listview could be
considered a simple view onto this array, approach (1) would use less memory
than (2), but whether or not this savings is significant of course depends
on the number of items in your list.

-- 
Doug Harrison
Microsoft MVP - Visual C++
0
dsh (2498)
12/11/2004 4:33:05 PM
Thanks, Doug.


I see some example that call both appoach (1) and approach(2) fullfil a
"virtual list". Do you  think agree this ? What is definition of "virtual
list"?

Though approach (2 at maintain it own data, but  it still send
LVN_GETDISPINFO
to get data when  set Item.pszText  = LPSTR_TEXTCALLBACK,
could you explain what kind of data  is maintain in the listview when use
approach (2) ?

Best Regard!

youhua wang


"Doug Harrison [MVP]" <dsh@mvps.org> wrote in message
news:hv7mr0dkhgvg59goriph7o11so5gegaj6v@4ax.com...
> youhua.wang wrote:
>
> >Hello , everyone.
> >
> >I see two approach that make application maintain data rather than the
> >control.
> >
> >1)  Use LVS_OWNERDATA style:
> >
> >    m_list.Create(WS_CHILD|WS_VISIBLE|LVS_REPORT|LVS_OWNERDATA,...);
> >
> >   then handle the LVN_GETDISPINFO message.
> >
> >
> >2)  NO LVS_OWNERDATA ! But set pszText member of LV_ITEM to
> >LPSTR_TEXTCALLBACK, and handle LVN_GETDISPINFO message.
> >    like:
> >
> >    LV_ITEM Item;
> >    Item.lParam   = (LPARAM) pItem;    // Store the pointer to the object
> >    Item.pszText  = LPSTR_TEXTCALLBACK;         // using callbacks to get
> >the text
> >    Item.mask     = LVIF_TEXT | LVIF_PARAM;     // lParam and pszText
fields
> >active
> >    Item.iItem    = nInsertPos;                 // position to insert new
> >item
> >    Item.iSubItem = 0;
> >
> >    VERIFY(InsertItem(&Item)
> >
> >
> >I wonder what is the difference between these two method.
> >
> >Which one would you prefer? Is there any difference?
>
> There's a big difference. When you use the LVS_OWNERDATA style, the
listview
> doesn't maintain the list of items beyond the information necessary to
> record which items are selected. This means that to add and delete items,
> you update your own data structure and use the LVM_SETITEMCOUNT message to
> tell the listview how many items there are. In addition, you need to
figure
> out which part of the list display needs updating, if any. When you don't

> use LVS_OWNERDATA, the listview maintains its own list of the items, and
you
> use messages like LVM_INSERTITEM and  LVM_DELETEITEM to add and delete
> items, respectively. If you're not maintaining an array of items but
> allocating each individually, as you seem to be doing, and using the
> listview as your container data structure, then the approach (2) is fine.
If
> you were maintaining your own array, such that the listview could be
> considered a simple view onto this array, approach (1) would use less
memory
> than (2), but whether or not this savings is significant of course depends
> on the number of items in your list.
>
> --
> Doug Harrison
> Microsoft MVP - Visual C++


0
12/13/2004 5:17:38 AM
youhua.wang wrote:

>Thanks, Doug.
>
>
>I see some example that call both appoach (1) and approach(2) fullfil a
>"virtual list". Do you  think agree this ? What is definition of "virtual
>list"?

A "virtual listview" is one that doesn't contain any item data. Thus, only
(2) (LVS_OWNERDATA) implements a virtual list. In the case of (1)
(LPSTR_TEXTCALLBACK), the listview maintains data for each item, some subset
of the LVITEM data members and possibly other state.

>Though approach (2 at maintain it own data, but  it still send
>LVN_GETDISPINFO
>to get data when  set Item.pszText  = LPSTR_TEXTCALLBACK,
>could you explain what kind of data  is maintain in the listview when use
>approach (2) ?

An LVS_OWNERDATA listview does not maintain any item data. However, the
listview does keep track of which items are selected, which can be optimized
in various ways. I doubt it simply maintains an array of bits, one per item,
for this purpose, because in most cases, a pair of ints defining a single
range of selected items is sufficient. (As a listview user, I don't think
I've ever created a multiple selection of more than a handful of ranges,
because I usually mess up and end up deselecting everything before I create
very many selections. :) So I don't see it getting pathological except
programmatically.)

-- 
Doug Harrison
Microsoft MVP - Visual C++
0
dsh (2498)
12/13/2004 12:54:31 PM
"Doug Harrison [MVP]" <dsh@mvps.org> wrote in message
news:7p3rr0tf16qs9i32apnhubgihp9rnteafp@4ax.com...
> youhua.wang wrote:
>
> >Thanks, Doug.
> >
> >
> >I see some example that call both appoach (1) and approach(2) fullfil a
> >"virtual list". Do you  think agree this ? What is definition of "virtual
> >list"?
>
> A "virtual listview" is one that doesn't contain any item data. Thus, only
> (2) (LVS_OWNERDATA) implements a virtual list. In the case of (1)
> (LPSTR_TEXTCALLBACK), the listview maintains data for each item, some
subset
> of the LVITEM data members and possibly other state.
>
> >Though approach (2 at maintain it own data, but  it still send
> >LVN_GETDISPINFO
> >to get data when  set Item.pszText  = LPSTR_TEXTCALLBACK,
> >could you explain what kind of data  is maintain in the listview when use
> >approach (2) ?
>
> An LVS_OWNERDATA listview does not maintain any item data. However, the
> listview does keep track of which items are selected, which can be
optimized
> in various ways. I doubt it simply maintains an array of bits, one per
item,
> for this purpose, because in most cases, a pair of ints defining a single
> range of selected items is sufficient. (As a listview user, I don't think
> I've ever created a multiple selection of more than a handful of ranges,
> because I usually mess up and end up deselecting everything before I
create
> very many selections. :) So I don't see it getting pathological except
> programmatically.)
>

I believe you can select random items in a list control (and therefore a
list view?) by using the Control Key / Left Mouse button combination.


0
billt61 (145)
12/14/2004 1:31:28 AM
Bill Thompson wrote:

>I doubt it simply maintains an array of bits, one per item,
>> for this purpose, because in most cases, a pair of ints defining a single
>> range of selected items is sufficient. (As a listview user, I don't think
>> I've ever created a multiple selection of more than a handful of ranges,
>> because I usually mess up and end up deselecting everything before I
>create
>> very many selections. :) So I don't see it getting pathological except
>> programmatically.)
>>
>
>I believe you can select random items in a list control (and therefore a
>list view?) by using the Control Key / Left Mouse button combination.

That's what I was talking about. (By "pathological", I meant a listview in
which, say, every other item out of a million items is selected. This would
greatly hinder optimization of a virtual listview's multiple selection info,
but most listview usage isn't like that.)

-- 
Doug Harrison
Microsoft MVP - Visual C++
0
dsh (2498)
12/14/2004 2:21:25 AM
Thanks your explanation, Doug .



"Doug Harrison [MVP]" <dsh@mvps.org> wrote in message
news:r8jsr0hjppfmprm5php67v54d8p4ikilus@4ax.com...
> Bill Thompson wrote:
>
> >I doubt it simply maintains an array of bits, one per item,
> >> for this purpose, because in most cases, a pair of ints defining a
single
> >> range of selected items is sufficient. (As a listview user, I don't
think
> >> I've ever created a multiple selection of more than a handful of
ranges,
> >> because I usually mess up and end up deselecting everything before I
> >create
> >> very many selections. :) So I don't see it getting pathological except
> >> programmatically.)
> >>
> >
> >I believe you can select random items in a list control (and therefore a
> >list view?) by using the Control Key / Left Mouse button combination.
>
> That's what I was talking about. (By "pathological", I meant a listview in
> which, say, every other item out of a million items is selected. This
would
> greatly hinder optimization of a virtual listview's multiple selection
info,
> but most listview usage isn't like that.)
>
> --
> Doug Harrison
> Microsoft MVP - Visual C++


0
12/16/2004 6:06:41 AM
Reply:

Similar Artilces:

List View style LVS_EX_CHECKBOXES | LVS_OWNERDATA
LVS_EX_CHECKBOXES does not seem to work in combination with LVS_OWNERDATA. How can i fix that? ...

Which is bester , LVS_OWNERDATA or LPSTR_TEXTCALLBACK ?
Hello , everyone. I see two approach that make application maintain data rather than the control. 1) Use LVS_OWNERDATA style: m_list.Create(WS_CHILD|WS_VISIBLE|LVS_REPORT|LVS_OWNERDATA,...); then handle the LVN_GETDISPINFO message. 2) NO LVS_OWNERDATA ! But set pszText member of LV_ITEM to LPSTR_TEXTCALLBACK, and handle LVN_GETDISPINFO message. like: LV_ITEM Item; Item.lParam = (LPARAM) pItem; // Store the pointer to the object Item.pszText = LPSTR_TEXTCALLBACK; // using callbacks to get the text Item.mask = LVIF_TEXT | LVIF_PARAM; // l...

NM_CUSTOMDRAW and LVS_OWNERDATA
Hi all, I have a question: I am using a virtual list control (LVS_OWNERDATA), and trying to handle the NM_CUSTOMDRAW message to draw something custom in one of the columns -- problem is, the NM_CUSTOMDRAW message only gets fired once for each item, rather than once for each column. Anyone know how to work around this? Thanks :) Casey This is normal behavior, you will need to draw the entire row when processing the NM_CUSTOMDRAW message. -- ============ Frank Hickman NobleSoft, Inc. ============ "Casey Langen" <avatar5d@hotmail.com> wrote in message news:yQQnb.17925$vi6.1...

RE: NV_CUSTOMDRAW and LVS_OWNERDATA
This is normal behavior, you will need to draw the entire row when processing the NM_CUSTOMDRAW message. D0h. Thats the answer I was looking for :) Cheers! Casey ============ Frank Hickman NobleSoft, Inc. ============ "Casey Langen" <avatar5d@hotmail.com> wrote in message news:yQQnb.17925$vi6.10586@newssvr29.news.prodigy.com... > Hi all, I have a question: > > I am using a virtual list control (LVS_OWNERDATA), and trying to handle the NM_CUSTOMDRAW message to draw something custom in one of the columns -- problem is, the NM_CUSTOMDRAW message only gets fired once f...

LVS_OWNERDATA and NM_CUSTOMDRAW with CListCtrl == slow?
Forgive me if this is a near duplicate post... anyway, I'm trying to use NM_CUSTOMDRAW to draw all the items manually in a virtual CListCtrl (a list control with LVS_OWNERDATA). The problem is that my method is very slow and sluggish feeling compared to the way windows does it, and I don't know why. Keeping in mind that NM_CUSTOMDRAW is only fired once per item, due to the LVS_OWERDATA style, rather than once per sub item, perhaps someone can explain to me what I'm doing wrong? Heres the code: void CMusikPlaylistCtrl::OnLvnGetdispinfo(NMHDR *pNMHDR, LRESULT *pResult) { NMLVDIS...

LVS_OWNERDATA and LVM_ENABLEGROUPVIEW Not Compatible???
Hi, I have a list-view control that is working with groups quite well. However, when I turn on the LVS_OWNERDATA style, I can get everything working again BUT the groups. Does anyone know if this is unsupported? Can this be done? Any thoughts? Thanks, Anthony ...

CListCtrl, EnsureVisible and LVS_OWNERDATA style
Hi all, I have a CListCtrl in a DialogBox. This CListCtrl has the LVS_OWNERDATA style. I call the function Ensure visible to show a particular item, and I have two differents behaviours : - If I DO NOT click in the ListCtrl, then, it works fine, the list si scrolled to the correct item - If I click in the ListCtrl, then, any call to EnsureVisible scrolls the List to the first item. Does anybody have an idea to explain what is happening ? Ask for precisions if necessary. Thanks in advance, Dansk Oh dear... I found it, it was a stupid side effect. CListCtrl works fine in this case... ...

LVS_OWNERDATA VS Label edit
How to implement item label edit in virtual list ctrl? I'v used SetItemText(...) in LVN_ENDLABELEDIT message handler, but got a assertion. Must I handle the label edit inside LVN_GETDISPINFO? On Wed, 9 Nov 2005 11:18:15 +0800, "liysh" <liysh@intertimes.com.cn> wrote: >How to implement item label edit in virtual list ctrl? >I'v used SetItemText(...) in LVN_ENDLABELEDIT message handler, but got a >assertion. >Must I handle the label edit inside LVN_GETDISPINFO? It doesn't make sense to use SetItemText in a virtual listview, because the listview doesn&...

Need some answers regarding CListCtrl and LVS_OWNERDATA style (advanced)
Hi, I have created my own version of a CListView class where the embedded listctrl has the LVS_OWNERDATA style. I understand how to implement this style and have no problems creating / using this, apart from the fact it is SLOW!!! Below is what I am doing in the LVN_GETDISPINFO handler:- void CNewTharFrontView::OnGetdispinfoList(NMHDR* pNMHDR, LRESULT* pResult) { NMLVDISPINFO* pDispInfo = (NMLVDISPINFO*)pNMHDR; if(pDispInfo->item.mask & LVIF_TEXT) { GetItemText(pDispInfo->item.iItem, pDispInfo->item.iSubItem); strcpy(pDispInfo->item.pszText, m_sGetText); ...

LVS_OWNERDATA
Hi all, I want to use features supported in windows XP for CListCtrl as: Thumbnail, Insertion mark;.... Any one can tell me the way or share me experience? Thanks! ...