Enable frame rate counters in code

In your App.xaml.cs or MainPage.xaml.cs, in the constructor, set the host property to true for this diagnostic mode:

Application.Current.Host.Settings.EnableFrameRateCounter = true;

Make sure the System Tray is not visible

By default in the beta tools, the MainPage.xaml sets the system tray to be visible. When this happens, the frame rate counters are hidden by the operating system shell.

Method 1: XAML

The default page template includes an XMLNS declaration for “shell”, and has this in the phone application page constructor:

shell:SystemTray.IsVisible="true"

Just change the IsVisible property to False:

shell:SystemTray.IsVisible="false"

Method 2: Code

Microsoft.Phone.Shell.SystemTray.IsVisible = false;

In a future release of the phone tools, this is actually going to be less of an issue, as the counters will actually be right-aligned on the screen instead.

Adding a simple check box to toggle the counters

A lot of app developers add a check box to debug builds that lets them toggle this sort of diagnostic display. In one of our ‘Scenarios’ test applications, we have a check box on the first page, and in XAML it connects the Checked and Unchecked events to this method.:

private void FrameRateCounters_Checked(object sender, RoutedEventArgs e)
{
    var checkbox = (CheckBox)sender;
    var newValue = checkbox.IsChecked.GetValueOrDefault();

    Application.Current.Host.Settings.EnableFrameRateCounter = newValue;
    SystemTray.IsVisible = !newValue; // Hides frame rate counter otherwise
}

Enabling frame rate counters only on debug builds

You can also use conditional compilation to just have your debug builds display this information. Add this to your App.xaml.cs:

#if DEBUG
    Application.Current.Host.Settings.EnableFrameRateCounter = true;
    Microsoft.Phone.Shell.SystemTray.IsVisible = false;
#endif

This assumes you remember to eventually ship your app on the marketplace with a release build .

Accelerated graphics note: If you still don’t see a frame rate counter

The frame rate counter only appears when your system has a supported DirectX 10 graphics card that allows the Windows Phone emulator to use accelerated graphics.

If you set the frame rate counter visibility to True, the system tray is hidden, and you still don’t’ see the counters, then unfortunately your system does not have a supported card for displaying this information.

All Windows Phone devices will show the frame rate counter, so once phone hardware is more widely available, you’ll still have an option to test the performance of your apps.

Exploring the frame rate counter data

This has been covered countless times, but I figure if you’re [using your search engine of choice to find this] here that it doesn’t hurt to duplicate.

The Beta tools display frame counter information on the top of the page.

Shipping frame counter information is displayed on the right of the screen.

So moving through the counters, we have the following.

Render Thread FPS: The number of frames per second that the independent simple animations and rendering thread is using. Keeping around 60 will provide a great experience, while a number of 30 fps will begin to show a poor experience to the end user.

Under 30 fps this counter will turn red in post-beta builds.

User Interface Thread FPS: The number of fps that the primary user interface thread is experiencing. Property change notifications, data binding, primary managed code execution, and animations not handled on the render thread use this threads’ resources.

Turns red when the count is at or below 15 fps.

Texture Memory Usage: A specialized memory counter indicating the video memory used for storing application textures.

Surface Counter: A count of the number of surfaces that are passed to the graphics chip.

Intermediate Texture Count: The number of intermediate textures created for compositing.

Screen Fill Rate: A metric representing the number of complete phone screens being painted each and every frame.

This counter was not present in the Beta tools and is a new metric for post-Beta use.

Target frame rates for good performance

When testing on a Windows Phone device, here are key performance metrics to try for. Understand that the emulator (XDE) performance may not be indicative of actual device performance.

Frame rate counters may be 0 when there is no animation being updated on the thread at any particular moment. You can add a very simple, continually animating and repeating, animation to your application during development & testing if you want to ensure that there is always some frame rate value available.

Future posts will cover tips for improving the frame rate and application performance. Hope this helps.

This brings the new features from the Silverlight 4 version to developers who have a business reason to continue with Silverlight 3 development for the time being:

• Updated user interface
• Integrated “tag expression” support for selecting subsets of tests to run
• Performance improvements
• Removal of dependencies on XLinq and System.Windows.Browser assemblies

These are also the bits you want for Windows Phone testing.

Why wasn’t there one for Silverlight 3 already?

Since the April 2010 toolkit release was targeted for Silverlight 4 developers only, these bits were not released for version 3 (though were built from the same source).

Why doesn’t the April 2010 toolkit work for Windows Phone development & testing?

The Windows Phone development environment is based on a version of Silverlight 3 today, and so that means that you need to use Silverlight 3 binaries and class libraries when re-using Silverlight apps and code – not Silverlight 4.

These bits work well for phone developers and replace the older bits I had posted to my MIX talk site.

Download the binaries

[Silverlight 3 binaries for the Silverlight Unit Test Framework, Zip 452KB]
You may need to ‘unlock’ the binaries for security reasons once downloading and extracting the assemblies from the .Zip. To do this, right-click on the file and select the ‘Unlock’ button.

These binaries are strong named as before, but are not Authenticode signed, so they are not official. This helps work around some Windows Phone signing issues I’ve heard reports of.

Hope this helps,
Jeff

My ChildWindow style

Click on the window above to open a simple Silverlight 4 application that demonstrates the transitions and interactivity. Project download.

Some things to call out:

• I don’t include a Close button in the window chrome.
• I hook up to the OnKeyDown event in my sample implementation. I always try and do this with my ChildWindows so that the escape (ESC) key can be treated as a cancelation of the dialog. Personal preference but a usability win I believe.
• I like a light overlay color instead of a darkening experience, and went for that look.
• My actual implementation uses a value converter to capitalize the title. I’ve removed this from my template for the time being.

The story on my evolving, unnamed theme, and how it relates to “Cosmopolitan”

There’s an excellent “Cosmopolitan” Silverlight project template + theme available that makes building good-looking interfaces a snap, and I’d highly recommend it if you’re looking to modernize the look of a new Silverlight project. I believe it pulls from “codename Metro” design ideas. It just works and as a VS template it rocks!

I’ve built an alternative, but similar theme, over time that I use on many of my projects, and it also pulls from the inspiration of the clean, consistent Zune software design principals.

Now that the “Cosmopolitan” theme is out there, I’ve been taking the time to compare and contrast my similar theme with this, and see where I can make changes. Yeah, the things I do in my free time are baffling…

This is a good exercise because design is a two-way street, comparing and contrasting design decisions and implementations: I’ve learned that I should have been including validation templates in my theme (oops, haven’t used that feature enough). And I’ve shared some minor feedback on parts of the “Cosmopolitan” theme’s implementation details with its designers.

In the future I’ll present the complete theme for many controls, but until that develops, I’m going to continue to share small styles and templates, along with my comments along the way. Previously I blogged my context menu style.

If you’re wondering “why should I use ChildWindow?” – I used to wonder the same thing. But I’m using ChildWindow more now than ever. I’ve discovered the importance of the nice integration with Visual Studio (there’s an item template for child windows), and out-of-browser applications have many uses for a rich modal-style window for sharing information at runtime.

I’ve completely replaced the MessageBox in my out-of-browser applications to instead use a child window designed to replace the message box functionality, offering a consistent visual design even when a message box-like experience is needed. I even use extension methods to add methods to MessageBox to instead use my styled child window.

Other ChildWindow styles

Here’s the standard ChildWindow style and control template that is built into the Silverlight SDK. I’m displaying a password entry form adapted from an app I was experimenting with:

Here is the same window with the “Cosmopolitan” theme’s style applied:

Note: There’s a bug in ChildWindow implicit styling support

While working on creating themes, I did discover that there’s an unfortunate bug in Silverlight 4 where the implicit styles for ChildWindow are not picked up in certain XAML scenarios. Namely, if you use the handy item template in Visual Studio, the implicit style won’t be picked up.

Oddly, at times Visual Studio will show the proper implicit style, but at runtime it will revert to the standard control default style. Here’s a small screenshot – this is out-of-the-box “Cosmopolitan” theme with a ChildWindow item template.

At design time it looks fine:

At runtime:

It appears that this item template format, where the XAML file of the child window’s root is the child window, doesn’t allow the style that was implicitly defined to be picked up.

No worries. To workaround this, add a Style attribute to the root of the file and a static resource to ChildWindow name. If you’re working with “Cosmopolitan”, then here are the steps:

• Open the Assets/SDKStyles.xaml file
• Navigate to the implicit style for ChildWindow around line 2,440
• Add an x:Key to make the style explicit instead of implicit. x:Key=”ChildWindowStyle”
• Add this line after the (now explicit) style:

<Style TargetType="controls:ChildWindow" BasedOn="{StaticResource ChildWindowStyle}" />

• Open your ChildWindow XAML file (mine is called Password.xaml) and add the attribute Style=”{StaticResource ChildWindowStyle}” to the root element

And here’s it at runtime now with our fix/workaround:

Note that whenever defining implicit styles myself, I always start explicit, then provide the implicit in the file using BasedOn.

Download my sample project including the style

[ChildWindowTheme.zip, 71 KB] Includes the theme in App.xaml.

“My yet-to-be-named Zune-inspired theme” components

• ChildWindow (this post)
• ContextMenu

It’s a familiar crowd: many of the brightest from across the company have been joining the ranks, and a lot of the classic Silverlight Toolkit team members are a part of the effort.

The focus of this blog won’t be changing much at all – I continue to be involved in Silverlight Toolkit, the Silverlight Unit Test Framework, and anything else I can get my hands on.

I took a few minutes to experiment with new Silverlight 4 features, including the new Silverlight Toolkit (April 2010 release) that includes a context menu control, to re-style/re-template the menu to look similar to a few other menus.

Here’s a quick look at some common context menu visuals – clearly there is some room for artistry in creating a consistent experience with your app.

The center context menu, with the Windows look, is what the default Silverlight Toolkit context menu looks most similar to.

New features used

• Right-click input event, added to the platform in Silverlight 4
• Context menu control from the Silverlight Toolkit
• Implicit styles support
• Local fonts

Consider checking out ‘Cosmopolitan’, too

There’s a theme that resembles the modern “codename Metro” design style, similar to that of the Zune user interface, that is available for Silverlight 4. More information is available on Tim’s blog.

What a context menu looks like in XAML

You need an xmlns for the input assembly in the Silverlight Toolkit. Then you setup the ContextMenuService, a ContextMenu instance, plus multiple MenuItem and Separator instances.

A MenuItem can optionally have an icon, though I believe the trend these days is moving away from the icon-heavy menu and toolbar world into a clean & crisp text-only experience… so I prefer a styled context menu that doesn’t optimize for icons.

The XMLNS for the context menu assembly is:

xmlns:controlsInputToolkit="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Input.Toolkit"

You can directly wire up to the Click event, or use Commands. Here’s a sample context menu within a data template:

<ListBox.ItemTemplate>
    <DataTemplate>
        <ContentPresenter Content="{Binding}">
            <controlsInputToolkit:ContextMenuService.ContextMenu>
                <controlsInputToolkit:ContextMenu>
                    <controlsInputToolkit:MenuItem Header="Play" Click="OnMenuItemClick"/>

                    <controlsInputToolkit:Separator/>

                    <controlsInputToolkit:MenuItem Header="Download" Click="OnMenuItemClick"/>
                    <controlsInputToolkit:MenuItem Header="Buy" Click="OnMenuItemClick"/>
                    <controlsInputToolkit:MenuItem Header="Add to cart" Click="OnMenuItemClick"/>

                    <controlsInputToolkit:Separator/>

                    <controlsInputToolkit:MenuItem Header="Add to playlist" Click="OnMenuItemClick"/>
                    <controlsInputToolkit:MenuItem Header="Add to burn list" Click="OnMenuItemClick"/>
                    <controlsInputToolkit:MenuItem Header="Add to now playing" Click="OnMenuItemClick"/>
                    <controlsInputToolkit:MenuItem Header="Mark as favorite" Click="OnMenuItemClick"/>

                    <controlsInputToolkit:Separator/>

                    <controlsInputToolkit:MenuItem Header="Send" Click="OnMenuItemClick"/>

                </controlsInputToolkit:ContextMenu>
            </controlsInputToolkit:ContextMenuService.ContextMenu>
        </ContentPresenter>
    </DataTemplate>
</ListBox.ItemTemplate>

And here’s what it looks like:

To use the ContextMenu, make sure your project includes references to both the toolkit’s System.Windows.Controls.Input.Toolkit.dll as well as the SDK’s System.Windows.Controls.dll.

Now I’d like to make this look more Zune-like.

Using implicit styles

So there are multiple ways to have a style (predefined look, settings and template) on your object:

1. Default style key – the default template and style that the creator of the control had in mind. No work required.
2. Implicit styles defined in Resources – in Silverlight 4, a Style defined by a user, but without an x:Key property, will automatically apply to all scoped controls of that type.
3. Static resource styles defined in Resources – the standard experience up until now, having a Style with an x:Key, then setting the Style=”{StaticResource MyKeyName}” on any and all controls that want to use that style.
4. Setting properties directly on an object.

So here is a standard, simple style for a Button, with the key:

<UserControl.Resources>
    <Style TargetType="Button" x:Key="MyButtonStyle">
        <Setter Property="Background" Value="Blue"/>
    </Style>
</UserControl.Resources>

Here’s how you reference it:

<Button Style="{StaticResource MyButtonStyle}" Content="OK"/>

And now let’s make that into an implicit style for Silverlight 4. Just remove the x:Key:

<UserControl.Resources>
    <Style TargetType="Button">
        <Setter Property="Background" Value="Blue"/>
    </Style>
</UserControl.Resources>

And here’s how you reference that style – you don’t – it’s implicit:

<Button Content="OK"/>

Small caveat, fyi: there is a bug with implicit styles not necessarily being applied within data templates. To work around this, I had to move to explicit styles (adding an x:Key to the style, then setting the Style property in the DataTemplate’s XAML to the static resource’s key).

Local fonts

I also used a feature of Silverlight 4 that lets me pick up and use local fonts on the machine. I’m using the ‘Segoe UI’ font, a key part of the Windows 7 user experience and visual identity.

However I also define fallback fonts, just like you would in HTML:

<Setter Property="FontFamily" Value="Segoe UI, Tahoma, Arial"/>

My Zune-like context menu

Here are the templates I ended up creating using Expression Blend.

To achieve the fade-in effect, I faked a little and used a Loaded event trigger, so the first time any particular context menu is shown, it will quickly fade – but subsequent presentations of the same instance will not fade, for a faster, more performant feel.

ContextMenu Style

<Style TargetType="controlsInputToolkit:ContextMenu" x:Key="ZuneLikeContextMenu">
    <Setter Property="Background" Value="#FFFFFFFF"/>
    <Setter Property="BorderThickness" Value="0,1,0,1"/>
    <Setter Property="BorderBrush" Value="#0D000000"/>
    <Setter Property="Padding" Value="0,4,0,4"/>
    <Setter Property="Template">
        <Setter.Value>
            <ControlTemplate TargetType="controlsInputToolkit:ContextMenu">
                <Border
                    x:Name="Menu"
                    Opacity="0"
                    BorderBrush="{TemplateBinding BorderBrush}"
                    BorderThickness="{TemplateBinding BorderThickness}"
                    Background="{TemplateBinding Background}"
                    CornerRadius="0">
                    <Border.Effect>
                        <DropShadowEffect
                            ShadowDepth="0" Opacity="0.6" BlurRadius="22"/>
                    </Border.Effect>
                    <Border.Triggers>
                        <EventTrigger RoutedEvent="Rectangle.Loaded">
                            <BeginStoryboard>
                                <Storyboard>
                                    <DoubleAnimation
                                        Duration="0:0:0.2"
                                        To="1"
                                        Storyboard.TargetProperty="Opacity"
                                        Storyboard.TargetName="Menu"/>
                                </Storyboard>
                            </BeginStoryboard>
                        </EventTrigger>
                    </Border.Triggers>
                    <Grid>
                        <ItemsPresenter Margin="{TemplateBinding Padding}"/>
                    </Grid>
                </Border>
            </ControlTemplate>
        </Setter.Value>
    </Setter>
</Style>

Separator Style

<Style TargetType="controlsInputToolkit:Separator" x:Key="ZuneLikeSeparator">
    <Setter Property="Background" Value="LightGray"/>
    <Setter Property="IsTabStop" Value="False"/>
    <Setter Property="Margin" Value="6,2,6,2"/>
    <Setter Property="Template">
        <Setter.Value>
            <ControlTemplate TargetType="controlsInputToolkit:Separator">
                <Border
                    BorderThickness="{TemplateBinding BorderThickness}"
                    BorderBrush="{TemplateBinding BorderBrush}"
                    Background="{TemplateBinding Background}"
                    Height="1"/>
            </ControlTemplate>
        </Setter.Value>
    </Setter>
</Style>

MenuItem Style

<Style TargetType="controlsInputToolkit:MenuItem" x:Key="ZuneLikeMenuItem">
    <Setter Property="Background" Value="Transparent"/>
    <Setter Property="FontSize" Value="14"/>
    <Setter Property="FontFamily" Value="Segoe UI, Tahoma, Arial"/>
    <Setter Property="BorderBrush" Value="Transparent"/>
    <Setter Property="BorderThickness" Value="0"/>
    <Setter Property="Padding" Value="8,2,10,2"/>
    <Setter Property="Template">
        <Setter.Value>
            <ControlTemplate TargetType="controlsInputToolkit:MenuItem">
                <Grid>
                    <VisualStateManager.VisualStateGroups>
                        <VisualStateGroup x:Name="CommonStates">
                            <VisualState x:Name="Normal"/>
                            <VisualState x:Name="Disabled">
                                <Storyboard>
                                    <DoubleAnimation Duration="0" Storyboard.TargetName="Presenter" Storyboard.TargetProperty="Opacity" To="0.5"/>
                                </Storyboard>
                            </VisualState>
                        </VisualStateGroup>
                        <VisualStateGroup x:Name="FocusStates">
                            <VisualState x:Name="Unfocused"/>
                            <VisualState x:Name="Focused">
                                <Storyboard>
                                    <DoubleAnimation Duration="0" Storyboard.TargetName="Bg" Storyboard.TargetProperty="Opacity" To="1"/>
                                    <DoubleAnimation Duration="0" Storyboard.TargetName="IconPresenter" Storyboard.TargetProperty="Opacity" To="1"/>
                                    <DoubleAnimation Duration="0" Storyboard.TargetName="Presenter" Storyboard.TargetProperty="Opacity" To="1"/>
                                </Storyboard>
                            </VisualState>
                        </VisualStateGroup>
                    </VisualStateManager.VisualStateGroups>
                    <Rectangle
                        RadiusX="0"
                        RadiusY="0"
                        Fill="{TemplateBinding Background}"
                        Stroke="{TemplateBinding BorderBrush}"
                        StrokeThickness="{TemplateBinding BorderThickness}"/>
                    <Rectangle
                        x:Name="Bg"
                        RadiusX="0"
                        RadiusY="0"
                        StrokeThickness="0"
                        Opacity="0"
                        Fill="#11000000"/>
                    <Grid Margin="{TemplateBinding Padding}">
                        <Grid.ColumnDefinitions>
                            <ColumnDefinition
                                Width="Auto"/>
                            <ColumnDefinition Width="2"/>
                            <ColumnDefinition Width="*"/>
                            <ColumnDefinition Width="17"/>
                        </Grid.ColumnDefinitions>
                        <ContentPresenter
                            x:Name="IconPresenter"
                            Content="{TemplateBinding Icon}"
                            Margin="1"
                            Opacity=".7"
                            VerticalAlignment="Center"/>
                        <ContentPresenter
                            x:Name="Presenter"
                            MinWidth="120"
                            Opacity=".7"
                            Content="{TemplateBinding Header}"
                            ContentTemplate="{TemplateBinding HeaderTemplate}"
                            Grid.Column="2"/>
                    </Grid>
                </Grid>
            </ControlTemplate>
        </Setter.Value>
    </Setter>
</Style>

ZuneLikeContextMenuImplicitStyles.xaml.txt: XAML. Download all three in one file. The file contains both implicit styles plus defined style names.

Here’s a comparison, a screenshot of the Zune menu on the left, and my Silverlight 4 context menu on the right:

Hope this helps you create some nice modern-looking Silverlight apps!

The session will be more comprehensive than the overview talk I presented at MIX 10 (which is available as a free online video stream now).

Click here to view the talk information on the Tech Ed site. The tentative information is as follows, but please double-check with the conference schedule builder before showing up:

Unit Testing in Microsoft Silverlight
Wednesday, June 9, 2010
11:45 AM – 1:00 PM
Room 287
Session Code WEB205
http://northamerica.msteched.com/topic/list?keyword=WEB205

Hope to see some friendly faces in the audience! I’ll be up there in some sort of speaker polo shirt uniform with khakis, apparently this conference isn’t quite as trendy and cool as MIX in Vegas .

If you’re going to be attending Tech Ed, I’d appreciate any early comments you have as there is still time to shape the content of the talk.

Rich, modern user interface

The user interface no longer uses the antiquated HTML DOM bridge for displaying results, but now is a data bound, rich Silverlight application itself.

Rich results information is available, and a tree view control allows you to select results to be included in a test report that can be copied to the clipboard. Failures are automatically selected.

The results pane includes information about the tests that ran, as well as detailed information for failures.

Descriptive text helps identify negative tests, known test issues and bugs, and other important metadata that was not always exposed in the previous test framework.

Integrated tag expression support

The startup experience now allows you to enter a tag expression to select which tests to run, or not to run. You can add the Tag(“”) attribute to any test methods or classes to define your own tags. Also, the full and short names of tests and classes implicitly become test tags, as well as priorities.

This means that you can define tags such as:

Out of Browser support

The framework now supports running out-of-browser. Paired with the new Silverlight 4 Tools for Visual Studio 2010, you can press F5 to run a test project you have marked as an out-of-browser.

This also opens up an opportunity to do testing of elevated apps that make use of AutomationFactory and other advanced features on Windows.

Simplified dependencies

The test framework removed dependencies on System.Windows.Browser (from the platform) and System.Xml.Linq (XLinq, from the SDK).

Building blocks for Windows Phone testing support

This version also contains the full source to the phone testing interface, which is significantly different in visual design and experience to coincide with the Windows Phone device size.

However, the story for phone testing is still developing: in the meantime binaries designed for phone use can be found at http://jeffatmix.com/

New location for binaries

Since the new rich user interface contains a number of controls, the traditional design-time integration system conflicts and presents some issues.

As a result, we had to move the binaries from the Bin directory of the toolkit installation folder into a new Testing directory.

So the two test framework assemblies (Microsoft.Silverlight.Testing and Microsoft.VisualStudio.QualityTools.UnitTesting.Silverlight) have moved.

This location change could cause existing applications that reference the test assemblies to fail to compile due to the "missing" references.

If that happens, please delete the two broken references and create references to these assemblies in their new location. Everything else should continue to work as expected.

Simplified test project template

In alignment with the test project changes in Visual Studio 2010, which are more simplified, the unit test project template for Silverlight no longer includes a README.TXT file.

Known issues

Test service

I’ve received reports from a number of people about issues with the test service automation support. Some of the NDA/preview users of the framework reported issues that were corrected, but there may still be some bugs out there. I’m working to investigate and post a fix if and when I know more.

In the meantime I know that StatLight, a third party system, has been updated for the April release and is working well for automation.

Test panel and visuals

Please beware that some of your tests may need to be updated to use the new framework if your application, utility functions, or tests ever used the Application.Current.RootVisual (against the recommended pattern for interface testing).

The root visual is now the test framework application runner itself, and the tests run within the same TestPanel as before. Controls added to the test panel will not be located at the 0, 0 screen position, but likely near the bottom of the screen instead.

Hope this helps. To get started, download and install the April toolkit!

Something I didn’t have to worry about in the typical user interface thread-only implementation of my app was which thread change notifications fire on.

Here’s a typical scenario:

1. You have a CLR property on a data/model object in your app. In a background thread, the property is updated.
2. As all data and model objects should be, the type implements INotifyPropertyChanged (the data binding system relies on this to know when to update bindings).
3. The property changed event is fired, and listeners react to the change, including the data binding system.
4. The data binding system throws an invalid cross thread exception, since all UI operations, including handing off the binding changes, need to happen on the UI thread (but it’s happening on a background thread)

So what you really need to do is funnel those change notifications back to always happen on the user interface thread – that’s what makes the most sense given the data binding requirement.

By using a dispatcher, which can accept a BeginInvoke for that other thread, it will all just work and binding will move along happily:

This scenario is ripe for a few helper classes that I’m open to receiving feedback on. Hope you agree with my approach of using a ‘smart dispatcher’.

One Dispatcher to rule them all

The only thing you need to fire an Action on the primary UI thread is a reference to a Dispatcher instance. Unfortunately this isn’t something you can request from a background thread – you need to have the instance already stored away in most cases.

As a result, I’ve a static helper class and in it, I try and make sure that there is an instance stored before any of my data binding or model code is used.

Though I could have used SynchronizationContext instead, Dispatcher is a little easier to use, and better suited to WPF and Silverlight apps.

In my App.xaml.cs, I add a line that calls Initialize on my class. This is to make sure that there is always an available dispatcher for other threads to get access to:

public App()
{
    this.Startup += this.Application_Startup;
    this.Exit += this.Application_Exit;
    this.UnhandledException += this.Application_UnhandledException;

    SmartDispatcher.Initialize(Deployment.Current.Dispatcher);

    InitializeComponent();
}

If you didn’t want to have to add this code to initialization, my implementation of a dispatcher helper class falls back to trying to grab the dispatcher from the root visual – but this won’t work in all scenarios, so I prefer the above. One more thing to remember however.

Being smart about using the dispatcher

It’s easy enough to replace all event firings for property changes to go through the dispatcher. However, this will reduce performance some; instead of the call being made immediately, it’s made at a later time.

There is a hidden method called CheckAccess on Dispatcher that returns true if you are on the same thread that the Dispatcher was first created in. By checking with it before making a call, we can make a better perf choice:

• If CheckAccess is true and we’re on the UI thread, just go ahead and directly invoke the Action.
• Else, BeginInvoke with the Dispatcher that will take care of getting it done on the UI thread later.

I’ve also done some optimization to try and ensure that the design-time experience at least stays consistent. In general you shouldn’t have background operations ever occurring in a design-time scenario.

The static helper class I’ve created is called SmartDispatcher and simplifies all of this logic.

So here’s my smart dispatcher implementation:

// (c) Copyright Microsoft Corporation.
// This source is subject to the Microsoft Public License (Ms-PL).
// Please see http://go.microsoft.com/fwlink/?LinkID=131993 for details.
// All other rights reserved.

using System.ComponentModel;

namespace System.Windows.Threading
{
    /// <summary>
    /// A smart dispatcher system for routing actions to the user interface
    /// thread.
    /// </summary>
    public static class SmartDispatcher
    {
        /// <summary>
        /// A single Dispatcher instance to marshall actions to the user
        /// interface thread.
        /// </summary>
        private static Dispatcher _instance;

        /// <summary>
        /// Backing field for a value indicating whether this is a design-time
        /// environment.
        /// </summary>
        private static bool? _designer;

        /// <summary>
        /// Requires an instance and attempts to find a Dispatcher if one has
        /// not yet been set.
        /// </summary>
        private static void RequireInstance()
        {
            if (_designer == null)
            {
                _designer = DesignerProperties.IsInDesignTool;
            }

            // Design-time is more of a no-op, won't be able to resolve the
            // dispatcher if it isn't already set in these situations.
            if (_designer == true)
            {
                return;
            }

            // Attempt to use the RootVisual of the plugin to retrieve a
            // dispatcher instance. This call will only succeed if the current
            // thread is the UI thread.
            try
            {
                _instance = Application.Current.RootVisual.Dispatcher;
            }
            catch (Exception e)
            {
                throw new InvalidOperationException("The first time SmartDispatcher is used must be from a user interface thread. Consider having the application call Initialize, with or without an instance.", e);
            }

            if (_instance == null)
            {
                throw new InvalidOperationException("Unable to find a suitable Dispatcher instance.");
            }
        }

        /// <summary>
        /// Initializes the SmartDispatcher system, attempting to use the
        /// RootVisual of the plugin to retrieve a Dispatcher instance.
        /// </summary>
        public static void Initialize()
        {
            if (_instance == null)
            {
                RequireInstance();
            }
        }

        /// <summary>
        /// Initializes the SmartDispatcher system with the dispatcher
        /// instance.
        /// </summary>
        /// <param name="dispatcher">The dispatcher instance.</param>
        public static void Initialize(Dispatcher dispatcher)
        {
            if (dispatcher == null)
            {
                throw new ArgumentNullException("dispatcher");
            }

            _instance = dispatcher;

            if (_designer == null)
            {
                _designer = DesignerProperties.IsInDesignTool;
            }
        }

        /// <summary>
        ///
        /// </summary>
        /// <returns></returns>
        public static bool CheckAccess()
        {
            if (_instance == null)
            {
                RequireInstance();
            }

            return _instance.CheckAccess();
        }

        /// <summary>
        /// Executes the specified delegate asynchronously on the user interface
        /// thread. If the current thread is the user interface thread, the
        /// dispatcher if not used and the operation happens immediately.
        /// </summary>
        /// <param name="a">A delegate to a method that takes no arguments and
        /// does not return a value, which is either pushed onto the Dispatcher
        /// event queue or immediately run, depending on the current thread.</param>
        public static void BeginInvoke(Action a)
        {
            if (_instance == null)
            {
                RequireInstance();
            }

            // If the current thread is the user interface thread, skip the
            // dispatcher and directly invoke the Action.
            if (_instance.CheckAccess() || _designer == true)
            {
                a();
            }
            else
            {
                _instance.BeginInvoke(a);
            }
        }
    }
}

A property change base class

Next up, instead of having to manually wire up the INotifyPropertyChanged interface in all my data classes, I prefer to derive from a common base class, PropertyChangedBase, that has logic in it to use my smart dispatcher.

This base class:

• Has a protected NotifyPropertyChanged method that does all the real work
• Statically stores created event arguments to improve performance over time (only one PropertyChangedEventArgs instance is required per property name in the application’s lifetime)
• Uses SmartDispatcher to use a dispatcher only if not running on the user interface thread, otherwise directly invokes the property change handler.

// (c) Copyright Microsoft Corporation.
// This source is subject to the Microsoft Public License (Ms-PL).
// Please see http://go.microsoft.com/fwlink/?LinkID=131993 for details.
// All other rights reserved.

using System;
using System.Collections.Generic;
using System.Windows.Threading;

namespace System.ComponentModel
{
    /// <summary>
    /// A base class for data objects that implement the property changed
    /// interface, offering data binding and change notifications.
    /// </summary>
    public class PropertyChangedBase : INotifyPropertyChanged
    {
        /// <summary>
        /// A static set of argument instances, one per property name.
        /// </summary>
        private static Dictionary<string, PropertyChangedEventArgs> _argumentInstances = new Dictionary<string, PropertyChangedEventArgs>();

        /// <summary>
        /// The property changed event.
        /// </summary>
        public event PropertyChangedEventHandler PropertyChanged;

        /// <summary>
        /// Notify any listeners that the property value has changed.
        /// </summary>
        /// <param name="propertyName">The property name.</param>
        protected void NotifyPropertyChanged(string propertyName)
        {
            if (string.IsNullOrEmpty(propertyName))
            {
                throw new ArgumentException("PropertyName cannot be empty or null.");
            }

            PropertyChangedEventHandler handler = PropertyChanged;
            if (handler != null)
            {
                PropertyChangedEventArgs args;
                if (!_argumentInstances.TryGetValue(propertyName, out args))
                {
                    args = new PropertyChangedEventArgs(propertyName);
                    _argumentInstances[propertyName] = args;
                }

                // Fire the change event. The smart dispatcher will directly
                // invoke the handler if this change happened on the UI thread,
                // otherwise it is sent to the proper dispatcher.
                SmartDispatcher.BeginInvoke(delegate
                {
                    handler(this, args);
                });
            }
        }
    }
}

Putting it all together

To use this in your own application, you take your model/data classes and derive from PropertyChangedBase. Then, in CLR setters, always call NotifyPropertyChanged:

public class SampleData : PropertyChangedBase
{
    private string _someText;
    public string SomeText
    {
        get { return _someText; }
        set
        {
            _someText = value;
            NotifyPropertyChanged("SomeText");
        }
    }
}

Grab the code

I’ve decided to place these classes inside their appropriate system namespaces: System.Windows.Threading for the smart dispatcher, and System.ComponentModel for the PropertyChangedBase. Hope that isn’t too offensive.

Here are the files for download as well:

• PropertyChangedBase.cs
• SmartDispatcher.cs

Hope this helps. Let me know what you think.

What’s with all the control development tips?

We’re looking at the best way to share a lot of the ‘black magic’ of control development with the community, and will have details on that another way – today so much of this information is hidden away in blog posts like this one.

Hopefully we’ll have a whitepaper at some point.

What are template parts?

Visualizing a control and it’s expected template: “MyControl” has a template part called Button, of type ButtonBase. And although it also may contain a text box, no events from the text box are used. Instead, just a template binding to the Text property.

This control has 1 template part: Button, not two. Don’t be tempted to have a text box template part!

Do you need template parts or not?

It’s important to minimize the number of template parts in a control to reduce complexity. Over-engineering controls leads to reduced code quality, expensive control maintenance, and increased testing cost.

If you can expose dependency properties and template bind into those properties from controls in the template, there is absolutely no reason to have parts present.

If you need to hook up to events of anything in the template, it’s likely that you will need to have a part for that sub control.

Choose wisely.

Use constants for the names

To prevent potential spelling errors or simple mistakes, it’s a good idea to not hard-code the template part name anywhere in your control.

Instead, add a constant string to the top of the file with the part name. You can then refer to it in the OnApplyTemplate method, the template part attribute, and anywhere else it is needed.

The constant can be protected if a subclass may want to reuse the name.

private const string PartButtonName = "Button";

Store parts as private fields in your class

Template parts are not designed to always be inherited by any subclasses. Though the subclasses are welcome to use the same parts, they should not expect to just use the base classes: they need to use OnApplyTemplate to also grab instances of the parts.

So do use private fields to store the parts in the OnApplyTemplate method:

private ButtonBase _button;

Detach any existing event handlers in OnApplyTemplate

Controls can be restyled and retemplated as a result. Make sure to detach any event handlers from previous template parts before adding new handlers.

Here’s the typical pattern for that:

public override void OnApplyTemplate()
{
    base.OnApplyTemplate();
    if (_button != null)
    {
        _button.Click -= OnButtonClick;
    }

    _button = GetTemplateChild(PartButtonName) as ButtonBase;

    if (_button != null)
    {
        _button.Click += OnButtonClick;
    }
}

Don’t assume template parts exist

Whenever using template parts in your code, you should not assume that they exist. Always check for null, and unless a significant reason exists for requiring their presence, never throw an error in this condition.

Often code in the class relating to states and properties will execute long before the template is applied, yielding no template part instances early on.

if (_button != null)
{
   // Do something with the button
}

Mark controls with template part attributes

Design surfaces like Expression Blend expect that controls are marked with the template part attributes. These are required to provide helpful tooling for editing templates.

Make sure to use the constant template part name that you created a few tips ago:

[TemplatePart(Name = PartButtonName, Type = typeof(ButtonBase))]
public partial class MyControl : ContentControl
{
}

Template parts don’t necessarily inherit from their base class

It’s possible to have different template parts at each level of a control’s hierarchy. It’s even possible that subclasses may not want to use a template of a base class.

As a result, never provide template parts as public or protected properties on your controls. If subclasses want them, they can ask for them.

This is another reason it’s important to quietly check template parts for null, they may not be defined in base classes.

You should define template part attributes on every subclasses where expected. They do not inherit.

Hope this helps.

Other tips

David Anson has been furiously writing tips as well as we all have hallway conversations on control development: Check out:

• Read-only dependency properties in Silverlight
• Default values for dependency properties
• Style default values if needed
• Don’t use the constructor to set defaults
• How to define dependency properties
• When using dependency properties, the CLR setters and getters must be super simple

XAML is such an important thing for enabling modern user interfaces that it’s easy to forget how complex and integral the parser is to the Silverlight platform.

It’s the thing that lets us geek out in code when we need to, yet still talk to our designer friends who wear black turtlenecks, dream in Adobe Illustrator actions, and love Expression Blend.

Your designer friends are going to like Silverlight 4 more than Silverlight 3, thanks to new features like direct content.

Developers are going to like Silverlight 4 more, since there are new, better error messages both while using Visual Studio, and at runtime. This means fewer AG_E_UNKNOWN errors.

What’s new?

In Silverlight 4, more than a year of development went into a modern, improved parser to offer new XAML features, fix some common requests and complaints, and develop a modern platform for future parser improvements to build upon.

A number of expert engineers at Microsoft came together to make this possible, and hopefully you’ll find the improvements worthwhile.

In no particular order, and not necessarily exhaustive, here’s a look at some of the changes (more comprehensive information in David Poll’s similar blog post).

Whitespace treatment

XAML in Silverlight 4 is parsed as you’d expect for XML in general: newlines, for instance, don’t show up unless you add the xml:space=’preserve’ attribute first.

<StackPanel Orientation="Horizontal">
    <TextBlock>
       <TextBlock.Text>
          This is the first line of the text block,
          and this is still the first line.
       </TextBlock.Text>
    </TextBlock>
    <TextBlock xml:space="preserve">
       <TextBlock.Text>
          This is the first line of the text block,
          and this is the second line.
       </TextBlock.Text>
    </TextBlock>
</TextBlock>

Upgrade warning: This change is double-edged. When we moved the Silverlight Toolkit samples to use the new parser, we were bit by the source code that displays in the source viewer: it was all one line! The preservation line had to be added, since previously we depended on the parser just grabbing and using the newlines from the parser input for breaks in the text boxes.

Direct content

Buttons work better now. You couldn’t do this before:

<Button>Ok</Button>

Error messages

Many, many bugs around error message handling have been fixed thanks to the new parser’s error service implementation. In most situations, errors are more descriptive, similar to their WPF counterparts, and will contain useful line and column number information.

In Silverlight 3, many times XAML parsing problems resulted in errors being identified as being at line 0, column 0, and those days are mostly over.

Dictionaries done right

If a type or property implements IDictionary, you can now use x:Key to add entries into dictionaries. Note that we’re talking about the non-generic IDictionary interface.

ISupportInitialize

A feature WPF developers have enjoyed, begin and end initialization calls are made before and after properties are defined in XAML.

Template bindings require CLR getters and setters

Dependency properties must have defined CLR getters and settings to be used in template bindings, consistent with WPF.

XmlnsDefinitionAttribute

Especially when using the Silverlight Toolkit and other control libraries, you needed to define a new XMLNS definition in every page, for every assembly you wanted to use.

xmlns:controlsToolkit=”…”, xmlns:navigation=”…”, etc.

Now with XmlnsDefinitionAttribute (an assembly-level attribute) support, you often can get by with less. All the assemblies in a single product can share a namespace which you can then just define one time.

x:Uid support

Uids are better supported, paving the way for localization tools and other uses of x:Uid.

Root default namespace restriction removed

Prior to Silverlight 4, the root XAML namespace had to be one of the supported standard namespaces. This restriction is removed. Note that you still need it if you want to reference set properties that come from the core Silverlight elements.

What about backward compatibility?

Compatibility with previous versions of Silverlight is one of the most important goals for the development and test teams working on Silverlight. As a result, there are a fair number of “quirks mode” checks throughout the codebase.

Whenever a bug fix or new feature is implemented, a quirks mode check often needs to be inserted to maintain the previous codepaths for compatibility reasons.

It’s a good technical challenge, and though “quirking” probably has a bad reputation from the Internet Explorer 5 & 6 days, it really does work well in Silverlight.

Dual parser implementations

Beyond just quirks mode checks in the Silverlight runtime, we have decided to also include the Silverlight 3 parser inside of Silverlight 4 for compatibility reasons.

At the start of the code path that parses XAML and eventually returns an object or tree, there’s an if/else check that keeps the parser versions completely separate:

    if (CQuirksMode::ShouldUseSL3Parser(pCore))
    {
        // ... Old parser code path
    }
    else
    {
        // ... New, awesome parser code path
    }

And the underlying quirks mode check whether the application’s major version is less than 4.

Which parser will be used?

The target application’s Silverlight runtime version is what determines which parser will be used at runtime. This value gets placed inside of the application manifest XAML file, in the application’s .Xap, at build time.

If you examine a .Xap file (rename to .Zip, extract the contents), inside the root directory you will find a file named AppManifest.xaml.

In the Deployment element there is an attribute called RuntimeVersion. This needs to start with 4.0 to use the new parser, such as:

<Deployment
    xmlns="http://schemas.microsoft.com/client/2007/deployment"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    EntryPointAssembly="SilverBugger"
    EntryPointType="JeffWilcox.SilverBugger.App"
    RuntimeVersion="4.0.50303.0" />

Note that I’ve removed the rest of the file contents for brevity.

This means that control and component developers need to be aware of this for new controls: if you have a control whose default styles and templates expect the Silverlight 4 XAML parser to be used (if you’re using direct Button content, for example), then you need to make sure your customers only use those components with Silverlight 4 applications.

What about System.Xaml?

System.Xaml shipped with WPF 4, and is a modern managed XAML parser implementation. We had signifcant knowledge and code sharing on the team to make sure that the implementations were similar, common, and yet they are different.

The parser in Silverlight is a complex implementation because it often has to bridge the native/managed code gap: so much of the core Silverlight runtime is implemented in native code, so properties and other information need to be shared between the two.

Though this is not a technical discussion of the implementation, I will note that there is a crisp interface shared by both a XamlNativeRuntime and XamlManagedRuntime, and it’s pretty impressive.

Let me know how your experiences are with the new Silverlight 4 parser.

Peppermint-Demo.zip [Zip, 1.2 MB]

Silverlight:

Requires Visual Studio 2010 (or express)
Requires the Silverlight Toolkit
Requires the test framework binaries included in the zip

Windows Phone:

Requires the Windows Phone development tools CTP
Requires the test framework binaries included in the zip

These barcode-displaying apps let you get rid of the plastic in your wallet and use your phone instead. Many airports and carriers have been using these barcodes for paperless boarding passes, too.

The barcode within the Windows Phone app on the left is QR encoded and stores the text ‘Hello World’

So, background: when I did this first implementation in September of ‘09, I wanted to see how quickly I could adapt existing .NET libraries for the desktop to work with Silverlight. I was really happy to find that it was simple, taking an existing .NET library for generating 2D QR barcodes and doing some WriteableBitmap work.

This really demonstrates how awesome the app platform for the Windows Phone can be – building on top of not only existing Silverlight knowledge, code, and libraries – but also full-fledged .NET libraries.

Here’s the app, and you’ll even see on the design surface that the barcode is showing up in real-time:

I expose the barcode through a simple control. Here’s the XAML that binds the barcode’s encoded text to the text box’s text – yes, you can type on the phone in real-time and watch the barcode update:

<barcode:QuickReadBarcode
    Width="100"
    Background="White"
    Text="{Binding Path=Text, ElementName=dataText}" />

Download the source to this Windows Phone app

JeffWilcox.WindowsPhone.Barcode.zip [Zip, 1.12 MB]

Requires the Windows Phone development tools CTP (info)

Hope this helps.

The canonical example of user settings is a “Show this welcome screen at startup” checkbox so that your application can offer a nice out-of-box experience.

By writing a simple type with some properties, adding a few helper files, and setting up a two-way data binding, you can store any settings without having to write special code.

Here’s what the completed project’s two-way data binding looks like for the checkbox shown to the right:

<CheckBox
   IsChecked="{Binding Source={StaticResource MySettings}, Path=IsFirstRun, Mode=TwoWay}"
   Content="Show this page at startup"
/>

You’ll see these components in the data binding:

• Source is a static resource, a strongly typed settings class you define
• Path points to the property name to bind to
• Binding is two-way so that the value is stored automatically
• Value and type converters can be applied as always in bindings if necessary

Let’s quickly implement this functionality in a quick app. We’ll also add a text box to the main application page, to let the value always be persisted between application runs, and even application updates.

Getting started

You can use the free Windows Phone development tools, or just Visual Studio 2010 if you have the phone tools CTP installed already.

Create a new ‘Silverlight for Windows Phone’ application project.

Adding some helper code

Either add the class library project I have for download here, or just add the 4 C# files that make up the helper code:

• SettingsHelperCode.zip (8 KB, zip)

Creating your configuration/settings type

Next, we need to create a strongly typed configuration class that derives from my SettingsProvider type. This class must:

• Implement INotifyPropertyChanged, so that bindings work well
• Have properties of the appropriate type for the settings you are interested in. Optionally, include the DefaultValue attribute to provide defaults.

Here is the MySettings.cs file I’ve created for this app. It defines two properties that I always want to have stored:

• HelloWorld is just some text I let the user edit in the user interface. A more realistic setting might be “best friend” or a list of people to show on the home screen of the app.
• IsFirstRun is a true/false value that indicates whether the welcome screen should be shown.

// (c) Copyright Microsoft Corporation.
// This source is subject to the Microsoft Public License (Ms-PL).
// Please see http://go.microsoft.com/fwlink/?LinkID=131993 for details.
// All other rights reserved.

using System.ComponentModel;
using JeffWilcox.Settings;

namespace Sample
{
    /// <summary>
    /// My settings class for storing application data and setting specific to
    /// the user.
    /// </summary>
    public class MySettings : SettingsProvider
    {
        private bool _isFirstRun;
        private string _hello;

        public MySettings() : base("MySettings.xml") { }

        [DefaultValue("What's up?")]
        public string HelloWorld
        {
            get { return _hello; }
            set
            {
                _hello = value;
                NotifyPropertyChanged("HelloWorld");
            }
        }

        [DefaultValue(true)]
        public bool IsFirstRun
        {
            get { return _isFirstRun; }
            set
            {
                bool old = _isFirstRun;
                _isFirstRun = value;
                if (value != old)
                {
                    NotifyPropertyChanged("IsFirstRun");
                }
            }
        }
    }
}

Looking closer, inside the MySettings file:

• MySettings type derives from SettingsProvider, part of the helper code downloaded above.
• The constructor calls the base class’s constructor with the name of a settings file to use within the isolated storage area for the phone application
• Properties have backing fields and fire change notifications
• Default values

Add the settings object to your App.xaml

Now, open up App.xaml. Add an XMLNS prefix declaration for your project. I named my app project “Sample”, so it’s short:

xmlns:local="clr-namespace:Sample"

And then add your settings object to the resources (I’m omitting all the theme resources in App.xaml to make it clear where this goes only).

AlwaysSaveOnChange needs to be set to true for Windows Phone applications: if you’re building a regular Silverlight app, the Application.Exit event works well and can be used to store. But on the phone, since an app may be in a paused or unknown state, this property tells my helper code to save the settings whenever a binding has a change notification. For performance impact should be minimal.

<Application.Resources>
        <!-- Settings -->
        <local:MySettings x:Key="MySettings" AlwaysSaveOnChange="True" />
</Application.Resources>

A simple TextBox binding

Now on my MainPage.xaml, I am just going to bind to the Hello World property from the MySettings type. Any time you type characters into the text box, they will be saved, and always there when you run the app. No need to write code to save or read settings.

<TextBox
    Text="{Binding Source={StaticResource MySettings}, Path=HelloWorld, Mode=TwoWay}" />

Good to go

To pull it in, I’m going to add a page called FirstRun.xaml to the project. This will be the content that I want first-time users to see. Then, I need to add the code to call this from main page at startup:

I define a loaded event for this that checks whether the current instance has run the page yet (hacky, and not a permanent setting), and then checks whether the user wants to see the screen (which defaults to true in my settings file):

if (!((App)App.Current).HasFirstRunCheckHappenedYet)
{
    ((App)App.Current).HasFirstRunCheckHappenedYet = true;

    MySettings settings = (MySettings)App.Current.Resources["MySettings"];
    if (settings != null && settings.IsFirstRun)
    {
        NavigationService.Navigate(new Uri("/FirstRun.xaml", UriKind.Relative));
    }
}

It then uses the navigation service to navigate, if needed.

If you’d like to learn more about Silverlight data binding, do check out this MSDN resource: http://msdn.microsoft.com/en-us/library/cc278072(VS.95).aspx

Some people have experimented with directly binding to the isolated storage settings file, but this approach gives your some separation – by having your own class, you can provide default values, even upgrade logic, and do some neat work.

This is based on a classic WPF post by Patrick Danino which used the full .NET configuration classes. Enjoy!

Although we had previously talked about a March 2010 release to coincide with the Silverlight 4 RC at MIX, we have decided not to ship an interim release for the RC, since the final release of Silverlight 4 is coming next month.

This is a good thing for developers, the time we save by not releasing goes toward a better release overall when Silverlight 4 is final.

In the meantime, the release of the toolkit in November, for Silverlight 3, still works great on Silverlight 4 RC.

I wanted to provide my own informal look at how it’s working with Silverlight for Windows Phone today.

Note that this information is only current as of today, 3/21, when used with the MIX-related CTP of the tools and emulator, and the November 2009 Silverlight Toolkit. A lot could change, and this is not exhaustive.

I’m also including some controls that are found in the Silverlight SDK today. I present these in order of how much I have used the components while building apps.

WrapPanel and DockPanel

Found in the Silverlight Toolkit, System.Windows.Controls.Toolkit.dll (SWC.Toolkit).

Work great.

If you just need the WrapPanel, and don’t want to include the entire toolkit assembly, you can just paste these source files into your application project instead (license: Ms-PL):

• OrientedSize.cs
• WrapPanel.cs

Charting and Data Visualization

There is a known issue with LINQ that prevents the controls today from working perfectly. A small, targeted fix has been made in the charting codebase and a future release will work well on the device.

Re-templating and styling the control is very important, and required, for working on the phone in an acceptable manner. I hope to share any decent templates I can come up with.

HeaderedItemsControl, HeaderedContentControl

Work great. Split between System.Windows.Controls (SWC) and SWC.Toolkit.

TreeView

SWC. Functional; requires massive re-templating and styling. Font sizes are much too small, and the theme and visuals do not appear code-name “Metro” compatible.

AutoCompleteBox

Found in the System.Windows.Controls.Input SDK library of the Silverlight 3 SDK.

Works OK, not ready for general development use.

Drop-down appears well. Major features all work. However, touching an entry in the drop down only performs selection. A second touch is required to verify the choice, effectively requiring a double-tap in use.

Calendar, DatePicker

SWC. Limited functionality, too small visually. Not designed for touch – not enough space to reliably click on a date. Require massive re-templating. Do not resemble the same experience as the date picker built into the Windows Phone operating system.

GridSplitter

Works, but may pose difficult to use on a device: requires much larger padding and custom templates to make the touch area visible and useful.

Not yet checked

DataGrid, DataPager, ChildWindow, Label, NumericUpDown, DomainUpDown, DataForm, Rating, TimePicker, TimeUpDown, GlobalCalendar, TransitioningContentControl, TreeMap, BusyIndicator, Viewbox, Expander, Accordion, drag and drop features, and many more.

We’re also still developing a story for the toolkit’s phone story moving forward. As there is a lot of momentum around the phone in the company, it’s very likely that some set of phone tools, samples, and toolkits come out.

Hope this helps.