Summary: | [Viewers] ElementComparer and Viewers | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Dirk Baeumer <dirk_baeumer> |
Component: | UI | Assignee: | Nick Edgar <n.a.edgar> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | ||
Version: | 2.1 | ||
Target Milestone: | 2.1 RC1 | ||
Hardware: | PC | ||
OS: | Windows 2000 | ||
Whiteboard: |
Description
Dirk Baeumer
2003-02-07 10:57:37 EST
We found a case where calling refresb(element, false) caused a situation that the old element was kept. We fixed it on your side my implementing the comparer in a way that a stale working copy element != original element. But neverless the viewer would be "more stable" if it always keeps references to the last updated elements. The corresponding viewer code is (TableViewer.internalRefresh(...): // if the element is unchanged, update its label if appropriate if (equals(children[i], items[i].getData())) { if (updateLabels) { updateItem(items[i], children[i]); } } if the elements are equals and and no label update, then the item keeps the "old" element, even if getChildren provided "new" elements. We had to remove the JavaElementComparer from all views except the package explorer. The reason is that the fix we put into the comparer regarding stale working copies led to garbage in th hash table. The scenario is as follows: - CU switches to working copy. The elements are equals hence the map element-> item changes. Key is now working copy - WC switches to CU. When we receive the delta the WC is already stale resulting in the situation that the map entry for the WC didn't get removed since WC != CU in this case. So conisdering the case that updateLabel is false as desribed in comment #1 is necessary. Fixed TableViewer.internalRefresh. AbstractTreeViewer should already handle this properly. Please let me know if you see this again. In I20030213. |