Re: #4541: Generate events for multiple selections in virtual wxListCtrl

16 views
Skip to first unread message

wxTrac

unread,
Jul 29, 2020, 5:04:31 AM7/29/20
to wx-...@googlegroups.com
#4541: Generate events for multiple selections in virtual wxListCtrl
-----------------------+------------------------------------------------
Reporter: tibosoft | Owner:
Type: defect | Status: confirmed
Priority: normal | Milestone: 3.2.0
Component: wxMSW | Version:
Resolution: | Keywords: wxListCtrl virtual selection event
Blocked By: | Blocking:
Patch: 0 |
-----------------------+------------------------------------------------
Changes (by ajm_flonidan):

* cc: ajm@… (added)


Comment:

To work around this, I've managed to track selections by handling
EVT_LIST_ITEM_SELECTED, EVT_LIST_ITEM_DESELECTED ''and''
EVT_LIST_ITEM_FOCUSED. Experimentally, it seems like that covers all
situations where the selection changes, but it doesn't inspire confidence.

It is not a strict necessity to have an event type that can represent a
range: Enumerating the selection using
GetNextItem(..wx.LIST_STATE_SELECTED) in the event handler provides all
then necessary information. Yes, it's O(n), and it would be nice to avoid
that, but when done from within the event handler, at least the O(n)
operation is opt-in.

The big drawback with that approach is that EVT_LIST_ITEM_[DE]SELECTED is
issued once for every item [de]selected. If the virtual ListCtrl contains
a million elements that are selected at once, then that's a million
separate events. That wouldn't be too bad if only there was a way to tell
which event is the last one, so you don't have to enumerate the selection
a million times, but just once.

An EVT_LIST_SELECTION_CHANGED event that's issued just once for each user
interaction that might change the selection, would be a huge improvement,
even if there's no information about the specifics of the change in the
event object.

--
Ticket URL: <https://trac.wxwidgets.org/ticket/4541#comment:6>

wxTrac

unread,
Feb 20, 2021, 2:34:43 PM2/20/21
to wx-...@googlegroups.com
#4541: Generate events for multiple selections in virtual wxListCtrl
-----------------------+------------------------------------------------
Reporter: tibosoft | Owner:
Type: defect | Status: confirmed
Priority: normal | Milestone: 3.2.0
Component: wxMSW | Version:
Resolution: | Keywords: wxListCtrl virtual selection event
Blocked By: | Blocking:
Patch: 0 |
-----------------------+------------------------------------------------
Changes (by whalley):

* cc: mark@… (added)


Comment:

Any view from the team on the prioritization of this issue? It has been
around for 13 years now.

At present I'm struggling to determine how many / which rows are selected
from a virtual control using any of the EVT_LIST_ITEM_SELECTED,
EVT_LIST_ITEM_DESELECTED, EVT_LIST_ITEM_FOCUSED events.

Is there any known work around?

--
Ticket URL: <https://trac.wxwidgets.org/ticket/4541#comment:7>

wxTrac

unread,
Feb 20, 2021, 3:47:50 PM2/20/21
to wx-...@googlegroups.com
#4541: Generate events for multiple selections in virtual wxListCtrl
-----------------------+------------------------------------------------
Reporter: tibosoft | Owner:
Type: defect | Status: confirmed
Priority: normal | Milestone: 3.2.0
Component: wxMSW | Version:
Resolution: | Keywords: wxListCtrl virtual selection event
Blocked By: | Blocking:
Patch: 0 |
-----------------------+------------------------------------------------

Old description:

> Hi,
>
> Virtual wxListCtrl for some reason ignore multiple selection events. Bugs
> 1729348, 732104 and 594072 all refer to this problem, and they have been
> closed by stating that this information takes O(n) to fetch.
>
> Under Windows - at least - this is wrong. There exist a message
> (LVN_ODSTATECHANGED) that lets the control know when multiple items are
> selected. Coupling this event with the traditional LVN_ITEMCHANGED would
> let us know the actual selection, even in virtual list controls.
>
> As of now, the [de]selection events are firing, but they are broken. I
> think that they should either be removed completely or fixed (or
> documented as buggy).
>
> I am currently writing a fix, but it requires a new event type that will
> contain the range of items selected with shift+click.
> I'll keep you guys informed how I get on.
>
> However, I don't know how this can be implemented in other ports - GTK,
> Carbon and such. Issues with those ports might have been the reason why
> the operation has been said to take O(n) in the first place.
>
> Thibault

New description:

Hi,

Virtual wxListCtrl for some reason ignore multiple selection events. Bugs
1729348, 732104 and 594072 all refer to this problem, and they have been
closed by stating that this information takes O(n) to fetch.

Under Windows - at least - this is wrong. There exist a message
(LVN_ODSTATECHANGED) that lets the control know when multiple items are
selected. Coupling this event with the traditional LVN_ITEMCHANGED would
let us know the actual selection, even in virtual list controls.

As of now, the [de]selection events are firing, but they are broken. I
think that they should either be removed completely or fixed (or
documented as buggy).

I am currently writing a fix, but it requires a new event type that will
contain the range of items selected with shift+click.
I'll keep you guys informed how I get on.

However, I don't know how this can be implemented in other ports - GTK,
Carbon and such. Issues with those ports might have been the reason why
the operation has been said to take O(n) in the first place.

Thibault

--

Comment (by vadz):

This is clearly important, but it's not that simple to fix because we
first need to decide what exactly to do here, knowing that we ideally we'd
like to not only have consistent behaviour between the different
platforms, but also between `wxListCtrl` and `wxDataViewCtrl`, and then
actually implement it.

I wish I could guarantee I'll do it soon, but I honestly can't do it. I'll
try to do my best, but whether this is going to be enough to do it before
3.2 or not, I have no idea.

--
Ticket URL: <https://trac.wxwidgets.org/ticket/4541#comment:8>

wxTrac

unread,
Feb 21, 2021, 10:22:18 AM2/21/21
to wx-...@googlegroups.com
#4541: Generate events for multiple selections in virtual wxListCtrl
-----------------------+------------------------------------------------
Reporter: tibosoft | Owner:
Type: defect | Status: confirmed
Priority: normal | Milestone: 3.2.0
Component: wxMSW | Version:
Resolution: | Keywords: wxListCtrl virtual selection event
Blocked By: | Blocking:
Patch: 0 |
-----------------------+------------------------------------------------
Changes (by dconnet):

* cc: dcon@… (added)


Comment:

Sounds like this is related (maybe the same) as #19017 that I recently
wrote.

--
Ticket URL: <https://trac.wxwidgets.org/ticket/4541#comment:9>

wxTrac

unread,
Sep 22, 2021, 4:33:12 PM9/22/21
to wx-...@googlegroups.com
#4541: Generate events for multiple selections in virtual wxListCtrl
-----------------------+------------------------------------------------
Reporter: tibosoft | Owner:
Type: defect | Status: confirmed
Priority: normal | Milestone: 3.2.0
Component: wxMSW | Version:
Resolution: | Keywords: wxListCtrl virtual selection event
Blocked By: | Blocking:
Patch: 0 |
-----------------------+------------------------------------------------
Changes (by dconnet):

* cc: dcon@… (removed)


Comment:

I've noticed that when I use shift-click to select a number of items, a
SELECTED message is not generated, only a FOCUSED. On Windows, this is ok
because the items do get selected (so processing the FOCUSED as a work
around works). However, on a Mac, the underlying items are not selected
when the focused message arrives, which leaves associated controls in the
wrong state. (For instance, editing a single item is supported, but
editing multiple is not)

--
Ticket URL: <https://trac.wxwidgets.org/ticket/4541#comment:10>
Reply all
Reply to author
Forward
0 new messages