I've application when Im using RichEditableText in skin for TextInput. Also I'm binding "text" property from previosly entered text from server. If there is simple text, all is ok, if there are new lines (\n) after binding text to RichEditableText, whole app hangs or is it veeery slow. Cpu is 100%. In profiler I've found out, that there is infinite loop for recreating TextFlow objects. Really dont know what's problem.
and this is code from skin
<s:RichEditableText id="textDisplay"
multiline="{hostComponent.multiline}"
lineBreak="toFit"
color="{hostComponent.textColor}"
fontFamily="{hostComponent.fontFamily}"
fontSize="{hostComponent.fontSize}"
focusedTextSelectionColor="0xddf1f8"
left="6" right="1" top="4" bottom="1"
kerning="off"
heightInLines="{hostComponent.lines}"
>
</s:RichEditableText>
ok, im trying to fix this now, so that's why I'm replying later
First test and found first problem. When I have strings with \n inside and do not set width and height (need to set both to fix problem) in Profiler you can see infinity loop which try to find out correct size (dont know if this is problem of layout component itself, or together with RichEditableText, but for text without \n it works correctly
Here is example code. You can try to change textData in init() function and run in in profiler (SDK 4.0.14403). To fix problem set width for all 3 instances of RichEditableText.
<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/halo"
minWidth="1024" minHeight="768"
applicationComplete="init()"
xmlns:components="com.bbdo.totalWorkPlanner.app.view.components.*">
<fx:Declarations>
<!-- Place non-visual elements (e.g., services, value objects) here -->
</fx:Declarations>
<s:HGroup>
<s:BorderContainer>
<s:RichEditableText id="textInput"
multiline="true"
lineBreak="toFit"
height="200"
color="0xaaaaa"
left="6" right="1" top="4" bottom="1"
kerning="off"
heightInLines="10"
>
</s:RichEditableText>
</s:BorderContainer>
<s:Button label="update" click="update()"/>
<s:VGroup>
<s:BorderContainer>
<s:RichEditableText id="textDisplay1"
text="{textData}"
height="200"
multiline="true"
lineBreak="toFit"
color="0xaaaaa"
left="6" right="1" top="4" bottom="1"
kerning="off"
heightInLines="10"
>
</s:RichEditableText>
</s:BorderContainer>
<s:BorderContainer>
<s:RichEditableText id="textDisplay2"
text="{textData}"
height="30"
multiline="false"
lineBreak="toFit"
color="0xaaaaa"
left="6" right="1" top="4" bottom="1"
kerning="off"
heightInLines="1"
>
</s:RichEditableText>
</s:BorderContainer>
</s:VGroup>
</s:HGroup>
<fx:Script>
<![CDATA[
[Bindable]
public var textData:String;
private function init():void
{
//textData = "Fearful criminals. \n\nAlso theme-based super-villians. Or super-villians too interested in villiany to establish a theme (i.e. slackers). \n\nBasically any bad-guys that can be defeated by being beaten up by a guy who wears his underwear on the outside of his pants and talks in a growly voice.";
textData = "test data.";// \n\ntest \n\ndata";
}
private function update():void
{
textData = textInput.text
trace(textData);
}
]]>
</fx:Script>
</s:Application>
But this was not my main problem. I just found this when trying to found problem itself.
Now there is infinite calling of SizesAndLimit (for VerticalLayout and HorizontalLayout) and LayoutElementFlexChildInfo (for VerticalLayout)
in my app, there are command about creating TextFlow (or something similar) I will provide information later today
In app (huge app, I cant post code it now) there is repeating comannd from Profiler:
MethodClosure (builtin.as$0)
DamageEvent (flashx.textLaout.events)
WeakRef (flashx.textLayout.eternal)
Vector.<*> (__AS3__.vec)
TextLayoutFormat (flashx.textLayout.formats)
StandardFlowComposer (flashx.textLayout.compose)
CompositionCompleteEvent (flashx.textLaout.events)
FactoryDisplayComposer (TextLineFactoryBase.as$174)
while I wrote this message, there werer created more than 55000 DamageEvents, 46000 WeakRef, 20000 TextLayoutFormats
When I do not use multiline strings in RichEditableText (it's in custom Skin, all is ok)
in app there is no problem with SizesAndLimit (so this completly different problem like I have mentioned in previous reply)
TLF 1.1 included in Flex 4.1 has many long document performance improvements. Suggest you try that out. You can download it here.
http://opensource.adobe.com/wiki/display/flexsdk/Download+Flex+4
Its in the nightly builds section.
Hope that helps,
Richard
Hi Richard,
I'm already using 4.1 (SDK 14403 which has name Flex 4.1). I have found that problem is in proper setting of width and height. Problem is just for multiline text.
Problem is that you can set size for RichEditableText in 3 different ways
And it works just for first option (absolute size), if you set size with percentual or with left, right, top, bottom TLF is trying to correctly measure component and recreating new TextFlow object (or something from TLF).
I have this problem occuring now as well. I had a TextArea set to 50% width and an explicit height. It was used to display data from the server. Suddenly, without apparent reason, it is throwing up all over me now. However, from the beginning I have been putting new line chars in this text field. Whatever. What a PAITA.
Hi
I cannot because the problem appears to occur based on data from the server. This is in production already so it requires luck to catch the error in time. We are currently trying to find out just what exactly is in the string data from the server that makes the app crash. All i can send are stack traces. If we catch the error in real time before it gets replaced on the server, i will hopefully have the actual string data that reproduces the problem. Please dont hold your breath though.
Sent from my iPhone
We have so far confirmed that the hang-up happens when UTF-8 encoded double-byte characters are passed from the server and inserted into the TextArea component.
In contrast, we tried changing to Shift-JIS and, although the component did not trigger an infinite loop, all the characters were moji-baked.
So, the problem appears to be that TextArea cannot accept double-byte characters safely.
I cannot reproduce this programmatically. The string MUST come from an external source.
Furthermore, the bug appears to be dependent upon a regular expression that is processing the string before it is assigned to the TextArea:
textArea.text = value.replace(/\n\s*/g, " ") + "\n";
If I remove the regular expression, the component does crash.
North America
Europe, Middle East and Africa
Asia Pacific