[
https://issues.apache.org/jira/browse/FLEX-24223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Mclean updated FLEX-24223:
---------------------------------
Labels: easytest (was: )
> Validation on ListBase, triggerEvent IndexChangeEvent.CHANGE, leaves the
> ErrorSkin a step behind errorString
> ------------------------------------------------------------------------------------------------------------
>
> Key: FLEX-24223
> URL: https://issues.apache.org/jira/browse/FLEX-24223
> Project: Apache Flex
> Issue Type: Bug
> Components: Spark: List
> Affects Versions: Adobe Flex SDK 4.0 (Release)
> Environment: Affected OS(s): All OS Platforms
> Affected OS(s): All OS Platforms
> Browser: Other (specify version)
> Language Found: English
> Reporter: Adobe JIRA
> Labels: easytest
>
> If you add a validator to check that a ListBase has a selectedIndex, or has
> selectedIndices (you need a custom validator) and use IndexChangeEvent.CHANGE
> as the trigger event the ErrorSkin is always a step behind the errorString
> property.
> For instance if you validating a selectedIndex you can use a NumberValidator
> making sure that the value isn't negative.
> If you validate the ListBase with no selectedIndex is shows an error as you
> would expect, if you then select an item, the triggerEvent fires and the
> ListBase is validated again. This time it will pass the validation and the
> errorString will be set to "", but the ErrorSkin still shows due to the
> invalidation process and commitProperties no running again immediately when
> the errorString has been set. Clicking on another item in the ListBase will
> then remove the ErrorSkin as should have happened previously.
> If the selectedItem is now deselected, the errorString is set to a value, but
> no ErrorSkin is displayed, again due to commitProperties no being ran.
> Workarounds are to extend the components you want to validate and handle the
> errorString yourself (i.e. ButtonBar, List etc..), or to call
> invalidateProperties a frame later (using callLater) from inside the
> validator, meaning commitProperties is ran and the errorString is handled
> correctly.
> Using ButtonBars/Lists in forms that require validation is something that
> should be quite common. For instance it's much easier to use a ButtonBar or
> List to lay out and managed 20 RadioButtons using a RadioButtonItemRenderer,
> or I have a MultipleSelectionButtonBar class that the same also applies for
> CheckBoxItemRenderers.
--
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
