Thanks. I'll consider using valueCommit in this case. I'd only used it in the context of things like text fields before.
On Fri, Sep 3, 2010 at 1:06 PM, Alex Harui <aha...@adobe.com> wrote: > > > 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 > >
