ValueCommit is supposedly for “any changes to selection”, the change event is supposedly only for user-initiated changes to selection. The binding system listens to both. The change of selection on close is currently seen as programmatic since the user didn’t directly do it, but I think there is already a bug that argues that change should fire as well.
On 9/3/10 11:12 AM, "Richard Rodseth" <rrods...@gmail.com> wrote: I was able to work around this issue by accessing selectedItem and updating my presentation model during the itemClose operation. But to answer your question, it looks like I get two valueCommits when closing a node. On Thu, Sep 2, 2010 at 10:58 PM, Alex Harui <aha...@adobe.com> wrote: I thought there was already a bug on that. Do you get a valueCommit? On 9/2/10 4:23 PM, "Richard Rodseth" <rrods...@gmail.com <http://rrods...@gmail.com> > wrote: It appears that when you close a node in a tree control, the selection (of a contained node) is lost, but no change event is fired. Does this sound like a bug? I'm trying to restore tree state (selection and open nodes) across a service call. I've got the open nodes working pretty well and the refresh use case also mostly works (I store the selection as guids from the objects in question and find them again after the refresh). But it seems I will have to handle openItem and closeItem, and clear the guid-based selection if the node is contained in the path being closed. -- Alex Harui Flex SDK Team Adobe System, Inc. http://blogs.adobe.com/aharui
