[news.eclipse.tools] Re: Phantom + signs in TreeViewer

["Nick Edgar" <nick_edgar@xxxxxxx>]

Interesting point about the interaction between filters and hasChildren().
Clearly the semantics are weak here.
It makes more sense if you think of hasChildren() as returning whether the
node can potentially have children, not whether it currently has children.
E.g. in a file system view, folders and drives would return true, files
would return false, regardless of whether the folders actually had contents.

Another aspect to keep in mind is that the TreeViewer populates the
underlying Tree widget lazily.
Until you actually expand something for the first time, the widget does not
have items for its children.
So for any node which can have children, it puts a + initially.  Windows
Explorer works this way in its directory hierarchy.
This lazy population is crucial in some cases, e.g. the repository view.
You don't want it doing extra round trips just to determine whether to show
the + or not.

Nick

"Wing Hong Ho" <winghong@xxxxxxxxxx> wrote in message
news:9m1170$370$1@xxxxxxxxxxxxxxxx
> I am using a TreeViewer with a filter so that only certain nodes show.
> However, when I do that, some of the leaf nodes in the TreeViewer show a
> phantom '+' sign until a user clicks on it in an attempt to expand that
> node.  At that point, if that node has no child to expand, the '+' sign
> goes away.
>
> This happens on leaf nodes that has at least one child but none that would
> pass the filter.  I can understand why the above happens: the TreeViewer
> simply calls the hasChildren() method in the ContentProvider and decides
> from that alone whether to put a '+' sign on the node.  When the user
> clicks on it, the TreeViewer finds out that there is actually no children
> to display and removes the '+' sign.
>
> Do you think that this is a bug with the TreeViewer?  Also, what is the
> best way to solve this problem for now?  We are currently putting smarts
> in the hasChildren() method to accomodate the filter, but we will be
> interested in other solutions as well.
>
> Thanks.
>