The question is old - but in case someone else stumbles across it with the same problem...
your code is right, but you have to do a little extra in order to convince the ItemRenderer that it needs to reevaluate its current state.
check out my answer to another post here: http://forums.adobe.com/message/3206112#3206112
I believe that same approach outlined there will address your concerns on this issue too.
Thanks Lee, that worked.
Oddly enough, the initial state is set but the MXML states are not implemented. So if I set a renderer to say, "hover", and set a color in the MXML for "hover", it will ignore the color even though the currentState is, in fact, "hover". Annoying as hell, and must be a bug.
Not sure why it happens, and I don't feel like digging into the inheritance tree to find out.
FYI - I think I see what the problem is.
If you look at the Flex Spark ItemRenderer, they have a private flag named rendererStateDirty that is true only one time after initialization to force an initial state change. The problem is that the state change occurs AFTER super.commitProperties so any states you set in the MXML document are ignored.
To fix it, your code works, or using a flag to force the state change after initialization before super.commitProperties().
@Scipio_BF2, I'm glad it was helpful. And of course, you're right - the spark ItemRenderer uses the renderStateDirty flag as a "short-circuit" to force the component to evaluate its state once at initialization, prior to the initial run of commitProperties(). Unfortunately, renderStateDirty is private, so you can't access it from your derived class, and even if you could, it wouldn't allow you to force reevaluation of the state later in the lifecycle.
Fortunately there is a fairly easy way to go here. Regardless of how and when you set the state, all you have to do is call invalidateProperties() at some point *after* you made your state change. The spark code will take care of the rest:
if you don't call invalidateProperties(), the state will be changed, but your component will fail to render the corresponding state-dependent mxml property changes. This is almost certainly what's going on in the case you described.
The code I suggested is an alternate approach that shouldn't be mixed with setting the state directly. My approach works well when all your state determination logic can encapsulated in the function getCurrentRendererState(). In that case, you would never need to call setCurrentState() directly. Instead, you'd change the relevant properties of your application's model, and then call invalidateProperties() - and that's all. From that point, the override of commitProperties() takes care of everything else for you: it calls getCurrentRendererState(), then setCurrentState(), and finally super.commitProperties(). Because the order is enforced in commitProperties, the state will always get set *before* the super-class runs commitProperties(); and so you'll never have to worry about your state-dependent mxml not getting properly applied.