Keep looking. I'm pretty sure there is at least one more that has the svn
rev # of when I did put in the fix. Or try searching the logs. I'm
pretty sure it is in the branch we donated. It was pretty invasive and
risky.
-Alex
On 2/12/14 8:50 PM, "Justin Mclean" wrote:
>Hi,
>:
>
>> Yup, that
Hi,
:
> Yup, that scrollbar thing as been around forever. There should be some
> existing bugs on it.
Like this one:
https://issues.apache.org/jira/browse/FLEX-33295
Any chance of obtaining that fix you mention in there?
I tried a simple count how many times updateDisplayList is called in
Scr
Yup, that scrollbar thing as been around forever. There should be some
existing bugs on it.
On 2/12/14 8:27 PM, "Justin Mclean" wrote:
>Hi,
>
>> Well, in general, the framework doesn't protect much against bad inputs.
>
>It setting the width to 20-30 that causes the issue not 0, I'd not call
>t
Hi,
> Well, in general, the framework doesn't protect much against bad inputs.
It setting the width to 20-30 that causes the issue not 0, I'd not call that a
bad input and it can happen at other width and text lengths as well it just
that this manages to reproduce the issue easily enough.
It t
not doing
anything.
-Alex
On 2/12/14 5:21 PM, "Justin Mclean" wrote:
>Hi,
>
>Managed to reproduce a TLF timeout simply. This may be an edge case but I
>can think of a few case where you have small text fields and could run
>into this.
>
>
>
>http://ns.adobe.com
>private function updateCompositionShapes():void
> {
> for each (var controller:ContainerController in
> controller)
> controller.updateCompositionShapes();
> }
Hmm. That's fun. It will end up doing nothing. Since th
Hi,
Managed to reproduce a TLF timeout simply. This may be an edge case but I can
think of a few case where you have small text fields and could run into this.
http://ns.adobe.com/mxml/2009";
xmlns:s="library://ns.adobe.com/
