Understanding the new features of Silverlight 2 Beta2
page 2 of 8
by Scott Guthrie
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 29356/ 69

UI and Control Improvements

Silverlight 2 Beta2 includes a bunch of work in the UI and Control space:

More Built-in Controls

In Beta 1 only a few controls were included with the core Silverlight setup.  Most common controls (including Button, ListBox, Slider, etc) were shipped within separate assemblies that you had to bundle with your applications (which increased the app download size).  Beta 2 now installs 30+ of the most common controls as part of the core Silverlight 2 download.  This means that you can now build Silverlight 2 applications that use core controls that are as small as 3kb in size - making Silverlight application downloads small and startup time fast.

In addition to the core controls included with the base Silverlight 2 setup, we are also this week shipping additional higher-level controls that are implemented in separate assemblies that you can then reference and include with your applications.  This includes controls like DataGrid (more details on its new Beta2 features below), Calendar (now with multi-day selection and blackout date support in Beta2), and a TabPanel control (new in Beta2).

We ultimately expect to ship over a 100 controls for Silverlight.

Control Template Editing Support

One of the most powerful features of the WPF and Silverlight programming model is the ability to completely customize the look and feel of controls.  This allows developers and designers to sculpt the UI of controls in both subtle and dramatic ways, and enables a tremendous amount of flexibility.  I covered these concepts a little in my previous Silverlight Control Templating blog post here.

This week's Expression Blend 2.5 June Preview now adds designer support for editing control templates - which makes it easy for you to quickly change the look of any control without having to drop-down to XAML source to-do it. 

To see control template editing in action, just drag/drop two Slider controls onto the Expression Blend design surface:

Figure 1

We might decide that the slider head in the default Slider control template is too large and wide for our application.  To use control template editing to change it, we can right-click on one of the sliders in the designer and select the "Edit Control Parts" context menu item.  We can choose to create a new empty control template for our slider (and start from scratch), or alternatively edit a copy of the built-in control template (and start from that and tweak it):

Figure 2


After we choose to edit a copy of the existing control template, Blend will prompt us to create and name a re-usable style resource that we'll define our control template within.  We can name it and then choose to store the style at either the application level (within App.xaml) or within our current page/user-control:

Figure 3

When we click "ok" we'll find ourselves in template editing mode for our Slider control.  We can change, tweak, or add/remove any of the underlying elements within the Slider control's template.  Notice below how in template editing mode we can see and select any of the underlying elements that make up the slider's control template (these are circled in red below in the "Objects" window).

To make our slider head narrower, we can select the "HorizontalThumb" element within the control template and adjust its width (either graphically or via the property grid):

Figure 4

We can then use the breadcrumb navigation bar at the top of the designer to navigate back to our page and see the control template changes applied:

Figure 5

Notice that right now only one of our slider controls is using the new Style resource with the control template we defined. 

To apply the same style resource to the other slider control as well, we can select it, right-click, and then use the "Apply Resource" context menu to apply our "ScottSlider" style to it as well:

Figure 6

Once we do this both our sliders reference the same style:

Figure 7

Changes we make to the "ScottSlider" style going forward will automatically apply to both controls.

Note that all controls shipped with Silverlight 2 support control templates and will support the above editing experience in Expression Blend.

Visual State Manager (VSM) Support

Control templates in Silverlight and WPF support customizing both the "look" of a control, as well as the "feel" of a control.  By "feel" I mean changing its interactive responsiveness.  For example: how it reacts when pushed, when it gets focus, loses focus, is in a pushed state, is in a disabled state, has something inside it selected, etc.  Often you want animations to execute when the user interacts with a control like this.

One of the new things we are introducing with Silverlight 2 Beta2 is a "Visual State Manager" (VSM) feature that makes it much easier to build interactive control templates.  VSM introduces two basic concepts that you can take advantage of within control templates: "Visual States" and "State Transitions".  For example, a control like Button defines multiple visual states for itself - "Normal", "MouseOver", "Pressed", "Disabled", "Focused", "Unfocused".   When in template editing mode in Blend, designers now have the ability to easily edit what the button looks like in each particular state, as well as setup transition rules to control how long it should take to animate when moving from one state to another.  At runtime Silverlight will then dynamically run the appropriate animation Storyboards to smoothly move the control from one state to another.

What is nice about this model is that designers do not need to write code, do not need to manually create animation storyboards, and do not need to understand the object model of controls in order to be productive.  This makes the learning curve for creating interactive control templates really easy, and means that existing graphic designers can very easily work on Silverlight projects.  Later this year we will also be adding Visual State Manager (VSM) support to WPF as well, which will let you use the same approach with Windows applications as well as share control templates between WPF and Silverlight projects.

To see an example of this in action, let's add a Button control onto our design surface:

Figure 8

We can then right click on the button and edit its control template. Instead of starting with the existing default control template (like we did with the slider example above), let's create an empty control template and start from scratch:

Figure 9

Blend will prompt us for the name of the Style resource we want to create.  We'll name it "ScottButton" and click ok.  This will then put the designer in control editing mode for the Button, and start with an empty control template:

Figure 10

One of the things to notice above is the new "States" window inside Blend.  This will show us all of the available "Visual States" that the Button control exposes.  Above the "Base" state is currently selected - which allows us to define the common visual tree of our Button control template. 

We can then add some vector elements into our base state that defines the look of a custom button like below.  We could use the built-in vector drawing tool support provided by Blend to author these graphics, or alternatively use Expression Design or Adobe Illustrator to build the vector art and then import it into Blend.  Below we are adding 4 "Path" elements into our control template - one a rounded background (named "background"), one a drop shadow (named "shadow"), one a 40% opacity "shine" that adds a glow near the top, and one that defines the default inner content (in this case a picture of a house):

Figure 11

Note: we could have alternatively imported an image, but using vector elements will give us the flexibility to scale/stretch/transform the button later and retain a crisp look and feel at any resolution or scale (particularly useful with Silverlight mobile scenarios - where screen resolutions might be different or smaller).  It will also allow us to easily animate/change any vector element within the artwork.

Once we've finished designing our base state above, we can press F5 to run our application in the browser:

Figure 12

As you can see above - our Button control now has a nicer look.  Despite its new look, the button still raises the same focus, click and hover events just like before - so a developer using the button does not need to change any code when working with a button that uses our new control template.

One downside with our new button control template, though, is that it isn't interactive.  This means that I don't get any visual feedback if the button gains/looses focus, or if a mouse hovers over it.  I also don't get a nice depress/bounce-back animation when I click it.

To add interactivity to our button, we'll return back to Blend and work with our Button's control template again.  Previously we added vector graphic elements to the "Base" state of our Button control.  This allowed us to define the default visual look of all visual states of our Button.  We can now go back and customize individual Button visual states further.

For example, to implement a mouse-over behavior for our Button, we can select the "MouseOver" state in the "States" window, and then tweak the look of the button when it is in that state.  Below I've selected the "shine" vector element inside our control template and adjusted its Opacity property in the property grid to have it be more visible when in the MouseOver state.  Notice how Blend automatically highlighted the "Shine" element with a red dot and then listed the Opacity property below it in our objects window.  This makes it easy to quickly track all changes that we've made between the "Base" state and the "MouseOver" state in our control template:

Figure 13

We can then select the "Pressed" state in the "States" window, and customize what a button looks like when it is pressed.  We'll change two things from the "base" state.  The first change is to make the "shine" element visible (like the MouseOver state). The second change will be to slightly offset the contents of the button control - while keeping the shadow element stationary.  This will give the button a nice "depressed" look and contrast nicely with its base visual:

Figure 14

We can implement the offset change to the background, content and shine elements by selecting them in the designer, and then apply an offset render transform to them in the property browser:

Figure 15

And now when we run our application again in the browser, we'll find that our Button now has interactive visual feedback when it is being used.  Below is the "normal" look of our Button:

Figure 16

Hovering the mouse over the Button will then cause it to glow like below:

Figure 17

Clicking the button will then cause it to depress and hide the shadow (it will then bounce back once the mouse button is released):

Figure 18

Note that we did not have to write any code or XAML to change our Button's look and feel - the new Visual State Manager feature automatically handled moving between visual states for us. 

By default Silverlight dynamically constructs and runs a transition Storyboard for you as you move from visual state to visual state (providing a smooth animation between the two states).  You do not need to write any code in order to make this happen (note: you do still have the ability to drop down and add a custom Storyboard transition if you want to, but for most cases you can probably use the automatic Storyboard transition).

One feature you can take advantage of with Silverlight's automatic transition feature is to customize the time duration it takes for a visual state transition to occur.  You can do this by clicking the arrow to the right of a visual state and setup a rule that controls how long it should take the transition animation to run when moving from one particular state to another.

For example, we could indicate that we want it to take .2 seconds to transition from the "Normal" to "MouseOver" visual state by adding the rule below:

Figure 19

We can then configure this rule to take .2 seconds to transition between Normal->MouseOver like so:

Figure 20

We can then click on the "MouseOver" state and setup a rule that causes the transition from MouseOver->Normal to take .4 seconds:

Figure 21

Now when we re-run our application we'll have slower animation transitions for MouseOver scenarios, which adds a slightly smoother and more polished feel to our application.  We did not have to write a single line of code to enable this.  All controls shipped with Silverlight 2 will have built-in support for Control Template and Visual State Manager customization like above.

To learn more about the new Visual State Manager and Control Template Editing features, please check out the tutorials here and here, and the videos on it here, here, and here.


Beta2 includes some significant improvements to the built-in TextBox editing control.  Text scrolling with text-wrap, multi-line text selection, document navigation keys, and copy/paste from the clipboard are now supported.

Beta2 also now includes IME Level 3 input support (including candidate window selection) for non-western character sets:

Figure 22

Input Support

Beta2 adds additional keyboard support in FullScreen mode (arrow, tab, enter, home, end, pageup/pagedown, space).  Note: full key input support isn't allowed to avoid password spoofing scenarios.

Beta2 also adds new APIs to support inking and stylus input support.

UI Automation and Accessibility

Beta2 adds UI Automation Framework support into Silverlight.  UI Automation (or UIA) enables screen readers and other assistive tools to identify and interact with the components that make up your Silverlight 2 application.

Beta2 uses the UIA framework and adds UIA based behaviors to an initial set of Silverlight controls.  By the final release of Silverlight 2 all controls will have UIA based behaviors built-in.  We will also add support for high-contrast scenarios.  These features will enable you to build accessible, section 508 compliant, applications.  This UIA support will also enable automated UI testing of applications.

Animation and Graphic System

Beta2 adds support for animating custom dependency properties.  Object animation support (animating structs) is also now supported.  Beta2 also supports the ability to create Storyboards in code that can animate parts of the render tree without having to be added to it (allowing you to embed animations entirely in code).  Per frame animation callback support will be added in the final release.

Beta2 includes a new Visual Tree Helper static class that provides advanced visual tree inspection APIs.  It provides features such as the ability to enumerate children of an element and getting the ancestor/parent of a given reference element.  These APIs work against any UIElement you pass to it.


Beta2 now supports an XML based manifest file for DeepZoom collections.  Beta2 also adds extensible MultiScaleTileSource support for DeepZoom (which allows developers to hook up existing image pyramids that don’t conform with the Deep Zoom format to the high performance rendering of Deep Zoom).

WPF Compatibility

Silverlight Beta2 includes a lot of fixes/changes to improve API compatibility between Silverlight and WPF (note: the final Silverlight release will contain some additional compatibility work as well).  We are also adding some new APIs we are introducing in Silverlight 2 to WPF in .NET 3.5 SP1 this summer.

This work, combined with the VSM support we are adding to WPF later this year, will enable good code re-use across browser and desktop applications.

View Entire Article

User Comments

No comments posted yet.

Community Advice: ASP | SQL | XML | Regular Expressions | Windows

©Copyright 1998-2024 ASPAlliance.com  |  Page Processed at 2024-02-27 11:26:14 AM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search