I have been developing a new Silverlight framework for the last two months.  Well, really just the last month since it took my about a month to actually ramp up to a point where I felt comfortable writing a Silverlight framework.  The reason I am writing a Silverlight framework in the first place is that we intend on using Silverlight to enhance some of the advanced features of our our existing web apps, and perhaps to develop a new web app.  Our stuff is written in ASP.Net, so it made sense to go with other .Net-based tech. I decided that we needed to write  a framework around the time we first decided to start looking into Silverlight.  There are a lot of custom things we do in our existing ASP.Net framework, and some of that would need to be replicated for Silverlight.  When I started down this road I did not imagine I would have as much work to do as I have done.  I was actually counting on a lot of stuff in Silvelight to be extensible that is actually not extensible.  I am learning that Silverlight acts more like an API than a Framework. Consider the Timeline class.  This is the class on which multiple animations classes are based.  Storyboard, DoubleAnimation and ColorAnimation are three common classes that derive from Timeline.  Since .Net (in general) is a framework and not an API (although it contains numerous APIs) I figured I would be able to derive from Timeline to create my own, custom animation classes.  This is a common task in normal .Net land.  Many core-framework classes are written to be extensible.  Boy was I stupid for thinking such a thing about Silverlight's Timeline class!  As it turns out extending Timeline gets you nowhere.  The Timeline class, and the classes that derive from it in Silverlight, do not contain any actual animation logic.  They are really just command objects that describe some values about a particular type of animation, and the animation itself is run deep in the Silverlight runtime. This really doesn't do me any good for a couple of the tasks I would like to accomplish.  The recommendations online are either to use a timer or use a thread to drive a "game loop" to do custom animations.  Really? So this morning I set out to write a custom animation framework.  I had been thinking of this for a while, so perhaps I should admit that I started the thought experiment of "How do I write a custom animation framework in Silverlight?" a couple of weeks ago.  Still, I wrote my first line of code this morning shortly after 9:00 AM CST.  At around 4:30 PM CST I had checked in an abstract classes similar in purpose to Timeline, except it actually drives the animation.  I had further derived an abstract child for animations that target object properties for animations (most cases), a class to extend said object that animates doubles (think DoubleAnimation), a concrete child that groups animations (think Storyboard), and a class that allows the programmer to write a custom logic that is fired for every frame render.  My core logic is based on the DispatchTimer class (in System.Windows.Threading), which I chose because it does the cross-thread invocation for me. I am still missing some of the functionality that is represented in the Silverlight counterparts, and am missing several types of animations.  Additional animations should be easy to implement now that I have the base stuff written.  It should be really easy to replicate those classes found in the Silvelight version of .Net as most of those are really just numeric range animations.  I also need to implement some functionality like AutoReverse, and looping logic for my own Storyboard object (which is called GroupStory).  What does it do when all of its animations are complete?  Repeat?  And the framed animations are also a task to get to in the near future. I did all this work, it is tested and checked in, in one day.  I wrote a framework to replace an API.  As much as I like Silverlight 2.0, I wish they have waited just a little longer to get some more of these "framework vs API" things resolved.  Animation is just one of the examples of where Microsoft should have been thinking about how all of us software engineer types in the real world would be extending their functionality.  But its a big example, especially considering their target audience.  I am not kidding myself here.  I prolly have bugs waiting for me in that code.  But I can leverage it to do so many interesting things now.  It may take me the rest of the week to really work through the other animations and fix bugs.  Maybe I will still be working on it next week.  But I am just one guy, and I can accomplish this much in such a short period of time? I am also not kidding myself about the talent at MS.  IMO, .Net is Microsoft's nicest product.  They have done a stellar job with it.  C# is my favorite language.  And really, Silverlight is a wonderful run-time.  I have no doubt that those developers and managers at MS responsible for it are hard working and talented people.  I just hope that the next version of Silverlight they produce is more like a framework that the current version.

Visual States are the way Silverlight communicates basic state information about an object.  Is a button pressed?  Is a mouse over a button?  Is a button normal?  The available states for an object are indicated via decoration with the TemplateVisualStateAttribute (in System.Windows).  For example, the Button class in Silverlight looks like this:

[TemplateVisualState(Name="Unfocused", GroupName="FocusStates"),
TemplateVisualState(Name="MouseOver", GroupName="CommonStates"),
TemplateVisualState(Name="Normal", GroupName="CommonStates"),
TemplateVisualState(Name="Pressed", GroupName="CommonStates"),
TemplateVisualState(Name="Disabled", GroupName="CommonStates"),
TemplateVisualState(Name="Focused", GroupName="FocusStates")]
public class Button : ButtonBase
{
    // Methods
    public Button();
    internal override void ChangeVisualState(bool useTransitions);
    public override void OnApplyTemplate();
    protected override void OnClick();
    protected override AutomationPeer OnCreateAutomationPeer();
}

You might notice from this code that the various states also have group names.  If you look at the states it makes sense why we would want to group them.  States like Unfocused and Focused are related.  States like Mouse Over, Normal, Pressed, and Disabled are all related to how a button looks with various interactions.  Silverlight only allows one state from any group of an object to be active at once.  This also makes sense.  A button cannot be Focused and Unfocused, or Pressed and Normal, but a button can be both Pressed and Focused.  I like to think of each group like an enumeration, and the states of each group as the values that enumeration can hold. When the button switches to a new state, it does so by calling VisualStateManager.GoToState(...).  Of course there needs to be some logic to fire this switch, and this is ultimately driven by built-in events like MouseEnter, MouseDown, etc.  To switch to Focused, the code might look like:

VisualStateManager.GoToState(this, "Focused", true);

To consume visual states one uses something called a VisualStateGroup class which contains a VisualState objects, one each corresponding to a visual state decorated on the class. This object is attached to the object's template. Here is some sample XAML for the button class:

<ControlTemplate TargetType="Button"
                 xmlns:vsm="clr-namespace:System.Windows;assembly=System.Windows">
  <Grid >
    <vsm:VisualStateManager.VisualStateGroups>
      <vsm:VisualStateGroup x:Name="CommonStates">

        <vsm:VisualStateGroup.Transitions>

          <!--Take one half second to trasition to the MouseOver state.-->
          <vsm:VisualTransition To="MouseOver"
                              GeneratedDuration="0:0:0.5"/>
        </vsm:VisualStateGroup.Transitions>

        <vsm:VisualState x:Name="Normal" />

        <!--Change the SolidColorBrush, ButtonBrush, to red when the
            mouse is over the button.-->
        <vsm:VisualState x:Name="MouseOver">
          <Storyboard>
            <ColorAnimation Storyboard.TargetName="ButtonBrush"
                            Storyboard.TargetProperty="Color" To="Red" />
          </Storyboard>
        </vsm:VisualState>
      </vsm:VisualStateGroup>
    </vsm:VisualStateManager.VisualStateGroups>
    <Grid.Background>
      <SolidColorBrush x:Name="ButtonBrush" Color="Green"/>
    </Grid.Background>
  </Grid>

This markup generates a VisualStateGroup named to correspond to a group on the object. It contains visual states, each named to correspond to an existing state on the object.  The VisualStateGroup can also contain transition objects to control the transition to any given state.  The VisualState itself doesn't do anything but start a Storyboard animation.  From that animation you target objects and properties as you would any other story board.  The pieces all just fall into place! Many built-in object contain a number of visual states that you can utilize with control templates to change look and feel, but you can also create your own visual states on custom objects, and consume those states in your own custom code.  While this system is not as flexible as the event triggers built into WPF, it does allow for some interesting capabilities.