Focused index 0
Selected index 0 selection 1 of 6
Deleting index 0
Deselected index 0
Focused index 1
Delete index 0
self.FocusedItem = 0 is correct.
I think the focus event should be triggered after deletion, not during deletion.
I will report these to the issue tracker, but I want to hear your opinions before that.
Thoughts?
Yes, it does make sense to delete the selected items rather than the focused item to avoid unintentional deletion.
I will fix the sample code, but the point is elsewhere:
The EVT_LIST_ITEM_FOCUSED handler retrieves the index that will be removed during deletion. As a result, the last state after deletion and evt.Index is inconsistent.
I donāt think it is a bug, but it will potentially produce a bug.
Need to distinguish between the contexts of the focus handler: normal focus or focus in deletion.
I donāt think there is anything like a transactional event, i.e. spanning across other events: it would blow up any event system (you may keep your own flag)
what I was more interested in is what are you using this pretty erratic focus for ?
Actually, since I ran into this problem, I noticed that EVT_LIST_ITEM_SELECTED should be used instead of EVT_LIST_ITEM_FOCUSED. Iām not sure if I should open this issue.
where Target is a sort of reference to a stack-frame list.
If a user removes frames from the stack, it dispatches a message with deleted indices.
The ListCtrl subscribes to it and deletes the corresponding items:
def on_frames_removed(self, indices):
for j in reversed(indices):
self.DeleteItem(j)
As DeleteItem triggers EVT_LIST_ITEM_FOCUSED while deletion, it raises an index error.
Thank you for the solution!
I think it would work in most cases. However, it cannot be filtered if the evt.Index during deletion was actually selected during deletion.
Yes, wx can! I think I would go to the wxWidgets issue tracker.
I suppose in the old days there must have been a really messy ādiscussionā about focus & select and this is just a leftover, the smoke, after everyone jumped into the cloudā¦