Selection issue with Multiple containers when text re-flows

Hi Jin,

This helps. I can query TextFlow for all the <img> elements it has and update lineHeight there. For now, I had handled it in the getEffectiveLineHeight method overridden in ILG class.

I investigated further and found the exact reason for TextLine's parent being null. This was leading to several other issues with selection.

What happens in this scenario is that the TextLine added to the controller contains the correct reference to the TextFlowLine in it's user data BUT when we do a peekTextLine() on this TextFlowLine, it doesn't return the same TextLine and instead returns a stale TextLine, parent of which is null.

After spending a lot of time, I wasn't able to understand why exactly it is happening but added a small work around to fix:

1. Before adding composed TextLine to Controller, I asked for the reference of TextFlowLine via TextLine's userdata
2. I added a public property currentLine in TextFlowLine and set the TextLine into it.
3. In peekTextLine, if currentLine is not null, I do not peek into TextBlock and simply return the TextLine.

This resolves the issue as the TextLine returned is always the correct one. I know that's the right place to do it but hopefully it'd help you suggest the area where fix needs to be done.

However, this does not help in resolving the issue with InlineGraphic element being removed by the succeeding controller. But the condition I added to the removeInlineGraphicElement seems to resolve it.  I know this is again a workaround but it works for me for now. The function looks like this:

     protected function removeInlineGraphicElement(parent:DisplayObjectContainer, inlineGraphicElement:DisplayObject):void

                    {

                              // We're removing the inline holder -- the float it owns should be in the visible list

                              CONFIG::debug { assert (parent != _container || _floatsInContainer.indexOf(DisplayObjectContainer(inlineGraphicElement).getChildAt(0)) >= 0, "Float *not* already in                                           container"); }

                              if (null != parent && inlineGraphicElement.parent == parent)

                              {

                                        if(parent.parent && parent.parent != container)

                                        {

                                                  return;

                                        }

                                        parent.removeChild(inlineGraphicElement);

                              }

                    }

I hope you come out with TLF 4.0 soon and have all these issues fixed there. I feel that there are certain areas where performance can be improved a lot by adding invalidation and commit cycles like Flex has, which would mean that everything gets processed lesser number of times and the user won't be able to make the difference. This is just how I thought.

Thanks for your time and I'd let you know I face any more issues.

Regards

Pulkit

Hi Jin,

I was initially using TLF 2 but tried porting to 3 and made change in the code as you suggested but it did not make any difference.

The App I am building is an extension of the sample Flex app you had shared on one of  the forums. It is a mobile app and am using Flex SDK 4.5.1. The TLF source is also embedded along as I had to comment / change out a few areas where Flex was giving compilation errors. These include using hardcoded string instead of constant in a constructor of few classes and commenting out ContextMenu code as mine is an AIR app and looks for NativeMenu instead of ContextMenu.

You can download the FXP from here:

http://s1.imfinity.com/TLFTest/TLF4EPub.fxp

There are plus and minus buttons at top and you can navigate to pages by tapping on left or right of the page.

Please choose Android from device configurations and Samsung Galaxy tab emulator from the list to emulate.

- As you make the text larger and it moves to new container, the selection stops working.

- As you reduce the font after increasing it such that image moves from one container to the one before it, the image would disappear.

Besides these, I am facing another issue on IPAD simulator where the first 2 lines appear behind the Image and are not visible. I have not been able to identify any solution for this till now. There is nothing specific about this issue to do with IPAD but just the dimensions of the device which make such a scenario happen.

I am not sure if I have put more than asked for but I thought I should give you as much information as I can. Hope you'd be able to have a look at this.

Thanks and Regards

Pulkit

I did not reproduce your new case. But based on your description, I think it is because TLF reuses some cached TextLines, rather than creates them from scratch.

When creating TextLines,

1. create TextElement to hold the text and GraphicElement to hold image,

2. feed the TextBlock.content with those TextElements and GraphicElements,

3. call TextBlock.creatTextLine() to create.

Thus, the parent of Loader is null because the process above has not been executed

We will be on vacation from Oct. 1st to 7th and will continue to look into the issue in Oct. 8th. Thanks!

We found that it's a bug. The lines that cannot be highlighted have no 'parent'.

An FTE TextLine’s parent can be null in many cases.  The most common is that the TextLine is not on the DisplayList (not parented by a Sprite).  That’s a fairly normal case when long TextFlow’s are being scrolled.  Only the visible lines are on added to the Sprite. A variation is that the TextLine is “stale”.  It was generated again and the new version is on the DisplayList.  There is code in getTextLine (or possibly other TextFlowLine member functions) that is intended to handle this case. 

Hope it can help you to find a better workaround, because the fix for this bug will be in TLF 4.0.