I do not agree that it is an issue on my computer. Two main reasons are...

I do not believe anything is being compiled for textLayout on my computer, isn't that the whole point of having the .swz? If i was to compile textLayout on my PC i wouldn't need the .swz right? The project is using the .swz library because textLayout is NOT being compiled. As i said before if i dont use the .swz and actually include the source (merge into code) from my pc (downloaded from sourceforge) then everything works perfect with no errors. But with the side effect of my project .swf being over 2 megs in file size.

The second reason is because there is no path of "C:\Vellum\branches\v2..." or any directory at any level called "Vellum" on my PC. I do not even have any source files for version 2 on my PC as when i downloaded build 29 from sourceforge i copied the version 3 files on top of the version 2 files in the directory "C:\Program Files (x86)\Adobe\Adobe Flash Builder 4.6\sdks\4.6.0\frameworks\projects\textLayout\src"

Do you have the directory "C:\Vellum\branches\v2..." on your PC or the PC where the .swz was compiled?

Is it possible that error message is in reference to the build process?

And yes i did all the steps to use the new swz...

* I copied the source files and textLayout.swc into the Flash Builder SDK as mentioned above.

* I downloaded both the textLayout_3.0.0.29.swf and textLayout_3.0.0.29.swz and put in "C:\Program Files (x86)\Adobe\Adobe Flash Builder 4.6\sdks\4.6.0\frameworks\rsls\"

* I edited the flex-config.xml and changed the tag...

<!-- TextLayout SWC -->

<runtime-shared-library-path>

     <path-element>libs/textLayout.swc</path-element>

     <rsl-url>http://www.mydomain.com/flash/lib/textLayout_3.0.0.29.swz</rsl-url>

     <policy-file-url>http://www.mydomain.com/flash/lib/crossdomain.xml</policy-file-url>

     <rsl-url>textLayout_3.0.0.29.swz</rsl-url>

     <policy-file-url></policy-file-url>

</runtime-shared-library-path>

* I verified the changes in Flash Builder...

Project > Properties > Flex Build Path > Flex 4.6.0 > textLayout.swc >

> Source attachment: C:\Program Files (x86)\Adobe\Adobe Flash Builder 4.6\sdks\4.6.0\frameworks\projects\textLayout\src   (No 'C:\Vellum' showing)

> Link Type: Use default (runtime shared library)

> RSL URL: http://www.mydomain.com/flash/lib/textLayout_3.0.0.29.swz

> RSL Policy File: http://www.mydomain.com/flash/lib/crossdomain.xml

* I did a clean build in Flash Builder > Project > Clean...

* I also made a production version in Flash Builder > File > Export > Release Build

* I looked in the /bin-debug/ directory and verified the textLayout_3.0.0.29.swf was put in there automatically from the clean build process.

* I looked in the /bin-release/ directory and verified the textLayout_3.0.0.29.swz was put in there automatically from the export process.

You also said the .swz was compiled with an Adobe certificate. But when i tested the project using the .swz hosted on my server i was given a security error message from my project swf saying my .swf did not have permission to access the .swz on the server. And yes, as mentioned above, i included a crossdomain.xml hosted on my server with the .swz file.

<?xml version="1.0"?>

<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">

<cross-domain-policy>

     <allow-access-from domain="*" secure="false"/>

</cross-domain-policy>

My theory is the .swz file was accidentally compiled with version 2 source files and is using a test certificate still, can you verify this?

Is there a "C:\Vellum\" directory on the PC it was compiled from?

Thank you very much, I was getting into this ContainerController bug using inline elements, and I managed to resolve using your hints.

Using a RichEditableText instead of a TextArea (for editable fields) would require quite a lot of work to manage scrolling behavior (e.g. scroll to follow the edit cursor during input, scroll through arrow keys, etc), so I suggest using the textLayout.swc v3 available on SourceForge (linked in a previus post) if you need editable, scrollable fields with inline graphic elements.

As a side note, I think that inline elements are also triggering other bugs.. often (usually when scrolling is involved) I get inconsistent results from the getText() method of TextFlow: some inline elements are not in the output string, other are correctly encoded using the ContentElement.GRAPHIC_ELEMENT char, so I had to rewrite a custom, simple recursive function to convert the text flow into a String in a consistent manner.