#113 Empty panels with Eclpse 3.5
After building and running the project on Eclipse 3.5, the panel displays are corrupted with some rows being empty and others alright, seemingly in a random fashion. The following stack trace is thrown (one per panel):
[main] Platform Exception: Status WARNING: org.eclipse.jface code=0 Ignored reentrant call while viewer is busy. This is only logged once per viewer instance, but similar calls will still be ignored. java.lang.RuntimeException - (AppPlugin.java:78)
[main] Stack trace: - (AppPlugin.java:79)
java.lang.RuntimeException
at org.eclipse.jface.viewers.ColumnViewer.checkBusy(ColumnViewer.java:763)
at org.eclipse.jface.viewers.AbstractTableViewer.replace(AbstractTableViewer.java:1056)
at org.eclipse.jface.viewers.deferred.DeferredContentProvider$TableViewerAdapter.replace(DeferredContentProvider.java:72)
at org.eclipse.jface.viewers.deferred.ConcurrentTableUpdator.updateTable(ConcurrentTableUpdator.java:365)
at org.eclipse.jface.viewers.deferred.ConcurrentTableUpdator.checkVisibleRange(ConcurrentTableUpdator.java:290)
at org.eclipse.jface.viewers.deferred.BackgroundContentProvider.checkVisibleRange(BackgroundContentProvider.java:432)
at org.eclipse.jface.viewers.deferred.DeferredContentProvider.updateElement(DeferredContentProvider.java:213)
at org.eclipse.jface.viewers.AbstractTableViewer$1.handleEvent(AbstractTableViewer.java:86)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1003)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1027)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1012)
at org.eclipse.swt.widgets.Table.checkData(Table.java:934)
at org.eclipse.swt.widgets.Table.checkData(Table.java:923)
at org.eclipse.swt.widgets.TableItem.getImage(TableItem.java:551)
at org.eclipse.jface.viewers.TableViewerRow.setImage(TableViewerRow.java:132)
at org.eclipse.jface.viewers.ViewerCell.setImage(ViewerCell.java:169)
at org.eclipse.jface.viewers.TableColumnViewerLabelProvider.update(TableColumnViewerLabelProvider.java:71)
at org.eclipse.jface.viewers.ViewerColumn.refresh(ViewerColumn.java:145)
at org.eclipse.jface.viewers.AbstractTableViewer.doUpdateItem(AbstractTableViewer.java:399)
at org.eclipse.jface.viewers.StructuredViewer$UpdateItemSafeRunnable.run(StructuredViewer.java:481)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.runtime.Platform.run(Platform.java:888)
at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:48)
at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175)
at org.eclipse.jface.viewers.StructuredViewer.refreshItem(StructuredViewer.java:1503)
at org.eclipse.jface.viewers.AbstractTableViewer.replace(AbstractTableViewer.java:1059)
at org.eclipse.jface.viewers.deferred.DeferredContentProvider$TableViewerAdapter.replace(DeferredContentProvider.java:72)
at org.eclipse.jface.viewers.deferred.ConcurrentTableUpdator.updateTable(ConcurrentTableUpdator.java:365)
at org.eclipse.jface.viewers.deferred.ConcurrentTableUpdator.access$2(ConcurrentTableUpdator.java:299)
at org.eclipse.jface.viewers.deferred.ConcurrentTableUpdator$1.run(ConcurrentTableUpdator.java:107)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3855)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3476)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2405)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2369)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2221)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:500)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:493)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.jcommander.ui.app.PlatformRunnable$JCMDApplicationEntryPoint.startup(PlatformRunnable.java:110)
at org.jcommander.ui.app.singleton.SingletonAppLauncher.startingFirstInstance(SingletonAppLauncher.java:76)
at org.jcommander.ui.app.PlatformRunnable.run(PlatformRunnable.java:47)
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.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:574)
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:368)
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:559)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514)
at org.eclipse.equinox.launcher.Main.run(Main.java:1311)
at org.eclipse.equinox.launcher.Main.main(Main.java:1287)
It could be one of the bugs in DeferredContentProvider.
https://bugs.eclipse.org/bugs/buglist.cgi?quicksearch=DeferredContentProvider
Hi,
there are a lot of bugs associated with DeferredContentProvider. Could we temporarily get rid of the use of SWT.VIRTUAL and the DeferredContentProvider from the FileTableControl.createViewerContents() method?
I have inspected the code and it seems though it uses SWT.VIRTUAL, the model is fully constructed/fetched in FileControlModel.update() and then all FileDetails are sorted and set in one big chunk into the super.SetModel, so from my understanding it makes no use anyway of the lazy loading feature of the virtual table. Am I right ?
Best regards,
Dan.
Dan, thanks for looking into this. From my knowledge, virtual tables optimize the display of the model so that graphical resources are allocated only for the visible rows. So if the model has 2000 items but the table has only 20 visible rows, then it will contain only 20 TableItem objects. It's a pretty poorly documented feature though.
I've seen the bug list and my guess is that removing the SWT.VIRTUAL flag is the most recommended for now and let's move on to other more pressing issues in making JC a plugin model. However, it's not as simple as removing the flag. I'll also look into this and get back to you with more ideas.
Hi,
I have made some small changes to not use the SWT.VIRTUAL flag any more. The code is running OK on galileo but I was not able to commit the changes on a new branch.
I have created a new branch named no_VIRTUAL but when I try to commit the changes I get
org.jcommander.ui.filepanel: cvs commit: Pre-commit check failed
I use the followinc CVS access url
:extssh:corneanu_dan@jcommander.cvs.sourceforge.net:/cvsroot/jcommander
Rober, can you please check what is wrong? In the meantime I'll attach a patch with the changes, maybe you can have a look and apply them.
Best regards,
Dan.
Temporary workaround: do not use SWT.VIRTUAL and the DeferredContentProvider as they are buggy.
You can find the workaround in the sources on CVS.