Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 153669

Summary:	[Viewers] Table.setSelection doesn't fire selection event anymore
Product:	[Eclipse Project] Platform	Reporter:	Giovanni Quarella <giovanni>
Component:	UI	Assignee:	Platform-UI-Inbox <Platform-UI-Inbox>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	bokowski
Version:	3.2
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description Giovanni Quarella

2006-08-12 13:15:05 EDT

I'm just using eclipse-SDK-N20060812-0010-win32.zip, but my code:
viewer.getTable().setSelection(nextSelectedIndex);
doesn't fire selection event as before.
So I must add the following line to force the event:
viewer.setSelection(viewer.getSelection())

But I'm using ILazyContentProvider and in the doc you read:

The TableViewer implmentation of this method is ineffecient for the ILazyContentProvider as lookup is done by indices rather than elements and may require population of the entire table in worse case. 

(the Javadoc contains errors like implmentation without 'e', ineffecient, etc.)

Comment 1 Boris Bokowski

2006-08-14 16:52:51 EDT

(In reply to comment #0)
> I'm just using eclipse-SDK-N20060812-0010-win32.zip, but my code:
> viewer.getTable().setSelection(nextSelectedIndex);
> doesn't fire selection event as before.

In which release was a selection event fired?

Comment 2 Giovanni Quarella

2006-08-20 13:03:00 EDT

(In reply to comment #1)
> (In reply to comment #0)
> > I'm just using eclipse-SDK-N20060812-0010-win32.zip, but my code:
> > viewer.getTable().setSelection(nextSelectedIndex);
> > doesn't fire selection event as before.
> In which release was a selection event fired?

When I used eclipse-SDK-N20060709-0010-win32 all worked correctly.
In one view I put

getSite().setSelectionProvider(viewer);

In the other

OtherView extends ViewPart implements ISelectionListener
...

public void selectionChanged(IWorkbenchPart part, ISelection selection) {
		System.out.println("selectionChanged");
	}

In N20060812 viewer.getTable().setSelection(nextSelectedIndex); doesn't fire anymore like before the call to selectionChanged.

I have the same problem when I call viewer.getTable().setTopIndex(0)
In N20060709 version the first table item 0 is selected, in N20060812 the table item 0 becomes visible, but it's not selected.
I'm using a ILazyContentProvider and in the tableviewer doc of setSelection you read
Use Table#setSelection(int[] indices) and Table#showSelection() if you wish to set selection more effeciently when using a ILazyContentProvider.

Comment 3 Boris Bokowski

2006-08-22 17:43:07 EDT

Moving to SWT for comment - did Table.setSelection(int) ever cause selection events to be fired?

Comment 4 Giovanni Quarella

2006-08-23 16:57:52 EDT

(In reply to comment #3)
> Moving to SWT for comment - did Table.setSelection(int) ever cause selection
> events to be fired?

Maybe I believed that the setSelection caused selection events to be fired, instead what I observed was a side effect of another bug I entered about removing items from a virtual table.
Anyway the doc is misleading because Table#setSelection(int[] indices) seems equivalent to TableViewer.setSelection.
So with a ILazyContentProvider if I want to fire a selection event on item 0, what should I use?
A TableViewer.setSelection(0) would be helpful...

Comment 5 Steve Northover

2006-08-24 20:05:12 EDT

Nope.  Table.setSelection() never should have.  It's possible a bug was fixed but I don't remember it.

Comment 6 Boris Bokowski

2006-08-24 20:34:55 EDT

(In reply to comment #4)
> So with a ILazyContentProvider if I want to fire a selection event on item 0,
> what should I use?
> A TableViewer.setSelection(0) would be helpful...

This is not going to be more efficient than tableViewer.setSelection(tableViewer.getSelection()) since when we fire a selection event, it has to be in terms of elements, not items, so we would have to map from that index back to an element. This is exactly what getSelection() does.

Closing as wontfix. As a workaround, you can implement your own selection provider that forwards native selection events coming from the viewer, and inserts its own selection events for when you set the selection programmatically.