You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by "Justin Mclean (JIRA)" <ji...@apache.org> on 2013/04/17 04:47:15 UTC

[jira] [Updated] (FLEX-14313) in Accordion. selectedIndex can return the wrong value

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

Justin Mclean updated FLEX-14313:
---------------------------------

    Labels: easyfix easytest  (was: )
    
> in Accordion. selectedIndex can return the wrong value
> ------------------------------------------------------
>
>                 Key: FLEX-14313
>                 URL: https://issues.apache.org/jira/browse/FLEX-14313
>             Project: Apache Flex
>          Issue Type: Bug
>          Components: mx: Accordion
>    Affects Versions: Adobe Flex SDK 3.0 (Release)
>         Environment: Affected OS(s): All OS Platforms
> Affected OS(s): All OS Platforms
> Language Found: English
>            Reporter: Adobe JIRA
>              Labels: easyfix, easytest
>
> Steps to reproduce:
> 1. set accordion selectedIndex to 3
> 2. commit value by allowing validate() to run
> 3. set accordion selectedIndex to 2
> 4. get selectedIndex, value returned is 2
> 5. set accordion selectedIndex to 3
> 6. get selectedIndex, value returned is 2
>  
>  Actual Results:
>  
>  2
>  Expected Results:
>  
> 3
> more info:
> From: Todd Rein 
> Sent: Friday, March 14, 2008 1:00 PM
> To: David Tristram
> Subject: RE: unexpected behavior in AccordionBase.get selectedIndex()
> I think this is the same as this bug I filed just on Accordion: https://bugs.adobe.com/jira/browse/SDK-9611
> From: David Tristram 
> Sent: Friday, March 14, 2008 12:49 PM
> To: DL-Flex Questions
> Subject: unexpected behavior in AccordionBase.get selectedIndex()
> This feels like a bug to me.  On an Accordion I set its selectedIndex.  Then, before commitSelectedIndex is called,  I set it again.  If I then read the index, I get the first value I set because the second time I set it I happened to set it to its original value and the setter bailed in the second test against _selectedIndex below.  That is, the getter is returning proposedSelectedIndex, but that didn't get updated the second time I called the setter.  
> I think the second test in the setter should be (logically, that is, it could be rewritten in one level of if's using conjunction of conditions):
> if ( proposedSelectedIndex != 1 ) {
>     if ( value == proposedSelectedIndex ) {
>         return;
>     }
> else {
>     if ( value == _selectedIndex ) {
>         return;
>     }
> }
> dt
>     public function get selectedIndex():int
>     {
>         if (proposedSelectedIndex != -1)
>             return proposedSelectedIndex;
>         return _selectedIndex;
>     }
>     /**
>      *  @private
>      */
>     public function set selectedIndex(value:int):void
>     {
>         // Bail if new index isn't a number.
>         if (value == -1)
>             return;
>         // Bail if the index isn't changing.
>         if (value == _selectedIndex)
>             return;
>         // Propose the specified value as the new value for selectedIndex.
>         // It gets applied later when commitProperties() calls commitSelectedIndex().
>         // The proposed value can be "out of range", because the children
>         // may not have been created yet, so the range check is handled
>         // in commitSelectedIndex(), not here. Other calls to this setter
>         // can change the proposed index before it is committed. Also,
>         // childAddHandler() proposes a value of 0 when it creates the first
>         // child, if no value has yet been proposed.
>         proposedSelectedIndex = value;
>         invalidateProperties();
>         // Set a flag which will cause the History Manager to save state
>         // the next time measure() is called.
>         if (historyManagementEnabled && _selectedIndex != -1 && !bInLoadState)
>             bSaveState = true;
>         dispatchEvent(new FlexEvent(FlexEvent.VALUE_COMMIT));
>     }
>  
>  Workaround (if any):

--
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