Community
Participate
Working Groups
I20030206 We are seeing problems where we get staled working copies in selection change event sent out by a structured viewer. We don't have a reproducable case yet, but it seems to be related to the following situation: - the JavaElementComparer maps working copy elements and original elements. So wc.euals(original) == true. - since working copies can get staled the viewer must ensure that whenever items in the viewer get updated or refresh the viewer always uses the new element in the item's data pointer or in the hash table, even if new.equals(old), since old can get staled. Nick, can you think about cases in the structured viewer where old elements get kept ?
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.
