Just to elaborate on this, and to be absolutely clear, you *cannot* use selectedIndex on a tree with open leaves and get an accurate result.
The reason for this is that the internal routine commitSelectedIndex uses an iterator that to find the item to select. But the iterator on the tree is exactly the same as the iterator for the list, and does not acknowledge the tree hierarchy. It only iterates over the top level. So right now I am trying to figure out if it is at all possible to programmatically select an item in a tree with open leaves. Hank On 12/12/06, hank williams <[EMAIL PROTECTED]> wrote: > Here's the issue. > > You have a tree that has certain leaves open. > > You get a selectedIndex from a tree lets say its 9. This means that > the 10th visible slot on the screen is selected, regardless of what is > or isnt open. Its 10 rows from the top of the screen. > > Then, you put that captured selectedIndex back. Its 9. > > But now the 9 seem not to mean the 10th row, but the 10th item at the > top level of the data structure. So if your first leaf in the tree is > open and it has 10 children, you will be selecting the 20th row on the > screen. > > In other words, reading a selectedIndex seems to be different from > setting a selectedIndex. This is interesting also because it is very > similar to my issue yesterday about the openItems being different when > you read it than when you set it. > > It appears to me there are a bunch of issues in the tree control > related to the fact that it is a heirarchical object being mapped to a > flat underlying list structure. Another similar issue is that the > iterators do not iterate over all the items in the tree, just the ones > at the top level. An iterator that doesnt iterate over all the objects > in the list doesnt seem to me to be very useful. > > I think all of this exposes some problems with the conceptual > underpinnings of the tree object. I would love to hear if others have > had similar issues. > > Hank >
