Comment 1 Ben Vitale 2007-03-15 08:55:39 EDT

Is there any known workaround for this?  I'm seeing it on 3.2.2:

org.eclipse.jface.util.Assert$AssertionFailedException: null argument;
	at org.eclipse.jface.util.Assert.isNotNull(Assert.java:150)
	at org.eclipse.jface.util.Assert.isNotNull(Assert.java:126)
	at org.eclipse.jface.viewers.AbstractTreeViewer.getTreePathFromItem(AbstractTreeViewer.java:2561)
	at org.eclipse.jface.viewers.AbstractTreeViewer.getSelection(AbstractTreeViewer.java:2584)
	at org.eclipse.ui.internal.AbstractSelectionService.getSelection(AbstractSelectionService.java:220)
	at org.eclipse.ui.internal.services.CurrentSelectionSourceProvider.swapListeners(CurrentSelectionSourceProvider.java:141)
	at org.eclipse.ui.internal.services.CurrentSelectionSourceProvider.access$0(CurrentSelectionSourceProvider.java:131)
	at org.eclipse.ui.internal.services.CurrentSelectionSourceProvider$1.windowActivated(CurrentSelectionSourceProvider.java:54)
	at org.eclipse.ui.internal.Workbench$8.run(Workbench.java:609)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)

Comment 2 Boris Bokowski 2007-03-15 09:22:46 EDT

(In reply to comment #1)
> Is there any known workaround for this?  I'm seeing it on 3.2.2:

Do you know in which view this is happening?

Comment 3 Ben Vitale 2007-03-15 10:33:09 EDT

(In reply to comment #2)
> Do you know in which view this is happening?

I have a custom view that extends ViewPart.  It creates a tree with 3 columns, adds a viewer on top of that, and sets the viewer as the selection provider for the view site.

After playing around a bit, it looks like the implementation of setFocus, when commented out, makes the problem go away.

public void setFocus() 
{
 treeViewer.getControl().setFocus();
}

Comment 4 Ben Vitale 2007-03-15 10:34:22 EDT

(In reply to comment #3)
> After playing around a bit, it looks like the implementation of setFocus, when
> commented out, makes the problem go away.

Check that, still happens when I double-click on the list elements.

Comment 5 Ben Vitale 2007-03-15 10:40:28 EDT

Better relevant stacktrace captured from the debugger:

Thread [main] (Suspended (breakpoint at line 88 in ProjectListView$1))	
	ProjectListView$1.getTreePathFromItem(Item) line: 88	
	ProjectListView$1(AbstractTreeViewer).getSelection() line: 2584	
	ProjectListView$1(StructuredViewer).handleSelect(SelectionEvent) line: 1128	
	StructuredViewer$4.widgetSelected(SelectionEvent) line: 1154	
	OpenStrategy.fireSelectionEvent(SelectionEvent) line: 213	
	OpenStrategy.access$3(OpenStrategy, SelectionEvent) line: 207	
	OpenStrategy$1.handleEvent(Event) line: 374	
	EventTable.sendEvent(Event) line: 66	
	Tree(Widget).sendEvent(Event) line: 928	
	Display.runDeferredEvents() line: 3348	
	Display.readAndDispatch() line: 2968	
	Workbench.runEventLoop(Window$IExceptionHandler, Display) line: 1930	
	Workbench.runUI() line: 1894	
	Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 422	
	PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 149	
	Application.run(Object) line: 29	
	PlatformActivator$1.run(Object) line: 78	
	EclipseAppLauncher.runApplication(Object) line: 92	
	EclipseAppLauncher.start(Object) line: 68	
	EclipseStarter.run(Object) line: 400	
	EclipseStarter.run(String[], Runnable) line: 177	
	NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]	
	NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39	
	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25	
	Method.invoke(Object, Object...) line: 585	
	Main.invokeFramework(String[], URL[]) line: 336	
	Main.basicRun(String[]) line: 280	
	Main.run(String[]) line: 977	
	Main.main(String[]) line: 952	

Comment 6 Boris Bokowski 2007-03-15 11:02:06 EDT

Do you call methods on TreeViewer reentrantly from your label or content provider? The Viewer classes don't expect this to happen.

The rules are: (1) While a viewer calls a method on your content or label provider, do not call back into the viewer unless the Javadoc explicitly states that this is expected. (2) While a viewer calls a method on your content or label provider, do not process events (as in Display.readAndDispatch).  Note that (a) acquiring a lock, (b) running a long-running operation that reports progress, or (c) causing an error dialog to open may cause events to be processed.

You should not do either (a) or (b) from a content provider or a label provider.  (c) is something we need to fix by making the error dialog non-modal.

Comment 7 Ben Vitale 2007-03-15 11:22:52 EDT

Sorry, previous stacktrace was misleading.  I overrode getTreePathFromItem to do some debug prints and to set breakpoints.

Comment 8 Ben Vitale 2007-03-15 11:23:30 EDT

Created attachment 60957 [details]
Project list view source

View exhibiting the behavior

Comment 9 Boris Bokowski 2007-03-15 11:38:46 EDT

The bug in your code is much simpler than what I thought - when using TreeViewer, you must not create or dispose tree items yourself, this is managed by the tree viewer.  If you use a tree viewer, you need to supply at least a content provider and an input.  You can go either way - use SWT directly and manage tree items yourself, or use TreeViewer and let it manage the tree items for you.

Comment 10 Ben Vitale 2007-03-15 13:55:45 EDT

Thanks.  Hadn't even looked at the mixed up tree code;  was working in 3.1.2 so assumed it was an upgrade problem.

Comment 11 Boris Bokowski 2009-11-26 09:53:04 EST

Hitesh is now responsible for watching bugs in the [Viewers] component area.

Comment 12 Eclipse Webmaster 2019-09-06 16:05:44 EDT

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.