Hi Hank, I'm not able to reproduce the issue where selectedIndex doesn't work. Could you email me a code snippet showing the bug?
Thanks, Belinda Flex QA SDK ________________________________ From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of hank williams Sent: Tuesday, December 12, 2006 10:14 AM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] another bug in tree... or am I missing something Problem solved. Someone offlist sent me a solution, which appears to be that setting selectedIndex doesnt work, but setting selectedItem does work. So the work around for the bug is dont use selectedIndex. Regards, Hank On 12/12/06, hank williams <[EMAIL PROTECTED] <mailto:hank777%40gmail.com> > 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] <mailto:hank777%40gmail.com> > wrote: > > > > > > On 12/12/06, Michael Schmalle <[EMAIL PROTECTED] <mailto: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 > > > > >
