The docs are a bit misleading when it comes to XML. Try using XML with the tree, it works great.
The warnings occur because most of the properties you deal with are dynamic objects, which are not bindable. Solve that by casting(object as XML) or converting(XML(object)) the object to the underlying XML. Do your nodes have unique id's? That makes things simple. That is a very arcane way to delete a node. Remind me, what was the problem using removeItemAt()? Were you using it with the selected nodes parent, and the selectedNodes child index? Tracy ________________________________ From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of shauncutts Sent: Friday, November 28, 2008 5:19 AM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: Crash of safari, firefox using XML.setChildren for XML in a XMLListCollection --- In flexcoders@yahoogroups.com, "Tracy Spratt" <[EMAIL PROTECTED]> wrote: > > First, if you are using a tree, why have you chosen XMLListCollection > instead of XML. For hierarchical data, XML is easier to work with than > nested collections. I thought an XMLListCollection was what you should use for a Tree control -- like using an ArrayCollection with a DataGrid. http://livedocs.adobe.com/flex/3/html/help.html?content=dpcontrols_8.htm l#397087 If the Tree represents dynamically changing data, you should use a collection, such as the standard ArrayCollection <http://livedocs.adobe.com/flex/3/langref/mx/collections/ArrayCollection .html> or XMLListCollection <http://livedocs.adobe.com/flex/3/langref/mx/collections/XMLListCollecti on.html> object, as the data provider. > Next, you say, "XML doesn't send notifications". Why do you say that? > And exactly what do you mean? XML is bindable. This is from: http://livedocs.adobe.com/flex/3/html/help.html?content=about_dataprovid ers_5.html If the Tree represents dynamically changing data, you should use a collection, such as the standard ArrayCollection <http://livedocs.adobe.com/flex/3/langref/mx/collections/ArrayCollection .html> or XMLListCollection <http://livedocs.adobe.com/flex/3/langref/mx/collections/XMLListCollecti on.html> object, as the data provider. It seems to be confirmed by the warning messages in the debugger I get from the collections when I'm fooling around with the underlying XML. > If you are using XML, then you delete a node using the "delete" operator > and an e4x expresaion: > > delete myXML.myNode.(myexpression)[0]; Ah ... thanks! I'll try this. > NOTE: You cannot use a variable containing a reference to the node you > want to delete, you must use the expression directly Um... but this might be a hinderance. I'm trying to react to an event generated from the Tree control (or rather a "delete" button, to delete selected branch)... I get the node in tree.selectedChild. Right now I'm getting the index of the child in the parent using childIndex, going up to the parent, making a copy of all the children *except* for the current child in a new XML List then setting the children of the parent using setChildren -- this tends to crash when the XML is in an XMLList which is the source of an XMLListCollection. But when it doesn't crash, I'm calling validateNow() on the Tree, then attempting to set the selectedChild to be the child of the XML before the node I just deleted -- this doesn't always work though. If anyone has any suggestions to replace this seemingly much to complex process with one that works better, I'd be very grateful! > The concept of an "index" seems inherently linear. I don't know how one > would implement it in a hierarchy. I have never been tempted to try to > use it. Um... well the Tree provides both selectedChild and selectedIndex... the later could be a path in the tree to get to the node, for example. [ list of indexes -- one for the top level XMLList, then the child's index in the parent down to the item selected. Or on the other hand if this isn't supported, then probably the class heirarchy should be reworked a little, get rid of selectedIndex for Trees. (Not that I'm complaining -- flex is obviously lightyears better than javascript.)