My use-case
Recently I’ve tried to introduce skin states to the pretty complex UI component in Adobe Flex 4. I have got puzzled by the behaviour that my invalidateSkinState() calls never had triggered execution of getCurrentSkinState method that controlls the current UI component skin state value as expected.
[pullquote]Invalidation of the same phase while processing that phase is ignored – by Alex Harui[/pullquote]
Under closer examination I found out that I fall into the same invalidation trap that James Polanco did in November 2010.
I must stress out that it was easy to fall into this trap in my case because inside “commitProperties” call I was doing pretty complex calculations that involved, for example, the creation of display object sub-children, listening for “preinitialize” events from those sub-children, reacting to it, etc.
To cut the talk short, to prevent this property invalidation trap from happening I suggest to always follow the simple rule of the thumb:
When overriding “commitProperties” put “super.commitProperties” call to the end of the method
override protected function commitProperties():void { if (myPropertyChanged) { disableMyUIComponent = true; invalidateSkinState(); myPropertyChanged = false; } super.commitProperties(); } override protected function getCurrentSkinState():String { var returnState:String = "normal"; // Use information in the class to determine the new view state of the skin class. if (disableMyUIComponent) { returnState = "disabled"; } return returnState; } |
Futher reading:
Discussion at 2008 at Flexcoders mailing list (yeah, at that time, this mailing list was more interesting to read) “Must call super.commitProperties at END of overrided commitProperties when extending XXXX?”