As promised, some links:

• Session deck
• Session samples
• Session recording

Also, if you haven’t already, please take the time to fill out the online evaluation.  Your comments help me be a better speaker. 

The overall breaking change list can be found here.

Control Model Silverlight 2 RTW Updates

• generic.xaml lives in themes directory
  • For WPF compat, we’re now looking for generic.xaml at \themes\resources.xaml.  It still needs to be built as an assembly resource.
• VisualTransition.GeneratedDuration
  • The VisualTransition.Duration’s property name has changed.  It is now called VisualTransition.GeneratedDuration.
  • This value will only impact the duration of generated transition animations.  It has no affect on the VisualTransition.Storyboard animations.
• VisualTransition.Storyboard must be defined inline
  • You cannot set VisualTransition.Storyboard to be a storyboard resource.  It needs to be defined as content of the <VisualTransition>.

HTTP Networking Silverlight 2 RTW Updates

• Cross-scheme HTTP <-> HTTPS calls are allowed with a cross domain file.
  • See my Networking Tutorial for more details
• Sub-domain wildcards are allowed within a clientaccesspolicy.xml cross domain file
  • See my Networking Tutorial for more details
• Setting the Content-Type is always allowed on cross domain POSTS
  • Of course, the cross domain POST itself needs to be allowed by the service’s cross domain policy file.
  • All other headers still need to be explicitly allowed in the service’s cross domain policy file.

Hope to see you there!

ScottGu, our VP, has a great release blog post, which is worth a read.

You can get all the new SL2 downloads here:

1. Install Silverlight 2 runtime.
2. Install Silverlight Tools for Visual Studio 2008 SP1
3. Install Expression Blend 2 SP1 update.  (If you don’t already have Expression Blend 2, you can get a free trial.)

On a personal note, it’s been a privilege to work with such a great group of people to put out this product.  I’ve learned a lot, and more importantly, had a lot of fun.  So, a shout out to my teammates - you guys rock.  This one was special.

p.s.  And yes, I promise to update all my tutorials for RTM soon.  Real soon.  Ok, probably next week. 

At http://nbcolympics.com/video, you can see live event coverage as well as on-demand viewing of already-happened events.  Check it out!  (Be sure to use the “Enhanced” player by clicking “Enlarge Video.”)

VisualStateManager will be added in to a future release of the .NET Framework.  For those of you who want an early look, you can now play with John’s VSM implementation.  (This is for prototyping only - it is not a supported feature yet.)  He uses AttachedProperties to hook up VisualStateManager-enabled Templates to WPF controls.

You’ll also see my WeatherControl using VSM on WPF!

There are a bunch of different “interpolations” that you can choose from, including “back”, “elastic”, and “bounce.”

I’ve updated my FlickrViewr to use this animating wrap panel with the “elastic” option.  In my totally unbiased opinion, it looks pretty hot.  Though, as Dave pointed out, “elastic” is a bit much for a “real world” application - for a more sane UI, try “back” interpolation.

(See the original post for more info & source code.)

Enjoy!

(See the original post for more info & source code.)

Today, we’ll go through some general recommendations on how to use the Parts & States model.  We’ll also take a look ahead:  VisualStateManager on Windows Presentation Foundation and future releases of Silverlight.

(Series Link:  Part 1, Part 2, Part 3, Part 4)

Parts & States Model Recommendations

1.  Use the Parts & States Model with Custom Controls and UserControls

Like we mentioned in the first post, the Parts & States Model is just a pattern.  It is not required by the runtime, and it’s perfectly fine to build controls without the Parts & States Model and VisualStateManager.

However, we do think this is a good model.  And Blend will only be able to support skinning of custom controls using the Parts & States Model.

And while this series concentrated on VSM with Custom Controls, remember you can use it with UserControls as well!

2.  Custom VSM xmlns

This one is less of a recommendation and more of a heads up.

Because of a known Silverlight 2 Beta 2 bug, you need to use a custom xmlns for VisualStateManager and its related classes.

   1: xmlns:vsm=“clr-namespace:System.Windows;assembly=System.Windows”

For consistency across controls, we recommend the following naming convention.

4.  CommonStates and FocusStates are special

Many controls define these two state groups:

If your control is going to have some or all of these states, for consistency, we recommend the above grouping and naming.

5. Be resilient to missing Parts & States in template

There are many reasons why a particular ControlTemplate might not supply a given part or state:  the designer may have deliberately chosen to leave it out.  He/she might not have created it yet.  And so on.

It is good practice to prevent crashes or other catastrophic failures when a part is missing.

Note: The VisualStateManager.GoToState() method already takes care of this for states - it returns false when the target VisualState is not found.

6.  Consider supporting “fallback” states

For complex controls, it is sometimes interesting to provide a fallback mechanism for particular states that do not exist.

   1: if (VisualStateManager.GoToState(this, “FocusContent”, useTransitions) == false) 

   2: {  

   3:     VisualStateManager.GoToState(this, “Focus", useTransitions);

   4: } 

The advantage of this approach are pretty intuitive:  the control continues to visually function correctly when a designer hasn’t provided a particular state.

But there are also some significant negatives: the fallback states mechanism isn’t fully integrated into the Parts & States model, which means that Blend has no way of knowing about them.

So, please use fallback states sparingly and only when the control is sufficiently complex enough to warrants it.

Also, if you think this is a pattern that you’ll leverage often, let us know!  We’d love the feedback.

7.  Subclasses should only add states in new state groups (not existing state groups)

As you know, each state group is orthogonal.  This makes it easy for a subclass to add new state groups.  For instance, you can create a StackButton that derives from Button and adds a StackStates group:

This works because the StackStates state group logic is completely independent from the Button’s logic around CommonStates & FocusStates.

However, if you want to add a new state to an existing state group, the state group logic can become jumbled.  It’s is difficult to guarantee that the right logical state checks will happen in the right order.

Let’s make this clearer with an example.  BasicControl defines two states in its CommonStates: Normal, MouseOver.  Its logical state machine is:

• if (mouse is not over control) goto Normal
• if (mouse is over control) goto MouseOver

Now, ExtendedControl derives from BasicControls and wants to add a Pressed state.  The goal logical state machine would be:

• if (mouse is not over control) goto Normal
• if (mouse is over control AND mouse button is not down) goto MouseOver
• if (mouse button is down) goto Pressed

However, there is no good for way for ExtendedControl to add the (AND mouse button is not down) check for the MouseOver state, since that logic lives in the Button base class.

All this just means:  Subclasses can always add new states to an new state group.  But we recommend against adding new states to existing state groups.

Note:  There are different ways (each with its own pluses & minuses) for the platform to address this limitation in a future version.  We’re currently leaning towards a Triggers-based solution (yes, I said triggers).  For more, keep reading.

Looking Ahead

VSM & Windows Presentation Foundation

Silverlight’s Parts & States Model leverages many features (like ControlTemplates, GetTemplateChild() helpers, etc) that already exist in Windows Presentation Foundation.

However, there are some features - namely VisualStateManager and its associated classes - that do not yet exist in WPF.   The good news is that the next version of Windows Presentation Foundation will include VisualStateManager!

For some that are trying to move their Siverlight 2 controls & skins to WPF now, the next version of the .NET framework may feel a ways off.  To help remedy that, we are currently looking into shipping a WPF assembly that contains VisualStateManager before the next full release of WPF.  Plans are still early - and so the timeline & ship vehicle details are still being worked out.

More details as we have them!

Future Silverlight Features

One of the often asked questions about the Silverlight control model is:  “Where are the Triggers?”  In fact, it’s normally, “Where are the TRIGGERS?????” 

There are a lot of different reasons why we were not able to bring Triggers into the Silverlight 2 release.  The primary technical challenge was that our property system architecture is not sufficiently complex to support them.  This will however change in a future version of Silverlight, and then we’ll be able to start supporting Triggers.

How would Triggers & VSM play together?  The tentative design brainstorm looks something like:

   1: <PropertyTrigger Property="IsPressed" Value="True">  

   2:     <GoToState State="Pressed"/>

   3: </PropertyTrigger>

The platform would provide a GoToState trigger action that causes VisualStateManager to initiate a state change to the desired state.

The designer would, then, have the option of using the built-in states that come with the control (and leaving the visual state change logic to the control).  OR, he/she can take over and trigger all the VSM state changes from XAML.  In the latter case, it would also be possible for the designer to add states to new or existing state groups that a control code does not know about.

Exciting stuff coming!

The End

So that’s the end of our 4 part series on the Silverlight 2 Parts & States Model.  If you have questions or feedback, we’d love to hear it.

If this series has wet your appetite for VisualStateManager, here are some more great resources:

• Christian Schormann’s Blog (Group Program Manager for Expression Blend)
  • Creating Control Skins with Visual State Manager - An Introduction
  • Visual State Manager: Goals
  • Visual State Manager for User Controls: A Simple Chord Finder Example
• Steve White’s video tutorials (Program Manager for Expression Blend)
  • Expression tutorials
• Celso Gomes’s tutorials (Designer for Expression Blend)
  • http://www.nibblestutorials.net/
• Tim Heuer’s Blog (Senior Program Manager on the .NET Developer Platform)
  • Skinning Silverlight controls just got easier
  • Silverlight and the VisualStateManager
• Jesse Liberty’s tutorials (Senior Program Manager on the .NET Developer Platform)
• Styles, Templates, and VisualStateManager
• Scott Guthrie’s Blog (Corporate Vice President of the Developer Division)
  • Silverlight 2 Beta2 Released

Last time, you learned how to reskin an existing control using VisualStateManager.  In this post, you’ll see how to build up a Parts & States-based custom control.  We’ll also explore how you can create more sophisticated visual transitions.

(Series Link:  Part 1, Part 2, Part 3, Part 4)

VisualStateManager

We’ve saw it briefly in the last post, but let’s formally introduce VisualStateManager. 

VisualStateManager is the class responsible for control visual state management.  The “visual” modifier in that sentence is important - the control logic remains in charge of the logical state machine.

VSM exposes two main pieces of PME:

• a VisualStateGroups attached property
  • This property is set on the control template’s root visual and contains all the visual states & transitions for that skin
• a static GoToState() method 
  • This method causes VisualStateManager to transition the control’s visuals from one visual state to another.

Last time, we concentrated on the VisualStateGroups property in XAML.  Today, we’ll dig into how the control code leverages that GoToState() method.

WeatherControl

The custom control that we’ll be looking at today is a simple WeatherControl. The shell of the control code can be found below.  (Note: For readability, I’ve collapsed some of the code snippets.  You can find the full sample code here.)

   1: public class WeatherControl : Control

   2: {

   3:  

   4:     public WeatherControl()

   5:     {

   6:         DefaultStyleKey = typeof(WeatherControl);

   7:     }

   8:  

   9:     // OnApplyTemplate()

  10:     public override void OnApplyTemplate()

  11:     {

  12:         base.OnApplyTemplate();

  13:     }

  14:  

  15:     // Temperature DP

  16:     public static readonly DependencyProperty TemperatureProperty = = DependencyProperty.Register("Condition", typeof(Condition), typeof(WeatherControl),null);

  17:     public string Temperature

  18:     {

  19:         get { ... }

  20:         set { ... } 

  21:     }

  22:  

  23:     // Condition DP

  24:     public static readonly DependencyProperty ConditionProperty = DependencyProperty.Register("Condition", typeof(Condition), typeof(WeatherControl), new PropertyMetadata(new PropertyChangedCallback(WeatherControl.OnConditionPropertyChanged)));

  25:     public Condition Condition

  26:     {

  27:         get { ... }

  28:         set { ... }

  29:     }

  30:  

  31:     // ConditionDescription DP

  32:     public static readonly DependencyProperty ConditionDescriptionProperty = DependencyProperty.Register("ConditionDescription", typeof(string), typeof(WeatherControl), null);

  33:     public string ConditionDescription

  34:     {

  35:         get { ... }

  36:         set { ... }

  37:     }

  38:  

  39:     // Property change notification

  40:     private static void OnConditionPropertyChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)

  41:     {

  42:         WeatherControl weather = d as WeatherControl;

  43:         ...

  44:         weather.OnWeatherChange(null);

  45:     }

  46:  

  47:     // OnWeatherChange virtual

  48:     protected virtual void OnWeatherChange(RoutedEventArgs e)

  49:     {

  50:     }

  51:  

  52: }

You can see that our WeatherControl…

• is a custom control, deriving from Control.
• defines its own built-in style, as indicated by the DefaultStyleKey.
• has 3 public dependency properties: 
  • Temperature
  • Condition
  • ConditionDescription

In order to make our WeatherControl skinnable with VSM, we need to:

• define a control contract
• discover & manipulate parts
• wire up appropriate state changes using VisualStateManager

Here we go!

Defining the Control Contract

The control code is responsible for documenting the control contract.  This means it should declare any and all expected Parts and States.  This is done using class level metadata:

   1: [TemplatePart(Name="Core", Type=typeof(FrameworkElement))]

   2:  

   3: [TemplateVisualState(Name="Normal", GroupName="CommonStates")]

   4: [TemplateVisualState(Name="MouseOver", GroupName="CommonStates")]

   5: [TemplateVisualState(Name="Pressed", GroupName="CommonStates")]

   6:  

   7: [TemplateVisualState(Name="Sunny", GroupName="WeatherStates")]

   8: [TemplateVisualState(Name="PartlyCloudy", GroupName="WeatherStates")]

   9: [TemplateVisualState(Name="Cloudy", GroupName="WeatherStates")]

  10: [TemplateVisualState(Name="Rainy", GroupName="WeatherStates")]

  11: public class WeatherControl : Control

  12: {

  13:     ...

  14: }

In the above snippet, there are two attribute classes:

• TemplatePartAttribute
  • Specifies the name of the part & expected type
• TemplateVisualStateAttribute
  • Specifies the name of the state & its associated state group

This metadata is not used by the runtime.  However, it is leveraged by tools like Expression Blend for their skinning support. 

These attributes on the WeatherControl give rise to this control bill of materials:

Now, let’s see how the control code manipulates Parts.

Discovering Parts

Parts are named elements in the template and need to be manually discovered by the control code.  This is done in the OnApplyTemplate() virtual, which is called whenever a new template is applied.

   1: // OnApplyTemplate

   2: public override void OnApplyTemplate()

   3: {

   4:     base.OnApplyTemplate();

   5:  

   6:     CorePart = (FrameworkElement)GetTemplateChild("Core");

   7: }

   8:  

   9: // private CorePart property

  10: private FrameworkElement CorePart

  11: {

  12:     get

  13:     {

  14:         return corePart;

  15:     }

  16:  

  17:     set

  18:     {

  19:         FrameworkElement oldCorePart = corePart;

  20:  

  21:         if (oldCorePart != null)

  22:         {

  23:             oldCorePart.MouseEnter -= new MouseEventHandler(corePart_MouseEnter);

  24:             oldCorePart.MouseLeave -= new MouseEventHandler(corePart_MouseLeave);

  25:             oldCorePart.MouseLeftButtonDown -= new MouseButtonEventHandler(corePart_MouseLeftButtonDown);

  26:             oldCorePart.MouseLeftButtonUp -= new MouseButtonEventHandler(corePart_MouseLeftButtonUp);

  27:         }

  28:  

  29:         corePart = value;

  30:  

  31:         if (corePart != null)

  32:         {

  33:             corePart.MouseEnter += new MouseEventHandler(corePart_MouseEnter);

  34:             corePart.MouseLeave += new MouseEventHandler(corePart_MouseLeave);

  35:             corePart.MouseLeftButtonDown += new MouseButtonEventHandler(corePart_MouseLeftButtonDown);

  36:             corePart.MouseLeftButtonUp += new MouseButtonEventHandler(corePart_MouseLeftButtonUp);

  37:         }

  38:     }

  39: }

To find a named element inside of the template, you use the GetTemplateChild() helper method.

In the above example, we discover the “Core” part, which we will use to determine when the control should go into the MouseOver or Pressed states.  Note that the setter logic is resilient to the Core part not being in the template.  This is important, because a control needs to be robust enough to handle a part that is missing or not yet been added.

Initiating State Changes

The control code is responsible for telling VisualStateManager when a visual state change should occur.  Therefore, it must maintain the logical state machine that is associated with the visual state machine.

All of Silverlight 2’s built-in controls create a simple helper method to assist with the state changes.  We recommend that you follow a similar pattern:

   1: // GoToState() helper

   2: private void GoToState(bool useTransitions)

   3: {

   4:     //  Go to states in NormalStates state group

   5:     if (isPressed)

   6:     {

   7:         VisualStateManager.GoToState(this, "Pressed", useTransitions);

   8:     }

   9:     else if (isMouseOver)

  10:     {

  11:         VisualStateManager.GoToState(this, "MouseOver", useTransitions);

  12:     }

  13:     else

  14:     {

  15:         VisualStateManager.GoToState(this, "Normal", useTransitions);

  16:     }

  17:  

  18:     //  Go to states in WeatherStates state group

  19:     if (Condition ==  Condition.PartlyCloudy)

  20:     {

  21:         VisualStateManager.GoToState(this, "PartlyCloudy", useTransitions);

  22:     }

  23:     else if (Condition == Condition.Sunny)

  24:     {

  25:         VisualStateManager.GoToState(this, "Sunny", useTransitions);

  26:     }

  27:     else if (Condition == Condition.Cloudy)

  28:     {

  29:         VisualStateManager.GoToState(this, "Cloudy", useTransitions);

  30:     }

  31:     else

  32:     {

  33:         VisualStateManager.GoToState(this, "Rainy", useTransitions);

  34:     } 

  35: }

The GoToState helper method contains a series of if statements which determine the current visual states.  It then tells VisualStateManager to initiate the appropriate state change.  This is done with the static public static bool VisualStateManager.GoToState(Control control, string stateName, bool useTransitions) method.

As you can see, this method…

• has 3 parameters:
  • control: instance of the control
  • stateName: name of the visual state to go to
  • usetTransitions: flag to determine whether transitions should be run in this state change
• returns a bool
  • It returns true if the state name was found and false otherwise.
• is a no op if…
  • the control was already in the passed in visual state
  • the visual state cannot be found

Most control authors will call their GoToState() helper in 3 places:

• OnApplyTemplate() with no transitions. 
  • When the control first appears, we generally want it to just appear in the appropriate state, and not transition into it.
• In certain property change notification handlers
• In certain event handlers

For our WeatherControl, we add these calls:

   1: // OnApplyTemplate

   2: public override void OnApplyTemplate()

   3: {

   4:     base.OnApplyTemplate();

   5:  

   6:     CorePart = (FrameworkElement)GetTemplateChild("Core");

   7:  

   8:     GoToState(false);

   9: }

  10:  

  11: // Property Change Notifications

  12: protected virtual void OnWeatherChange(RoutedEventArgs e)

  13: {

  14:     GoToState(true);

  15: }

  16:  

  17: // Event Handlers

  18: void corePart_MouseEnter(object sender, MouseEventArgs e)

  19: {

  20:     isMouseOver = true;

  21:     GoToState(true);

  22: }

  23:  

  24: void corePart_MouseLeave(object sender, MouseEventArgs e)

  25: {

  26:     isMouseOver = false;

  27:     GoToState(true);

  28: }

  29:  

  30: void corePart_MouseLeftButtonDown(object sender, MouseButtonEventArgs e)

  31: {

  32:     isPressed = true;