Community
Participate
Working Groups
Build Identifier: I have a TableViewer and a PropertyView. When selecting on table viewer update to Properties View fails intermittently. Here's a tack trace that could help. !ENTRY org.eclipse.ui.workbench 4 0 2011-11-08 15:48:17.057 !MESSAGE Index out of bounds !STACK 0 java.lang.IllegalArgumentException: Index out of bounds at org.eclipse.swt.SWT.error(SWT.java:4263) at org.eclipse.swt.SWT.error(SWT.java:4197) at org.eclipse.swt.SWT.error(SWT.java:4168) at org.eclipse.swt.widgets.TreeItem.findPrevious(TreeItem.java:230) at org.eclipse.swt.widgets.TreeItem.<init>(TreeItem.java:197) at org.eclipse.ui.views.properties.PropertySheetViewer.createItem(PropertySheetViewer.java:361) at org.eclipse.ui.views.properties.PropertySheetViewer.updateChildrenOf(PropertySheetViewer.java:1290) at org.eclipse.ui.views.properties.PropertySheetViewer.updateChildrenOf(PropertySheetViewer.java:1312) at org.eclipse.ui.views.properties.PropertySheetViewer.access$2(PropertySheetViewer.java:1211) at org.eclipse.ui.views.properties.PropertySheetViewer$3.childEntriesChanged(PropertySheetViewer.java:322) at org.eclipse.ui.views.properties.PropertySheetEntry.fireChildEntriesChanged(PropertySheetEntry.java:301) at org.eclipse.ui.views.properties.PropertySheetEntry.refreshChildEntries(PropertySheetEntry.java:576) at org.eclipse.ui.views.properties.PropertySheetEntry.setValues(PropertySheetEntry.java:760) at org.eclipse.ui.views.properties.PropertySheetViewer.setInput(PropertySheetViewer.java:973) at org.eclipse.ui.views.properties.PropertySheetPage.selectionChanged(PropertySheetPage.java:510) at org.eclipse.ui.views.properties.PropertySheet.selectionChanged(PropertySheet.java:363) at org.eclipse.ui.internal.AbstractSelectionService.firePostSelection(AbstractSelectionService.java:179) at org.eclipse.ui.internal.AbstractSelectionService$2.selectionChanged(AbstractSelectionService.java:71) at org.eclipse.jface.viewers.StructuredViewer$3.run(StructuredViewer.java:888) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:49) at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175) at org.eclipse.jface.viewers.StructuredViewer.firePostSelectionChanged(StructuredViewer.java:886) at org.eclipse.jface.viewers.StructuredViewer.handlePostSelect(StructuredViewer.java:1226) at org.eclipse.jface.viewers.StructuredViewer$5.widgetSelected(StructuredViewer.java:1251) at org.eclipse.jface.util.OpenStrategy.firePostSelectionEvent(OpenStrategy.java:262) at org.eclipse.jface.util.OpenStrategy.access$5(OpenStrategy.java:256) at org.eclipse.jface.util.OpenStrategy$3.run(OpenStrategy.java:433) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4140) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3757) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2696) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2660) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at com.vastech.badgerui.controller.Application.start(Application.java:46) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577) at org.eclipse.equinox.launcher.Main.run(Main.java:1410) at org.eclipse.equinox.launcher.Main.main(Main.java:1386) Reproducible: Sometimes
Moving to Platform UI for comment
What version of eclipse are you using? PW
Eclipse SDK Version: 3.7.0 Build id: I20110613-1736
Willem, we need more information than this. You wrote a view that contains a TableViewer? What kind of model backs it? How does the property view consume it? Are you using an extension point? PW
I have an Editor that contains the TableViewer. On createPartControl() of the editor, I call getSite().setSelectionProvider(). The TableViewer contains Row objects where Row implement IAdaptable. In response to getAdapter(IPropertySource.class) the Row object returns a RowSource object that implements IPropertySource. RowSource returns a set of about 60 properties that are rendered in the properties view.
Remy, could you have a quick look a this stack trace? My org.eclipse.swt.widgets.TreeItem doesn't have a findPrevious(*) at all. PW
Willem, is this problem 100% reproducible? (In reply to comment #6) > Remy, could you have a quick look a this stack trace? My > org.eclipse.swt.widgets.TreeItem doesn't have a findPrevious(*) at all. It is there on win32. Don't really see anything suspicious given that the tree items are created in order starting from an index of 0. I can only assume a previous item failed to be created which then lead to this insertion problem.
The problem is not 100% reproducible. It does not happen every time I select a Row, but it happens quite often. I have tried, but I cannot reproduce the problem consistently. Here is something I did not mention before that could be of assistance: The properties are not the same for every row in the table and I construct new instances of all the property descriptors every time a row is selected.
Thank you for responding to this problem. I have decided to implement custom property pages instead of using the default. So, this bug is not troubling me anymore. However, I though it may help if I share some thoughts on the matter. Here is the documentation on IPropertyDescriptor.getId: * Returns the id for this property. This object is * used internally to distinguish one property descriptor * from another. IProperySource.getPropertyDescriptors says: * Implementors should cache the descriptors as they will be asked for the * descriptors with any edit/update. Since descriptors provide cell editors, * returning the same descriptors if possible allows for efficient updating. In my program I did not have any use for caching or reusing descriptors; and I allocated values for the id rather carelessly. So my theory is that duplicate id's could somehow have been the cause of this misbehavior. If this is the cause it may help the next guy to make the documentation 'stronger'. The documentation could clarify the scope in which the id should be unique: IPropertySource instance, IPropertySource implementator class, or maybe plug-in?
Created attachment 235082 [details] stack trace Using Eclipse 4.3.0 build I20130605-2000 on Windows. I am also experiencing this bug. I have a JFace TreeViewer with an ObservableListTreeContentProvider observing a hierarchical list. When a large number of items are added to the list, after a number of tree items have been successfully added, the TreeItem.findItem() method starts returning 0 to the TreeItem.findPrevious() method, which then in turn throws the SWT error with SWT.ERROR_INVALID_RANGE. When debugging, I noticed that the following call (Tree.java line 2853): hNextItem = OS.SendMessage (handle, OS.TVM_GETNEXTITEM, OS.TVGN_NEXT, hNextItem); returns 0 in the last iteration of the loop. This causes all subsequent calls that use hLastIndexOf to fail, throwing the error each time. See stack trace attached.
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. If the bug is still relevant, please remove the stalebug whiteboard tag.
