Community
Participate
Working Groups
Problem: There is currently no way to determine what objects are visible in a TreeViewer Request: Add a method that will return all current TreePaths in a TreeViewer all the way down to the leaf nodes, or other mechanism to determine what Objects are currently visible in the TreeViewer. Example: I am facing the problem of using restoring the expansion state of a TreeViewer that uses a IDeferredWorkbenchAdapter. The problem is on refreshing the tree the whole structure collapses. I can use getExpandedTreePaths to get access to the state before collapse but as deferred provision uses PendingUpdateAdapter as place holders using setExpandedTreePaths fail e.g.: Before collapse: Root+_ |-MyFolder+_ | |-readme.txt After when trying to expand: Root+_ |-Pending... i.e. there is no "MyFolder" element as a the PendingUpdateAdapter is in its place whilst waiting for MyFolder to be retrieved. The solution to this problem is to check the tree for instances of PendingUpdateAdapter and sleep until they are gone before progressively opening up the tree. The issue is that there is no way for me to determine this. getExpandedTreePaths only gives you access to Root, and there is no way for me to get access to the pending node. I could go down the to underlying tree to look for Node.getText().equals("Pending...") but that still does not guarantee that the node is not just something with a label provider returning "Pending". If I had a method to return all TreePaths I could easily see what was loaded and act accordingly
I feel this can be implemented by JFace using the APIs already existent in Tree/TreeItem.
(In reply to comment #0) > Problem: > There is currently no way to determine what objects are visible in a TreeViewer Please have a look at org.eclipse.jface.databinding.viewers.ObservableListTreeContentProvider.getKnownElements - this is the closest API to what you want to do that I can think of. See bug 237359 for an example snippet.
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.
