flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mihai Chira <mihai.ch...@gmail.com>
Subject Re: [jira] (FLEX-34756) How to know when the textFlow is damaged?
Date Fri, 27 Feb 2015 17:14:34 GMT
Hi Alex,

I'm not sure what you mean by "why not add enough code to get its
value"? In my mind, I can't get the value of
FlowComposerBase.isDamaged() because all text fields have a
StandardFlowComposer by default (and I can't change this, because I'm
in Squiggly, so I have to assume things are in their default setup),
which overrides this function to return something I can't use anymore.
What am I missing?

Or do you mean temporarily changing the TextFlow.flowComposer that
extends FlowComposerBase to each text field every time I would need to
check to see if the textFlow is damaged?
(No, sorry, that wouldn't work, because it wouldn't have any
information about the damage that occurred before this reset of
composer.)

Sorry, I'm still out of ideas.

On 25 February 2015 at 18:33, Alex Harui <aharui@adobe.com> wrote:
> 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" <mihaic@apache.org> wrote:
>
>>bump. Any ideas from people more experienced with tlf? Thank you.
>>
>>On 19 February 2015 at 15:44, Mihai Chira <mihai.chira@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.
>

Mime
View raw message