Re: [flexcoders] another bug in tree... or am I missing something
use .item of the treeEvent to get the model and use selectedItem in the tree to set according to model. so what i am basically saying is do your iteration over the dataprovider and code according to the data vs the view. 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 -- j:pn http://www.lennel.org
Re: [flexcoders] another bug in tree... or am I missing something
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'.
Re: [flexcoders] another bug in tree... or am I missing something
I dont quite understand. I am trying to set the selectedItem in the tree control. There is no concept of selection in the dataprovider so I dont know how I could set the set a selected item in the data vs the view. Selection is a view only concept. Hank On 12/12/06, Johannes Nel [EMAIL PROTECTED] wrote: use .item of the treeEvent to get the model and use selectedItem in the tree to set according to model. so what i am basically saying is do your iteration over the dataprovider and code according to the data vs the view. 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 -- j:pn http://www.lennel.org
Re: [flexcoders] another bug in tree... or am I missing something
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
Re: [flexcoders] another bug in tree... or am I missing something
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
Re: [flexcoders] another bug in tree... or am I missing something
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'.
Re: [flexcoders] another bug in tree... or am I missing something
On 12/12/06, Michael Schmalle [EMAIL PROTECTED] wrote: 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'.
Re: [flexcoders] another bug in tree... or am I missing something
On 12/12/06, Michael Schmalle [EMAIL PROTECTED] wrote: 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 may have been reading into your note because this is exactly what setting openItems does. If you look at the code I posted in the other thread, you will see that nothing is ever removed. If you set openItems it just adds the items you set to the list of open items. The only way to start fresh is to close them using the expandItems function. 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. Yeah, but the code doesnt work this way. 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. I think we were missunderstanding each other. My complaint is that it doesnt work the way that you are saying. If it worked that way I would be fine. Regards Hank
Re: [flexcoders] another bug in tree... or am I missing something
when selecting something in a tree you get a treeevent, this has a refrence to the item in the dataprovider. On 12/12/06, hank williams [EMAIL PROTECTED] wrote: I dont quite understand. I am trying to set the selectedItem in the tree control. There is no concept of selection in the dataprovider so I dont know how I could set the set a selected item in the data vs the view. Selection is a view only concept. Hank On 12/12/06, Johannes Nel [EMAIL PROTECTED] wrote: use .item of the treeEvent to get the model and use selectedItem in the tree to set according to model. so what i am basically saying is do your iteration over the dataprovider and code according to the data vs the view. 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 -- j:pn http://www.lennel.org -- j:pn http://www.lennel.org
RE: [flexcoders] another bug in tree... or am I missing something
I have never used selectedIndex, because of the very flat vs hierarchical dichotomy you mentioned. I have had good results using e4x XML as the dataProvider for my trees. Whe I need to select an item programmatically, I use an e4x selection expression to find the node, then set the selectedItem. I haven't used the openItems propety yet. Tracy From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Nel Sent: Tuesday, December 12, 2006 1:46 PM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] another bug in tree... or am I missing something when selecting something in a tree you get a treeevent, this has a refrence to the item in the dataprovider. On 12/12/06, hank williams [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I dont quite understand. I am trying to set the selectedItem in the tree control. There is no concept of selection in the dataprovider so I dont know how I could set the set a selected item in the data vs the view. Selection is a view only concept. Hank On 12/12/06, Johannes Nel [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: use .item of the treeEvent to get the model and use selectedItem in the tree to set according to model. so what i am basically saying is do your iteration over the dataprovider and code according to the data vs the view. On 12/12/06, hank williams [EMAIL PROTECTED] mailto:[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 -- j:pn http://www.lennel.org http://www.lennel.org -- j:pn http://www.lennel.org http://www.lennel.org
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] 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] 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
RE: [flexcoders] another bug in tree... or am I missing something
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
Re: [flexcoders] another bug in tree... or am I missing something
Unfortunately, my specific example is in a much bigger project. It will take a bit of work to construct an example, and because I will be out for the better part of tomorrow, I will not get to it until thursday. But I will get you an example. Regards Hank On 12/12/06, Belinda Nambooze [EMAIL PROTECTED] wrote: 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] 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] 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
