Hi, I think you should take a look at the;
import mx.controls.treeClasses.HierarchicalViewCursor; import mx.controls.treeClasses.HierarchicalCollectionView; classes I don't think the 'underpinnings' are incorrect. It's just conceptually there are differences that present themselves in that collection view. As far as your problem, I haven't run into that. As far as your 'issue' about the openItems; I think you are looking at it backwards. You are thinking open items means closed items as well. I don't see anything wrong in getting a list of open items and taking 'out' the items you don't want open. THus creating closed items. The point of the openItems is to collect a list and use it with their collection view. There is nothing in the model that says 'isOpen'. So you have to bend the way you think and say, I have these open items now, I am taking items out of the open items, now these items are closed. Peace, Mike 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
-- Teoti Graphix http://www.teotigraphix.com Blog - Flex2Components http://www.flex2components.com You can find more by solving the problem then by 'asking the question'.
