[PATCH v3 6/7] comctl32/listbox: Implement LBS_NODATA for single-selection listboxes

Huw Davies huw at codeweavers.com
Wed Nov 21 12:07:21 CST 2018


On Wed, Nov 21, 2018 at 07:45:01PM +0200, Gabriel Ivăncescu wrote:
> On Wed, Nov 21, 2018 at 7:33 PM Huw Davies <huw at codeweavers.com> wrote:
> >
> > On Wed, Nov 21, 2018 at 07:26:05PM +0200, Gabriel Ivăncescu wrote:
> > > On Wed, Nov 21, 2018 at 7:04 PM Huw Davies <huw at codeweavers.com> wrote:
> > > > Plewase do this.  Part of the reason this patch is proving difficult
> > > > is the messy allocation scheme that already exists.  Let's tidy
> > > > that up first.  Everything should fall back to a common allocator,
> > > > once that's done, it becomes easy to alter the size that that
> > > > will allocate if we shift to using a byte array for the nodata
> > > > multiselect case.
> > > >
> > >
> > > The only difference I can see is that the custom allocator deals with
> > > sizes in bytes, instead of sizes in "number of items", otherwise
> > > there's no way to share it. I'll try something like that, hope that's
> > > fine.
> >
> > The common allocator would take number of items, it would then pass
> > that on to heap_realloc() having done the appropriate multiplication.
> >
> 
> But that's exactly what InitStorage is currently doing (barring the
> bug it has, since my bugfix got rejected :-/ ), so why not just use
> InitStorage?

No it isn't, InitStorage only increments the storage.

> My concern is: how would that be "common" then for the case where we
> need to allocate items *without* multiplying by anything?

It will always multiply by something, that number might be sizeof(BYTE).
The function will decide what to multiply by based on descr->style.  This
really isn't that complicated...

Huw.



More information about the wine-devel mailing list