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.
What are you talking about here?
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 didn't say this; I said, you can retrieve the list of open items, run a check on whcih you want closed, pop them out and reset the property by setting it to the new popped list. Which is now minus the items you want closed and they will be closed on the next commitProperties() pass. Thus, using the property to set a new state of opendItems.
Properties reflect state.
Yeah, and they also set state. Which in this case you are setting the new state of openItems by taking out items of the open list that you want closed. Maybe were talking about two different things here. Peace, Mike On 12/12/06, hank williams <[EMAIL PROTECTED]> wrote:
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] <hank777%40gmail.com>> wrote: > > > On 12/12/06, Michael Schmalle <[EMAIL PROTECTED]<teoti.graphix%40gmail.com>> 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 > >
-- 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'.
