[ 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