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