Mailing-List: contact dev-help@flex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flex.apache.org
Received-SPF: pass (nike.apache.org: domain of harbs.lists@gmail.com
 designates 209.85.212.179 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: TextFlowLine recycling
From: Harbs <harbs.lists@gmail.com>
In-Reply-To: <D080D660.1D64A%aharui@adobe.com>
Date: Thu, 6 Nov 2014 21:31:40 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <7BB1BB3E-7106-4016-A47B-960272858D35@gmail.com>
References: <FEF122BE-5DB5-4F4D-AD64-DAA6A705D285@gmail.com>
 <D080D660.1D64A%aharui@adobe.com>
To: dev@flex.apache.org

If someone has the time to walk through this with me off-list, that =
would be very helpful. I=92d really like an extra set of eyeballs to =
make sure I=92m not missing something with this and I don=92t blow =
things up. I don=92t have a good enough grasp on exactly how the =
management of TextFlowLines is supposed to be working.

On Nov 6, 2014, at 7:15 PM, Alex Harui <aharui@adobe.com> wrote:

> My memory is a bit fuzzy.  I thought TextLine recycling wasn=92t
> per-paragraph, or is there a TextBlock per paragraph?
>=20
> The doc says that TextBlock.createTextLine/recreateTextLine returns =
null
> if the TextBlock is empty or if the width specified is less than the =
width
> of the next element, and to check the TextBlock.textLineCreationResult
> property if you get a null.
>=20
> Could it just be that the number of lines in the paragraph when to =
zero?
>=20
> -Alex
>=20
> On 11/6/14, 2:26 AM, "Harbs" <harbs.lists@gmail.com> wrote:
>=20
>> I ran into an issue where I have a runtime error in
>> TextFlowLine.getTextLine(). I=92m having trouble stepping through =
things,
>> but as best as I can figure, the issue is caused by the umber of =
lines in
>> a paragraph becoming reduced.
>>=20
>> The RTE happens inside TextFlowline.recreateTextLine() after =
requesting
>> the line from the TextBlock. The function (I=92m not sure if it=92s
>> createTextLine or recreateTextLine) returns null. The =
TextBlock.lastLine
>> is the line before the current one.
>>=20
>> The caller of this mess is ComposeState.composeNextLine.
>>=20
>> If anyone is still following me, my problem is I=92m not sure the =
best way
>> to fix this. I=92m not sure why this is breaking now. I=92m not sure =
what I
>> changed that=92s causing this error. Should I fix
>> TextFlowLine.getTextLine() to return null if there=92s no more lines =
in the
>> paragraph? Will there be any other repercussions from doing that? =
Should
>> I fix ComposeState/BaseCompose  so it does not try to compose the =
next
>> line once the paragraph is out of lines?
>>=20
>> Is anyone familiar enough with the composer to even give me =
suggestions?
>> :-(
>>=20
>> Harbs
>=20