Return-Path: X-Original-To: apmail-flex-dev-archive@www.apache.org Delivered-To: apmail-flex-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id BB0AE17A23 for ; Fri, 27 Feb 2015 17:15:21 +0000 (UTC) Received: (qmail 51032 invoked by uid 500); 27 Feb 2015 17:15:21 -0000 Delivered-To: apmail-flex-dev-archive@flex.apache.org Received: (qmail 50992 invoked by uid 500); 27 Feb 2015 17:15:21 -0000 Mailing-List: contact dev-help@flex.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@flex.apache.org Delivered-To: mailing list dev@flex.apache.org Received: (qmail 50979 invoked by uid 99); 27 Feb 2015 17:15:20 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Feb 2015 17:15:20 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of mihai.chira@gmail.com designates 74.125.82.172 as permitted sender) Received: from [74.125.82.172] (HELO mail-we0-f172.google.com) (74.125.82.172) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Feb 2015 17:15:15 +0000 Received: by wesk11 with SMTP id k11so21613132wes.11 for ; Fri, 27 Feb 2015 09:14:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=x5OspR+PSOYd0aTNCL5S3FSepHO4QJhKsTzO5NX7GBM=; b=f3oJTIot/S3VSMJlvsSLa2NpJV4sCP4QrlEUHPno76ACCFApNTYjDmgsLxN6O1ZyDI e/210HzDxGRhc9kVSdHLrCKIMBKwtBS+CSuIo+MLrs0GoQP68ONwyWDgzXFMIhtUwQqQ jnLJrbS830Ae3lv0lwoBnGj0NYs8MMf74QNZHaUqDLvj3bq7SdVxMy0sxmrWfRof8jMp LwH2Q7k6/FepyUVSOsQBHvLYuO4Oy4NQ60hvmkcX2iXs/80bW5n6v05jabtmn2s2BBd+ Sy84+fWeHQRfZpKrtq0vnhS1aknga/mqsjIyMzHlWACoS5iue7N/JpP2BmoD6zZE7gKU /kqA== X-Received: by 10.180.107.201 with SMTP id he9mr8511836wib.46.1425057294672; Fri, 27 Feb 2015 09:14:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.57.215 with HTTP; Fri, 27 Feb 2015 09:14:34 -0800 (PST) In-Reply-To: References: From: Mihai Chira Date: Fri, 27 Feb 2015 18:14:34 +0100 Message-ID: Subject: Re: [jira] (FLEX-34756) How to know when the textFlow is damaged? To: "dev@flex.apache.org" Cc: Alex Harui Content-Type: text/plain; charset=UTF-8 X-Virus-Checked: Checked by ClamAV on apache.org 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 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" wrote: > >>bump. Any ideas from people more experienced with tlf? Thank you. >> >>On 19 February 2015 at 15:44, Mihai Chira 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. >