Community
Participate
Working Groups
I first saw this bug in 3.1.1, but it appears in 3.2 and the latest build I checked is 3.2 I20051116-1332. It's an issue with supplying the TableViewer with a DeferredContentProvider. When elements of the model are changed (that is, IConcurrentModelListener#update is invoked to notify the provider of the changes), the Table is not updated unless the results of the sort changes the order of the rows. What it comes down to is that when the SetModel#changeAll method is invoked, the UI doesn't get updated some of the time. There appears to be an issue with the ConcurrentTableUpdator class where it doesn't flush its pending clears unless it's told the element assigned to a row is different (replace()) or checkVisibleRange() is invoked. The ConcurrentTableUpdator#scheduleUIUpdate method should be invoked when clears are pending regardless of whether element-to-tablerow assignments change. To reproduce the problem, construct a java project from the testcase attached (updatorproblem). After launching the application, you should see a table with some content and some controls beside the table. - select the first row in the table (should be "22 | Jitter") - click the "Change to->" button which changes the integer value of the element associated with the first row. The table is not updated with the new integer value. (The table is sorted by the Text column so the sort order won't change.) - click the "Change to->" button again. In eclipse 3.1.1, the table remains unchanged, but in eclipse 3.2., the table is now updated with the previous integer value (0). I believe that this is because the "Change to->" button invokes a getSelection() which triggers the pending clear from the previous update to be flushed to the table. As you click the button successively, the table will update but it is always behind a step. The best workaround I've thought of so far is to use my own versions of BackgroundContentProvider and ConcurrentTableUpdator. I added a method to ConcurrentTableUpdator that schedules the ui update when there are pending clears and then I invoke that from BackgroundContentProvider#doSort after the ConcurrentTableUpdator#replace invocations (that way, the method I added does nothing if the replace() invocations flushed the pending clears). I'll attach my workarounds for your reference.
Created attachment 30271 [details] testcase with a small application this is the testcase mentioned in the bug description
Created attachment 30273 [details] ConcurrentTableUpdator workaround added the updateCleared method
Created attachment 30274 [details] BackgroundContentProvider workaround the invocation of ConcurrentTableUpdator#updateCleared is in this file
I found something else in the ConcurrentTableUpdator that seems to cause SetData to be ignored when the table should be updated. The ConcurrenTableUpdator#replace() method references the sentObjects array to decide if it's already sent the table the new data. However, there is a loop where it is using the wrong index into the sentObjects array. I will create another attachment that illustrates this. Search for the FIXME tag in the replace method. I attached another testcase that helps in identifying this particular version of the update problem. Run the testcase in the elements_not_updated attachment: - Click on the "Text" column header to sort by that column. - Scroll down to item "text_5000" and select it. - Hit the "Change to->" button over on the left side.
Created attachment 31992 [details] Testcase for larger sets of items and the sentObjects issue
Created attachment 31993 [details] FIXME tag identifies suspicious code The third FIXME tag is placed at the spot where I question the index usage. The second FIXME tag is at the place where I think the pendingClears array is being resized improperly.
Hitesh is now responsible for watching bugs in the [Viewers] component area.
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. -- The automated Eclipse Genie.
