While trying to get the debug options dialog working, I noticed that the win32 interface…
Vincent Snijders wrote 45 lines
On Mon, 08 Dec 2003 00:30:56 +0100
Marc Weustink wrote:
> At 22:23 7-12-2003, Vincent Snijders wrote:
> >On Sun, 07 Dec 2003 18:41:49 +0100
> >Marc Weustink wrote:
> >
> > > At 10:47 7-12-2003, Vincent Snijders wrote:
> > > >Hi,
> > > >
> > > >While trying to get the debug options dialog working, I noticed
> > > >that the win32 interface doesn't store the objects associated
> > > >with a list item in a CheckedListBox (or ListBox).
> > > >
> > > >While implementing this the obvious way with LB_SETITEMDATA. This
> > > >works for TListBox, but not for TCheckListBox, because
> > > >TCheckListBox stores it Checked property in the item data.
> > >
> > > Yep.
> > >
> > > >Any suggestions to solve this? Storing a heap-allocated record
> > > >with object and selected fields in the item data is one
> > > >possibility, but I fear the bookkeeping involved. Any suggestions
> > > >are wellcome.
> > >
> > > I had the samme problem when I introduced the CheckList. Delphi
> > > uses the TCheckListBoxDataWrapper class to handle this. We can do
> > > it the same way, but like you said, you need some bookkeeping.
> > > Another way is to move the checkstate to the interface, so that
> > > Item.Dat is just userdata. The TCheckListBoxDataWrapper class
> > > isn't published, so I have no problems with that.
> >Maybe I don't understand you, but at the moment checkstate is stored
> >in the interface, together with item text and item object. So where
> >do you want to move the checkstate to?
> >Do you mean to move the storage of checked state to the LCL?
>
> No, I was just wondering why the checked state was stored as data. The
> only thing I could think of was that it wasn't stored (or isn't
> accessible) through the interface. So if there is a function like
> LCLIsItemChecked, I see no reason to store it in the LCL as well.
> (Ehm, I don't know if there is a function like that, I've no access to
> all source at the moment)
FYI, at the moment checked state is already stored in the interface and
set and retrieved by the LCL with the LM_CLB_SETCHECKED and
LM_CLB_GETCHECKED messages.
We might want to change these to direct calls in the future :)
Show quoted text 8 lines
The Items stringlist is also stored in the interface. The problem I have
now is, that for each item in a checked listbox three things need to be
stored: string, object and checkstate. The win32 api has only place for
2: string (item text) and object (item data).
If you don't want to move the storage of checkedstate to the LCL, I see
no other way than to store the checkedstate and the object together in
item data, which will need some taking care to prevent memory
leaks when deleting items or clearing the list.
Thats true. IMO this is an interface issue. So for win32 the item data is in fact a record with a data pointer and a checked bool.
If you see another way, please let me know. Otherwise I will implement it this way this week.
AFAIK there is no other option. And indeed we have to take care of releasing data on WM_DESTROY and romoving items.
Maybe we should use data in a mixed way. Initially only as bool (0 or 1) and as soon as Data is used, as a pointer to a rec.
Marc