I suspect that the behaviour you are seeing is a result of the animation you use when IsEnabled becomes false. DependencyProperties actually have a precedence associated to them, in which animations are high up on the list; that hierarchy, from MSDN, is:
- Property system coercion
- Active animations, or animations with a Hold behavior.
- Local value
- TemplatedParent template properties
- Implicit style
- Style triggers
- Template triggers
- Style setters
- Default (theme) style
- Inherited from parent
- Default value from dependency property metadata
By default, animations have a FillBehavior of HoldEnd, which means that they stay at the value that the animation ended at. When IsEnabled becomes True through your binding, that update occurs at the 'Local value' level in the precedence, and since the DisableActivating storyboard is holding the appearance at a higher level of precedence ('animations with a Hold behavior'), you never see the button change once it has changed the first time.
There are three solutions to this:
- Update your animation to have a FillBehavior of Stop, which means that the animation will not assert the 'IsEnabled=False' visual once the animation stops. You'll need a standard, non-animated trigger with the same state as the end of the animation to continue to assert this once the animation completes, as otherwise you'll just see it revert back to the state it was when the animation began. Since it's just a trigger set, when the local value is updated you'll see it return to the original value like you expect. Also, since the animation is of higher precedence, you can set the style and start the animation simultaneously and only "see" the affects of the style once the animation completes (so your fade will work as expected).
- Instead of changing the FillBehavior, you can create a new trigger that applies when IsEnabled is True that animates (perhaps instantaneously) back to the original state. This can also be done by applying an animation in the trigger's ExitAction. Since it's also an animation but was applied later, it will override the HoldEnd state of the other animation. In some sense, this is easier that option 1, but it can become a hassle to maintain a forward and reverse animation, especially if you don't need the reverse animation for a specific visual effect; you may want to keep it to fade in and out the disabled state, however.
- Add an ExitAction to your IsEnabled trigger to stop the storyboard, preventing the animation from continuing to assert the value it had at the end of the animation so that the local value style can be applied. This option has the benefits of not having to repeat the style (as in #1) while also not having to reverse the animation (as in #2).
Of the three solutions, the last one is probably the cleanest architecturally (unless you have a specific reason, like needing to fade both in and out, to prefer one of the other options - or a combination of the options above).