Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 316432 - [widgets] SWT Cocoa, StructuredViewer dispatches selectionChanged on refresh()/setInput()
Summary: [widgets] SWT Cocoa, StructuredViewer dispatches selectionChanged on refresh(...
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 4.0   Edit
Hardware: Macintosh Mac OS X
: P3 normal (vote)
Target Milestone: 3.6.1   Edit
Assignee: Scott Kovatch CLA
QA Contact: Silenio Quarti CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-10 05:11 EDT by Anirudh Sasikumar CLA
Modified: 2010-06-28 13:18 EDT (History)
1 user (show)

See Also:
grant_gayed: review+

Attachments
test case (3.77 KB, application/octet-stream)
2010-06-10 12:14 EDT, Scott Kovatch CLA 		no flags Details
Scott's test case modified to use a ListViewer (with commented out setInput() call to use when the TreeViewer is used) (4.26 KB, application/octet-stream)
2010-06-11 03:46 EDT, Anirudh Sasikumar CLA 		no flags Details
Fix for Tree, List, & Table (2.01 KB, patch)
2010-06-14 18:59 EDT, Scott Kovatch CLA 		no flags Details | Diff
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Anirudh Sasikumar CLA 2010-06-10 05:11:12 EDT 
Build Identifier: 20100603-0907

SWT Cocoa only: Selection listeners of List/Tree fire when the corresponding viewer's refresh/setInput methods are called. In these cases, if the viewer's handleSelect method is overriden, event.item always seem to be null.

Reproducible: Always

Steps to Reproduce:
1. Use a SWT Tree or List.
2. Listen to the TreeViewer/ListViewer's selection by an addSelectionChangedListener or by overriding handleSelect in the viewer.
3. Call refresh() or setInput() on the viewer.

Notice that selectionChanged() will fire even though selection hasn't changed.
Comment 1 Anirudh Sasikumar CLA 2010-06-10 05:19:05 EDT 
This has bad side effects in Adobe Flash Builder: loops of selectionChanged/refresh(), unexpected actions occurring when refresh() is called, etc.
Comment 2 Scott Kovatch CLA 2010-06-10 12:13:15 EDT 
Can you post a test case that's failing? I'm attaching a modified snippet that I think does what you're describing, but the selectionChanged() doesn't fire when you click the button.
Comment 3 Scott Kovatch CLA 2010-06-10 12:14:24 EDT 
Created attachment 171652 [details]
test case

Modified TreeViewer snippet.
Comment 4 Anirudh Sasikumar CLA 2010-06-11 03:42:20 EDT 
Hi Scott,

Thank you for that test case. I tried it out:

1. Change TreeViewer to ListViewer and selectionChanged() will fire on Button press.
2. Using a TreeViewer, change v.refresh() to v.setInput() and selectionChanged() will fire.

These two cases do not occur on windows/carbon.

I'll attach the modified test cases as well.

Thanks,
Anirudh Sasikumar,
Flash Builder Engineering
Comment 5 Anirudh Sasikumar CLA 2010-06-11 03:46:40 EDT 
Created attachment 171696 [details]
Scott's test case modified to use a ListViewer (with commented out setInput() call to use when the TreeViewer is used)

Modified test case.
Comment 6 Scott Kovatch CLA 2010-06-11 12:59:24 EDT 
It looks like Tree.removeAll() is triggering a outlineViewSelectionDidChange event when we call reloadData(). I suspect something similar is happening in Table. Looks like we just need an ignoreSelect = true/false pair around reloadData.
Comment 7 Scott Kovatch CLA 2010-06-14 18:59:38 EDT 
Created attachment 171880 [details]
Fix for Tree, List, & Table

Ignore selection change events when calling removeAll.
Comment 8 Scott Kovatch CLA 2010-06-14 19:00:23 EDT 
Grant, can you review for 3.6.1?
Comment 9 Scott Kovatch CLA 2010-06-28 13:18:53 EDT 
This was the first bug that motivated bug 317054 and bug 317051, so I'm marking it fixed in 3.6.1 and HEAD.