[PATCH 2/2] comctl32/listbox: Implement LBS_NODATA

[Gabriel Ivăncescu]

On Tue, Nov 20, 2018 at 1:35 PM Huw Davies <huw at codeweavers.com> wrote:
>
> I was getting ahead of the conversation and referring to the
> multi-selection case, where you'd need something allocated.  Sure this
> would end up using more memory than your patch, but it would be a
> stepping stone that should at least help with performance in that case.
>

Right, I don't mind postponing multi-selection to a later patch, I
just don't know how to do it without breaking something that works now
(slowly) or adding more redundant checks that will be removed later.

> As a first step, I'd do what Nikolay proposed, and handle the
> single selection case with a NULL items array.  What does that
> patch look like?
>
> Huw.

Do you mean just testing for LBS_NODATA single-selection and leave
multi-selection alone for now? I can't test for NULL because some
functions, like InsertItem, assume that NULL means "empty listbox" so
it's not a reliable check -- I still have to specialize for
LBS_NODATA. If not, please elaborate.

I can add checks like (excuse email formatting):

if ((descr->items & LBS_NODATA) && !IS_MULTISELECT(descr))
    /* do single-selection LBS_NODATA easy stuff */
else
    /* leave the current code unchanged */

This will work, but those checks will have to be removed later when
multi-sel is implemented of course (I was worried they could be
considered a hack, but if you are okay with them I'll go this route).


Another option is to implement multi-sel listboxes as a byte array and
iterate 1 item at a time which simplifies it somewhat, as a first
patch. Then, I'll profile the difference and implement the bit array
(or something else) in a later patch. Would that be acceptable for a
first patch at least? (the byte array thing)

Those 2 are the options I can think of.