Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 164371

Summary: [Viewers] Collapsed item get's child count re-set to 1 if children already retrieved
Product: [Eclipse Project] Platform Reporter: Darin Wright <darin.eclipse>
Component: UIAssignee: Boris Bokowski <bokowski>
Status: VERIFIED FIXED QA Contact:
Severity: major    
Priority: P3    
Version: 3.3   
Target Milestone: 3.3 M4   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Bug Depends on: 164647    
Bug Blocks:    

Description Darin Wright CLA 2006-11-13 14:17:18 EST 
The following behavior can be seen using the debugger from HEAD:

* stop at a breakpoint
* expand a variable to see its children (more than one)
* step
* collapse the expanded variable
* step
* expand

> only one child is shown even though there are more. Stepping again brings back the other children.

It looks like this is because of TreeViewer.setHasChildren(...). When a tree is refreshed, each node is asked if it has children. The content provider eventually calls back to setHasChildren(..). This method sets the child count to one (1) if a node is *not* expanded but has children. Then, when a node is again expanded in TreeViewer.handleTreeExpand, the node is not updated if there is a child that has associated data. 

Perhaps the child count should not be modified for items that have children when setHasChildren is called?

The associated JFace sqeunce of events in a virtual tree is:

* expand a node that has > 1 child
* collapse the node
* refresh the root
* expand the node 

> the node only shows one child until the root is refreshed again
Comment 1 Boris Bokowski CLA 2006-11-14 14:53:30 EST 
I believe the correct fix for this is to set the data of the (single) child to null and then call clear() on it.  Released to HEAD.  Darin, could you test again with JFace from HEAD?
Comment 2 Darin Wright CLA 2006-11-14 17:18:51 EST 
Works with latest code in HEAD.
Comment 3 Boris Bokowski CLA 2006-11-14 18:11:41 EST 
ok - I consider this fixed >20061114.
Comment 4 Boris Bokowski CLA 2006-12-14 16:19:10 EST 
Doesn't happen any more. I20061213-0800