A while back, a friend of mine and fellow Flex developer was consulting on a Flex 4 based application.  He was having a troublesome issue where in some cases the skin state was not updating in his application when he called invalidateSkinState().  The problem was that when he called invalidateSkinState(), the getCurrentSkinState() was never called during the next commit properties phase (think validation during maturity, eee our whitepaper for more details). It wasn't consistent in the code and it only happened in a few specific cases. 

He asked me if I had ever seen the issue where getCurrentSkinState() is skipped after calling invalidateSkinState(). At that time I had never seen a problem with the Skin state not updating, so I didn't have much guidance for him.  He found a solution which involved making sure to call both invalidateSkinState() and invalidateProperties() at the same time, even though invalidateSkinState() should also invalidate properties for you.

About three weeks later, I stumbled upon the same issue while working on an application.  Inexplicably, one of my components started ignoring invalidateSkinState() and the skin wouldn't change.  After setting some breakpoints and screaming at the code for a while I finally figured out what the cause was.  I had mistakenly used invalidateSkinState() within the commitProperties() after calling super.commitProperties():

/* don't do this... */
override protected function commitProperties():void {
     // call super first

     super.commitProperties();

     ... calculate data, set the flag if the skin needs to change ...

     // set the skin state
     if(_flag) {
          _stateIWant = "stateName";
          invalidateSkinState();
     }
}

I am simplifying the code dramatically, but what I was trying to do was during the commit phase I was calculating a lot of data set by a dataProvider.  If the data had certain properties I needed to change the state of my skin, and that was why I was calling invalidateSkinState() post-data calculation. The core issue was that during the setting of the dataProvider, I had no idea if my skin had to change or not because the new data had to be processed before I could determine what state I needed to be in.  At that point, I still wanted to delay the data processing until the commit phase, so I deferred the calculation until later and then post-calculation I could set the proper state.

Looking back, this was clearly a bad thing to do but at the time it seemed like a reasonable request. The problem with this call is around order of operation. Let's look at the order of operation within the UI component:

1. Invalidation
   1. invalidateProperties() is called
   2. invalidateProperties() sets invalidatePropertiesFlag = true
   3. The component registers with LayoutManager for the next validation pass
2. Validation
   1. LayoutManager begins the validation pass (started by ENTER_FRAME / RENDER event)
   2. LayoutManager calls validateProperties() on the invalid component
   3. validateProperties() determines if invalidatePropertiesFlag is set to true
   4. if true, validateProperties() calls overridden commitProperties()
   5. overridden method first calls super.commitProperties()
   6. super.commitProperties() determines if the skinStateIsDirty has been marked true (set via invalidateSkinState())
   7. if skinStateIsDirty is true it calls getCurrentSkinState() to get the state name
   8. super is complete and returns to the overridden method
   9. we process the data, determine the skin needs to change
   10. we call invalidateSkinState()
   11. invalidateSkinState() sets skinStateIsDirty to true and calls invalidateProperties()
   12. invalidateProperties checks to see if invalidatePropertiesFlag is already set to true
   13. invalidatePropertiesFlag is set to true (we are still validating at this point), so invalidateProperties() does not re-start the invalidation process
   14. commitProperties is complete, and returns to validateProperties(), remember we are synchronous at this point
   15. invalidatePropertiesFlag is set back to false
   16. validation process is complete
3. Re-Invalidation
   1. At some point post the last validation pass, we call invalidateSkinState()
   2. invalidateSkinState() checks skinStateIsDirty, which is still set to true so invalidateProperties() is not called

At there lies the crux of the issue.  The problem is that when we call invalidateSkinState() it still thinks the skin flag is dirty, meaning we are already waiting for a validation pass and therefore we don't restart the invalidation process.  This means that our skin flags are now out of sync and we get odd behavior until the next full invalidation process goes through. Of course we may keep re-entering into the same conflict over and over depending on how circular our logic is in the code.

The way to fix this is to move our logic BEFORE the super call:

/* acceptable fix */
override protected function commitProperties():void {
     // do our code first
     if(_flag) {
          _stateIWant = "stateName";
          invalidateSkinState();
     }

     // then call super
     super.commitProperties();
}

This allows the invalidateSkinState() method to set the skinStateIsDirty flag to true before the super is called and will prevent the issue.

Finally, in 99% of the cases you won't need to call invalidateSkinState() within commitProperties(). You will more then likely want to call invalidateProperties() and invalidateSkinState() at the same time.  But remember, you will still need to do all your skin state flag calculations BEFORE calling super so that commitProperties() and getCurrentSkinState() process the flags correctly.