[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