If FlowComposerBase.isDamaged() is returning the answer you want, why not add enough code to get its value?
IIRC, the RichTextEditor and TLF have some logic to do a compose(). I would think you would want Squiggly to run whenever the compose() finishes, not when it is damaged. -Alex On 2/25/15, 3:12 AM, "Mihai Chira" <mih...@apache.org> wrote: >bump. Any ideas from people more experienced with tlf? Thank you. > >On 19 February 2015 at 15:44, Mihai Chira <mihai.ch...@gmail.com> wrote: >> How can I see if a RichEditableText's textFlow is damaged? >> >> From my investigations, it seems that FlowComposerBase.isDamaged() >> offers the perfect solution, but that it's then overridden in >> StandardFlowComposer.isDamaged() to return true if the >> RichEditableText allows scrolling. So if a text field allows scrolling >> (even if it's not scrolled at the moment), the textFlow will ALWAYS >> appear broken. How can this be useful? >> >> (I need to know whether a textFlow is damaged because I want to fix >> FLEX-34756[1] by preventing SpellUI from spell checking when the >> textFlow is damaged - the assumption being that it will be recomposed >> on the next frame. If you can think of a better solution, please let >> me know. >> >> >> Thanks! >> >> [1] https://issues.apache.org/jira/browse/FLEX-34756 >> Summary of bug: >> -squiggly is set to spell check when the focus returns to a text field >> (see SpellUI.handleFocusIn()) >> -after making changes to the text, the RichEditableText's textFlow is >> damaged and has to be recomposed. This normally happens in the next >> frame, when RichEditableText.updateDisplayList calls >> _textContainerManager.updateContainer(). >> -BUT if we set focus on the RichEditableText after the text change, >> squiggly does the spell checking on the damaged textFlow. >> -because of this, it's offered bad indexes in >> SpellUI.getValidFirstWordIndex() and SpellUI.getValidLastWordIndex(), >> thus checking on non-existing text.
