Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Date: Mon, 17 Dec 2012 16:43:11 +0000 (UTC)
From: "Maxime Cowez (JIRA)" <jira@apache.org>
To: flex-dev@incubator.apache.org
Message-ID: <JIRA.12624307.1355762201356.17355.1355762591747@arcas>
In-Reply-To: <JIRA.12624307.1355762201356@arcas>
References: <JIRA.12624307.1355762201356@arcas>
Subject: [jira] [Updated] (FLEX-33311) Nullpointer in ConstraintLayout when
 executing Transition on content
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/FLEX-33311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Maxime Cowez updated FLEX-33311:
--------------------------------

    Attachment: SpecifiableListWrapperHorizontalSkin.mxml
                SpecifiableListWrapper.as

Custom component and skin to recreate the error.
                
> Nullpointer in ConstraintLayout when executing Transition on content
> --------------------------------------------------------------------
>
>                 Key: FLEX-33311
>                 URL: https://issues.apache.org/jira/browse/FLEX-33311
>             Project: Apache Flex
>          Issue Type: Bug
>          Components: Spark: Layout, Transitions
>    Affects Versions: Apache Flex 4.8 (parity release)
>            Reporter: Maxime Cowez
>            Priority: Trivial
>         Attachments: SpecifiableListWrapper.as, SpecifiableListWrapperHorizontalSkin.mxml
>
>
> In some very specific cases `ConstraintLayout` will throw a nullpointer error when a component inside it is playing a transition. I tried a few things and found out that:  
>  - `parseConstraints()` creates a new `rowBaselines` Vector (or empties it if it exists)
>  - some other process calls `clearConstraintCache()` in the middle of the execution of `parseConstraints()`, setting `rowBaselines` back to `null`
>  - `parseConstraints()` calls `parseElementConstraints()` which tries to access elements in `rowBaselines` and throws a nullpointer error
> I know very little about how Effects and Transitions work, so the "some other process" part is a bit of a mistery to me.
> Here is some code to reproduce the error consistently. My apologies for the complexity, but I couldn't get a simpler example to trigger the error.
>     <s:Group width="100%">
>         <s:layout>
>             <s:ConstraintLayout>
>                 <s:constraintColumns>
>                     <s:ConstraintColumn id="sequenceCol"/>
>                     <s:ConstraintColumn id="labelCol"/>
>                     <s:ConstraintColumn id="contentCol" width="100%"/>
>                     <s:ConstraintColumn id="helpCol" maxWidth="200"/>
>                 </s:constraintColumns>
>                 <s:constraintRows>
>                     <s:ConstraintRow id="row1" baseline="maxAscent:10" height="100%"/>
>                 </s:constraintRows>
>             </s:ConstraintLayout>
>         </s:layout>
>         <s:Group left="contentCol:0" right="contentCol:1" baseline="row1:0" bottom="row1:10">
>             <t:SpecifiableListWrapper width="100%" skinClass="SpecifiableListWrapperHorizontalSkin">
>                 <s:DropDownList dataProvider="{dp}"/>
>             </t:SpecifiableListWrapper>
>         </s:Group>
>         <s:Group id="helpContentGroup" left="helpCol:27" right="helpCol:10" bottom="row1:10" baseline="row1:0"/>
>     </s:Group>
> As you may notice, the constraint columns and rows are a copy of those used in FormItemSkin. I left only the content columns necessary to trigger the error (yup, remove the `helpContentGroup` and the error's gone). SpecifiableListWrapper is a custom component which I will attach, along with the specific skin that has the Transition that triggers the error.
> Workaround: subclass ConstraintLayout (or FormItemLayout), override `measure()`, put a try/cacth block around it and use this custom layout.
> public class FormItemLayout extends spark.layouts.FormItemLayout {
>     override public function measure():void {
>         try {
>             super.measure();
>         }
>         catch (e:Error) { }
>     }
> }
> Not exactly pretty but it works without apparent side effects.
> Quick fix (but probably not the ideal solution): just test whether `rowBaselines` exists before trying to access it >
> if (rowBaselines && rowBaselines[bIndex][1]) ...
> instead of 
> if (rowBaselines[bIndex][1]) ...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira