Well an example would be where there say half a dozen related properties that get set, these individualy call invalidateProperties and will then be collectively processed in commitPorperties on the next frame.
In that processing events are raised to notify changes, however the handlers for those events could lead to other properties being set that in turn will call invalidateProperties which of course fails. The thing is I have no idea when that situation will happen as its ooutside my component and in any particular call to invalidateProperties there is nothing I can check to say 'oh I am already in commitProperties so I need to use callLater or smtg'. At the moment I have tried to fix it by overriding validateProperties and setting a flag called "inCommitProperties" and then overriding invalidateProperties and if the flag is set I then either use a callLater or set another flag "needToCommitAgain" which I then check at the end of validateProperties and if set I run commitProperties again. But its a bit of a hack and I wondered what others are doing --- In [email protected], Manish Jethani <manish.jeth...@...> wrote: > > I think normally if changing property1 also calls for a change in > property2, that change should happen in the setter for property1. Then > both properties get "committed" in commitProperties() > > If your situation is special and you can't follow that pattern, you > can try a callLater() on invalidateProperties() > > > On 5/27/09, reflexactions <reflexacti...@...> wrote: > > It seems that if during the validateProperties call,l I change some random > > properties and one of them calls invalidateProperties() in order to complete > > processing during the next commmitProperties() phase, the commitProperties > > never runs. > > This is because at the end of processing the initial validateProperties the > > invalidation flag is cleared so blocking the next commitProperties from > > running. > > > > Is that right and how to work around it for general properties. > > > > > > tks > > > > > > > > > > ------------------------------------ > > > > -- > > Flexcoders Mailing List > > FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt > > Alternative FAQ location: > > https://share.acrobat.com/adc/document.do?docid=942dbdc8-e469-446f-b4cf-1e62079f6847 > > Search Archives: > > http://www.mail-archive.com/flexcoders%40yahoogroups.comYahoo! Groups Links > > > > > > > > > > -- > Sent from my mobile device >
