By the way, again, just to be clear, the selectedIndex setter seems to inherit from ListBase.as instead of from something in the tree family.
Regards, Hank On 12/12/06, hank williams <[EMAIL PROTECTED]> wrote: > > > On 12/12/06, Michael Schmalle <[EMAIL PROTECTED]> wrote: > > > > 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. > > > The underpinnings are incorrect in that if you trace the code that is > invoked when you set selectedIndex you end up in commitSelectedIndex and the > iterator and specifically the cursor that is used is not a > HierarchicalViewCursor, but a flat view cursor that in no way acknowledges > the hierarchical structure of the tree. I have just single stepped through > the code and it is clear that at least the selectedIndex setter has no idea > that it is a hierarchical tree as opposed to a list. > > > > > As far as your problem, I haven't run into that. > > To bad. It would be helpful to hear from someone who knows what the deal is > with this. Its quite frustrating. > > > > > 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. > > > No, my 'issue' is not be cause I am looking at it backwards. I am looking at > it the only logical way to look at it. OpenItems is not a method, it is a > property. Properties reflect state. This means that openItems should be a > list of all and *only* open items. And since it is a property that can be > read and written we should be able to set the list of which items are open > and which are closed. If they intended to make it work such that setting > openItems just adds to a list of open items then they should have made it a > function and not property. > > > > > 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. > > > There is nothing wrong with this if openItems is a function and not a > read/write property. As a read/write property this is poor design. > > > > > 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. > > Again, this may be how they were thinking when they designed it. But if so, > first it should be documented, and second it should be a function. > > Regards, > Hank > >
