Community
Participate
Working Groups
Build Identifier: 20110615-0604 In an table initialized with SWT.MULTI, when selecting a single element that was part of a multiple selection, will give a wrong selection during the change notifications (SelectionListener::widgetSelected). Not sure if it is related, but the gui updates the selection only after the widgetSelected methods have been called. Reproducible: Always Steps to Reproduce: 1. Run the attached code 2. Select two or more items in the table 3. without deselecting first, click on the last item of the selection 4. Message in the console shows the items selected at point 2
Created attachment 201772 [details] Example code to verify the problem
*** Bug 354969 has been marked as a duplicate of this bug. ***
This seems quite severe since commands using selections will use elements that the user didn't intend to be used.
*** Bug 379090 has been marked as a duplicate of this bug. ***
*** Bug 343778 has been marked as a duplicate of this bug. ***
IMHO, this is a very serious bug! Imagine a file manager where the user has 5 files selected. Then she selects one of these files and invokes Delete. All 5 files will be deleted. Please raise the priority to Critical and solve it quickly! Thanks in advance.
Possible workaround: On the Mac on which I tested this, Table.getSelection will return the new, "correct" selection about 500 ms after widgetSelected is called. That means if you want to get a useful selection from the table, you can wrap the code inside your widgetSelected method in a Display.timerExec call with a delay of more than 500 ms. (That also means Display.asyncExec won't work.)
Created attachment 220726 [details] patch The problem is that the selection event is sent before the selection is updated in the view. So, calling getSelection() in the Selection listener returns the incorrect value. The patch deselects the items manually before the selection event is sent. Silenio, can you please review the patch?
(In reply to comment #8) > Created attachment 220726 [details] > patch > > The problem is that the selection event is sent before the selection is > updated in the view. So, calling getSelection() in the Selection listener > returns the incorrect value. The patch deselects the items manually before > the selection event is sent. > Silenio, can you please review the patch? We cannot deselect the items in mouseDown(), otherwise we will not be able to drag and drop multiple items ever. Add this line to the sample, select multiple items and start dragging. DragSource dragSource = new DragSource(table, SWT.NONE); The delayed deselection is a Mac behaviour. It happens in Finder too. I think what is wrong here is that we are not send a selection event when that happens. Selection can never change without a SWT.Selection event.
Created attachment 220751 [details] possible patch Lakshmi, would this patch work? It still sends the extra selection event when clicking in an item already selected (selection count=1). Otherwise, it sends the selection event when the items are deselected (after the cocoa timer expire).
(In reply to comment #10) > Created attachment 220751 [details] > possible patch > > Lakshmi, would this patch work? > > It still sends the extra selection event when clicking in an item already > selected (selection count=1). Otherwise, it sends the selection event when > the items are deselected (after the cocoa timer expire). Silenio, I tried the patch. This causes the Selection event to be sent after MouseUp. (and cause some old bugs like Bug 289483). I also noticed that the Selection event is not sent until I move the mouse or perform some other action.
(In reply to comment #9) > We cannot deselect the items in mouseDown(), otherwise we will not be able > to drag and drop multiple items ever. Add this line to the sample, select > multiple items and start dragging. > > DragSource dragSource = new DragSource(table, SWT.NONE); > Thanks Silenio, I tried this and can see the problem with deselecting items on mouseDown(). I'm thinking of doing this in mouseUp() instead, before sending the MouseUp event. This way the order of events can be maintained and Drag case can also be handled.
Created attachment 220785 [details] patch-2 patch based on above comments.
(In reply to comment #13) > Created attachment 220785 [details] > patch-2 > > patch based on above comments. Patch looks good.
Thanks Silenio! I'll commit this soon after M2.
Pushed to master > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=bc8036435837353efa5da8c19b6a3003dbb86045 Silenio, I noticed that an extra selection event is sent after MouseUp. I'm not sure where it is coming from though.
Committed fix for the extra selection event to master > git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=81fc4fbb51e1206ed8a526050d3bdcad1a2f0496
verified in I20121030-2000
