Community
Participate
Working Groups
StructuredViewer.java: public void update(Object[] elements, String[] properties) { for (int i = 0; i < elements.length; ++i) update(elements[i], properties); } This loops through all the elements fed to it, which calls update(Object element, String[] properties) which calls internalUpdate(Widget widget, Object element, String[] properties) which checks the properties with the filter&sorter: if (needsRefilter) { refresh(); return; } And if successful a full refresh has been done, yet update() is still looping over more elements to update. The full refresh gets/filters/sorts _all_ the elements as far as I understand it. There is no need to continue. Updating with an Object[] of 1000 elements that triggers the refresh() on the first element need not call update() on the remaining 999 elements. They could theoretically be 999 elements that trigger a refresh() (resulting in a bogged down gui thread..)
It will be easier to fix this one once we made StructuralViewer.internalUpdate private again.
Therefore, I have added a dependency on bug 89606.
Created attachment 34572 [details] possible patch against org.eclipse.jface Since we haven't been able to make internalUpdate private again, I don't think I can release the fix for this yet.
Moving to 3.2M6. I'll try my best to convince JDT to not use internalUpdate anymore, which would allow fixing this.
Sorry, bug I didn't have the time for lobbying. Deferring to 3.3.
Deferring again. Workaround is to pass null for the properties array, which avoids the inner loop if you don't need a refresh, or calling refresh directly if you need it.
Created attachment 72079 [details] new patch
Michael, this patch will likely break CommonViewer because it relies on an unspecified implementation detail: StructuredViewer.update(Object[], String[]) currently calls update(Object, String[]) but after applying this patch, it won't do that anymore. Would it be possible that you override update(Object[], String[]) as well?
Moving to M3.
Michael, could you please have a look at this and comment? I would be interested in your opinion as to how likely it is that someone else (the original WTP common navigator?) made the assumption that StructuredViewer.update(Object[], String[]) calls update(Object, String[]).
So far as I'm aware, most of the implementations of content extensions from WTP land make use of update(obj, null); I'm not aware of any implementation that makes use of the string array for properties. Until 3.3, the CNF actually called refresh() as a result of it's update(obj, ..) method because of deficiencies with known notification patterns from existent content providers.
Fixed in HEAD > 20080203. I made no assumptions about who calls what in my fix. It is really ugly because of that but should work. Rutger, would you be able to confirm that this fixes the problem you reported? Thanks
Rutger, I would appreciate if you could download a recent integration build (for example, I20080205-0010) and confirm that the fix solves the reported problem.
