Phew!
Looks like I fixed this issue. Once I found the problem, the fix was
straight-forward... There’s still some failures with FloatTests, but nothing as
bad as what we were getting before.
I’m going to comment on the other FlexUnit discussion about the remaining
errors.
On Nov 23, 2014, at
Duh!
I’ve actually been working on this for so long, I forgot what I’ve done! :-(
I just looked through the git logs and I see, that I’m the one that added
_curLineStart. The code used to get the index from the TextBlock, but that is
no longer a reliable method of getting the index, so I added
Here’s what I *think* is happening:
1) ComposeState.composeNextLine() calls createTextLine() and gets a TextLine.
2) Part of what BaseCompose.createTextLine() does is: _curLineStart +=
_curLine.textLength. That increases the index of where the line is supposed to
start from. _curLineStart is the
I went through all the ParagraphElements and TextFlowLines. I added it up, and
it’s clear to me that the _curElementOffset and _cur is being upped by 41 which
is the length of the current line before the line is initialized. That seems to
be throwing everything out of whack.
Now I just need to
I’m back on this. I have a simpler case where things are getting out of sync.
I have a line where the _curElementOffset is 382, the _curElementStart is 803
(total 1201).
The total textLength of the textFlow is 1201.
The _curLineStart is 1185 and the rawTextLength of the TextLine returned by the
Right. My question is more related to TextFlowLines than Slugs though.
Let’s say a flowComposer has an array of TextFlowLines and the geometry of them
does not fit in the new composition space. What is supposed to happen to the
old TextFlowLines? I’m having trouble understanding the architecture
I don’t know for sure, I just looked up the Slug class. It says it is
created by Parcels to track geometrical line information.
Maybe a simpler test case would help you understand the desired behavior?
I would think at some point if the composable areas change, the Parcels
and their Slugs get upd
Just to be a little clearer:
I’m not sure why this used to work, and now it doesn’t.
It seems to me that if the parcel changes on a TextFlowLine, the
outerTargetWidth could be changed and the TextLine regenerated. (Then the Slug
and the outerTargetWidth should match.) The thing is, the code did
I took a little break on this to deal with some other crises.
I found where it’s going off:
In BaseCompose.fitLineToParcel() this check was failing:
// check to see if we got a good line
if (Twips.to(_lineSlug.width) !=
_curLine.outerTargetWidthTW
We have had
if (_curElementStart == _curParaStart+_curParaElement.textLength)
break;
get off before because we accidentally edited the model during composition.
TLF really hates when you do that.
On Fri, Nov 7, 2014 at 2:50 AM, Erik de Bruin wrote:
> No, please go ahead, I think showing pro
No, please go ahead, I think showing progress and thoughts/ideas will be
helpful to others, and it might even trigger someone with a solution.
EdB
On Fri, Nov 7, 2014 at 9:34 AM, Harbs wrote:
> A bit more progress: It looks like things go off where the text flows from
> one container into ano
A bit more progress: It looks like things go off where the text flows from one
container into another mid-paragraph…
(Sorry for polluting the mailing list with this. I’ll try to be quiet until I
figure it out…)
On Nov 7, 2014, at 9:55 AM, Harbs wrote:
> It’s pretty big.
>
> It consistently g
It’s pretty big.
It consistently gets out of whack at the end of the second paragraph. I’m
getting closer to where it’s going off…
On Nov 7, 2014, at 1:01 AM, Alex Harui wrote:
>
>
> On 11/6/14, 2:02 PM, "Harbs" wrote:
>
>> I think it’s _curElementOffset which gets updated.
>>
>> It does
On 11/6/14, 2:02 PM, "Harbs" wrote:
>I think it’s _curElementOffset which gets updated.
>
>It does look like something is getting out of sync. I’m just not sure yet
>what. This is one of those areas that’s way too fragile IMHO… Every time
>I’ve run into these kinds of issues it’s taken me days
I think it’s _curElementOffset which gets updated.
It does look like something is getting out of sync. I’m just not sure yet what.
This is one of those areas that’s way too fragile IMHO… Every time I’ve run
into these kinds of issues it’s taken me days to figure out exactly what’s off.
On Nov 6
On 11/6/14, 1:50 PM, "Harbs" wrote:
>Well, it does this:
>
>if (_curElementStart == _curParaStart+_curParaElement.textLength)
> break;
>
>to normally break out of the loop.
>
>I’m a bit fuzzy though on how it handles SpanElements that span multiple
>lines and how to break out of that.
Doesn’t
Well, it does this:
if (_curElementStart == _curParaStart+_curParaElement.textLength)
break;
to normally break out of the loop.
I’m a bit fuzzy though on how it handles SpanElements that span multiple lines
and how to break out of that.
(I should really try to comment the code a bit so next
On 11/6/14, 1:03 PM, "Harbs" wrote:
>
>For some reason, the flowComposer has TextFlowLines beyond the end of the
>paragraph which it’s trying to compose.
>BaseCompose.composeParagraphElementIntoLines() should really break out of
>the loop before this happens (if I’m understanding things correct
The error happens here:
// trace("Recreating line from", absoluteStart,
"to", absoluteStart + textLength);
textLine = TextLineRecycler.getLineForReuse();
if (textLine)
{
On 11/6/14, 12:27 PM, "Harbs" wrote:
>It’s all checked in to the tables branch.
>
>I can give you a swf to step through.
I’m willing to spend a little time looking into it. Probably not until
this evening (8 hours or so from now).
-Alex
I think the root of the problem is that BaseCompose.createTextLine() is
returning null. The only reason why that would happen is if the line
couldn't fit in the space provided. I am not sure why
ComposeState.composeNextLine() is trying to do _curLine.getTextLine(true)
when the textLine is null. I w
It’s all checked in to the tables branch.
I can give you a swf to step through.
On Nov 6, 2014, at 10:18 PM, Alex Harui wrote:
>
>
> On 11/6/14, 12:09 PM, "Harbs" wrote:
>
>> Yes. It’s very reproducible.
>>
>> Not small at all… :-(
>>
>> It would be considerable work to try to put togethe
On 11/6/14, 12:09 PM, "Harbs" wrote:
>Yes. It’s very reproducible.
>
>Not small at all… :-(
>
>It would be considerable work to try to put together a test case for this.
Can the current SWF you are debugging be made public so I can run it in a
debugger, or do I need accounts, password, etc? I
Yes. It’s very reproducible.
Not small at all… :-(
It would be considerable work to try to put together a test case for this.
On Nov 6, 2014, at 9:41 PM, Alex Harui wrote:
> Do you have a 100% reproducible test case? How small is it?
>
> On 11/6/14, 11:31 AM, "Harbs" wrote:
>
>> If someone
Do you have a 100% reproducible test case? How small is it?
On 11/6/14, 11:31 AM, "Harbs" wrote:
>If someone has the time to walk through this with me off-list, that would
>be very helpful. I’d really like an extra set of eyeballs to make sure
>I’m not missing something with this and I don’t bl
If someone has the time to walk through this with me off-list, that would be
very helpful. I’d really like an extra set of eyeballs to make sure I’m not
missing something with this and I don’t blow things up. I don’t have a good
enough grasp on exactly how the management of TextFlowLines is supp
I think my explanation might be more helpful, but here:
TypeError: Error #1009: Cannot access a property or method of a null object
reference.
at
flashx.textLayout.compose::TextFlowLine/http://ns.adobe.com/textLayout/internal/2008::recreateTextLine()[/Users/harbs/Documents/ApacheFlex/fle
What was the stack trace?
On Thu, Nov 6, 2014 at 11:29 AM, Harbs wrote:
>
> On Nov 6, 2014, at 7:15 PM, Alex Harui wrote:
>
> > My memory is a bit fuzzy. I thought TextLine recycling wasn’t
> > per-paragraph, or is there a TextBlock per paragraph?
>
> There’s generally one TextBlock per paragr
On Nov 6, 2014, at 7:15 PM, Alex Harui wrote:
> My memory is a bit fuzzy. I thought TextLine recycling wasn’t
> per-paragraph, or is there a TextBlock per paragraph?
There’s generally one TextBlock per paragraph. My table work was actually quite
difficult because there was an assumption in ma
My memory is a bit fuzzy. I thought TextLine recycling wasn’t
per-paragraph, or is there a TextBlock per paragraph?
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
I ran into an issue where I have a runtime error in TextFlowLine.getTextLine().
I’m 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.
The RTE happens inside TextFlowline.recreateTextLine() after request
31 matches
Mail list logo
