Opened 9 years ago

#22 new defect

Enter on Simulation management dialogs list sometimes misbevhaves

Reported by: flip Owned by: flip
Priority: minor Milestone:
Component: common Version:
Keywords: Cc:

Description

Summary

Double clicking on on a ListCtrl fires EVT_LIST_ITEM_ACTIVATED. Hitting enter also fires EVT_LIST_ITEM_ACTIVATED so it should behave the same as double clicking. In practice there can be a slight difference.

The problem (I think) is that a ListCtrl has both a selection and a focus rectangle, and they don't have to be on the same item. When enter is pressed, it activates the item with the focus which is not necessarily the item that's selected. Double clicking forces the two to be in sync which is why this problem only occurs when using the keyboard.

Recreate

Here's how to recreate the problem under Linux or OS X. Under OS X it's a bizarre experience since the focus rect isn't drawn at all.

  1. Open one of the Simulation management dialogs (e.g. metabolite management).
  2. Double click on an item in the list other than the first item. For my example I'll use the 6th item in the list (acetate). Simulation will open the editing dialog.
  3. You don't need to make any changes, just click OK on the editing dialog. Simulation will close the dialog, refresh the list of metabs in the mgmt dialog and reselect the item that was selected. At this point the bug has been triggered and it is visible in GTK (but not under OS X) because the focus rect is on the first item rather than the selected item.
  4. Note that acetate is still selected. Hit enter. Simulation will open the editing dialog, but with the first metab in the list (GPC-gp) populating the dialog.

The attached 3x magnified screenshot from Ubuntu taken between steps 3 & 4 clearly shows that the focus rect is on the first item while the selection is on the 6th.

Under Windows, the bug manifests itself slightly differently. Here's how to demo it.

  1. Open one of the Simulation management dialogs (e.g. metabolite management).
  2. Single click on an item in the list other than the first item. For my example I'll use the 6th item in the list (acetate).
  3. Press your keyboard's down arrow. Note that the selection (and focus rect) move down one item to alanine as expected.
  4. Press your keyboard's up arrow twice. Note that the selection (and focus rect) move up one item to acetate and then up one more to NAAG-truncated-siemens, all as expected.
  5. Double click on acetate. Simulation will open the editing dialog.
  6. You don't need to make any changes, just click OK on the editing dialog. Simulation will close the dialog, refresh the list of metabs in the mgmt dialog and reselect the item that was selected. If you look very carefully, you can see that the focus rect that should be on acetate is nowhere to be found.
  7. Press your keyboard's down arrow. The selection and focus rect jump to the first item in the list.

Severity

Severity is minor. Really confusing when it happens, but it won't happen often since it requires using the keyboard to navigate or open an item immediately after a refresh of the list.

Note that the initial list refresh (when the mgmt dialog is first opened) isn't a problem since the first item in the list is what's selected by default.

Resolution

I don't think this is a bug in wxPython or wxWidgets. It's easy to say that the focus rect should always follow the selection, especially for the way we're using ListCtrls which is basically as fancy listbox. But if someone uses a ListCtrl to implement something like a spreadsheet I could see that it might be very desirable to have the focus rect move independently of the selection(s).

In common.wx.util.select_list_ctrl_items() currently performs all (I hope) list item selection in our mgmt dialogs. Currently it calls list_ctrl.Select() to select an item. I think that adding a call to I think that calling list_ctrl.SetItemState() to also set the focus would ensure that the focus rect and selection are in sync.

That mitigates the problem but doesn't fix it. First of all, it only fixes the problem for code that calls common.wx.util.select_list_ctrl_items(). Any code that calls list_ctrl.Select() on its own will also have to implement the additional list_ctrl.SetItemState() call or get bitten by this bug.

Attachments (1)

Screen shot 2010-12-28 at 2.17.17 PM.png (88.0 KB) - added by flip 9 years ago.

Download all attachments as: .zip

Change History (1)

Changed 9 years ago by flip

Note: See TracTickets for help on using tickets.