Community
Participate
Working Groups
org.eclipse.ui.testing.ContributionInfo cannot be cast to org.eclipse.gef.EditPart at org.eclipse.gef.ui.parts.TreeViewer.findObjectAtExcluding(TreeViewer.java:155) at org.eclipse.gef.tools.TargetingTool.updateTargetUnderMouse(TargetingTool.java:424) at org.eclipse.gef.tools.SelectionTool.handleMove(SelectionTool.java:363) at org.eclipse.gef.tools.AbstractTool.mouseMove(AbstractTool.java:1188) at org.eclipse.gef.tools.SelectionTool.mouseMove(SelectionTool.java:561) at org.eclipse.gef.EditDomain.mouseMove(EditDomain.java:287) at org.eclipse.gef.ui.parts.TreeViewer$EventDispatcher.mouseMove(TreeViewer.java:91) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:205) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1052) ... Simple GEF editor, having tree in the outline. ClassCastException happens moving mouse over outline tree and there is no tree item under the mouse. GEF sets EditPart to Widget.setData() in org.eclipse.gef.editparts.AbstractTreeEditPart.setWidget(Widget) but workbench sets it to ContributionInfo in org.eclipse.ui.part.PageBookView.createPage(IWorkbenchPart) ContributionInfo is @since 3.6 And in this case the control is created by the user code, so workbench shouldn't modify data in it.
Created attachment 170954 [details] proposed patch This would remove the feature (displaying contribution info) for page book views. So instead of displaying, "this view content has been contributed by: org.eclipse.jdt.ui" for the Outline view with JDT content, we'd be displaying "this view has been contributed by: org.eclipse.ui.views".
(In reply to comment #0) > the control is created by the user code, so workbench > shouldn't modify data in it. I agree. Given that this happens with any GEF editor I'm inclined to fix this even though our last scheduled build for 3.6 is already running as I write this. John, what do you think? The fix is to remove the code that calls widget.setData, thereby removing one of the features of Shift+Alt+F3 for now. The proper fix would probably be to use setData with a key, but we can do that post 3.6.
Silenio, +1?
(In reply to comment #2) > Given that this happens with any GEF editor Actually, I haven't been able to reproduce this myself yet. Alex, can you provide us with more detailed steps? Can I reproduce it with one of the GEF examples?
+1 from me. It's quite important to fix this. Besides GEF, I'm sure there are other people using setData in trees in page book views and we'll be bashing their content, causing loss of data, etc. We can live with the slight loss of functionality in the spy command.
+1. Fully agree with John and Boris' patch. Reproduced with these 3 projects from HEAD of /cvsroot/tools/org.eclipse.gef/*: org.eclipse.draw2d org.eclipse.gef org.eclipse.gef.examples.shapes
Fix released to HEAD.
(In reply to comment #6) > Reproduced with these 3 projects from HEAD of /cvsroot/tools/org.eclipse.gef/*: Thanks, I tried the logic example with does not appear to show the problem. Verified on Mac Cocoa using I20100603-1500 and the shapes example.
