The blog of dlaa.me

A customer contacted me a few days ago asking how to display text labels on a NumericAxis. (Whereas CategoryAxis makes it easy to use text labels for the independent axis, this request was about text labels on the dependent axis.) It's a bit of an unusual request (I spent a minute just now and don't see how to accomplish this in Excel), but I knew it would be easy to do with the Charting controls in the Data Visualization assembly that's part of the Silverlight Toolkit and WPF Toolkit.

The underlying scenario is to provide labels for the results of one of those "How are we doing?" surveys restaurants and hotels like to give out. The chart should look like this:

Though I originally suggested a different approach, the act of coding it up myself suggested a trusty old IValueConverter would be most appropriate. (Aside: See more IValueConverter tricks here and here.) The basic approach is to explicitly specify the dependent axis and then use it to configure exactly the set of tick marks we want. Once that's done, a simple bit of IValueConverter magic converts the numeric values into their corresponding text labels - and the problem is solved! :)

 

I've added the sample shown here to my DataVisualizationDemos application which is collection of all the Data Visualization samples I've blogged. Like the core Data Visualization code itself, the demo app compiles for and runs on multiple platforms with the same code and XAML - it's an easy way to publish a sample and show it running on Silverlight 3, Silverlight 4, WPF 3.5, and WPF 4. Just for kicks, I've used the "Compatible" ColumnSeries for this example - but it works just as well with traditional ColumnSeries. Better yet, the basic idea can be generalized to solve a variety of similar problems as well!

 

[Click here to download the complete source code for the cross-platform DataVisualizationDemos sample application. ]

 

Here's the relevant XAML:

<!-- Chart of customer feedback -->
<charting:Chart Title="Customer Feedback">
    <compatible:ColumnSeries
        ItemsSource="{Binding}"
        IndependentValuePath="Topic"
        DependentValuePath="Rating">

        <!-- Custom Y axis for text labels -->
        <compatible:ColumnSeries.DependentRangeAxis>
            <charting:LinearAxis
                Orientation="Y"
                Minimum="0"
                Maximum="4"
                Interval="1"
                ShowGridLines="True">

                <!-- Custom style/template for text labels -->
                <charting:LinearAxis.AxisLabelStyle>
                    <Style TargetType="charting:AxisLabel">
                        <Setter Property="Template">
                            <Setter.Value>
                                <ControlTemplate TargetType="charting:AxisLabel">
                                    <TextBlock Text="{Binding Converter={StaticResource RatingToStringConverter}}"/>
                                </ControlTemplate>
                            </Setter.Value>
                        </Setter>
                    </Style>
                </charting:LinearAxis.AxisLabelStyle>
            </charting:LinearAxis>
        </compatible:ColumnSeries.DependentRangeAxis>

        <!-- Custom style for different background -->
        <compatible:ColumnSeries.DataPointStyle>
            <Style TargetType="charting:DataPoint">
                <Setter Property="Background" Value="#ff00a0e0"/>
            </Style>
        </compatible:ColumnSeries.DataPointStyle>
    </compatible:ColumnSeries>
</charting:Chart>

And code:

/// <summary>
/// Implements IValueConverter to convert from double rating values to friendly string names.
/// </summary>
public class RatingToStringConverter : IValueConverter
{
    public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
    {
        // Validate parameters
        if (!(value is double))
        {
            throw new NotSupportedException("Unsupported value type in RatingToStringConverter.");
        }
        // Convert number to string
        double doubleValue = Math.Floor((double)value);
        if (0.0 == doubleValue)
        {
            return "Awful";
        }
        else if (1.0 == doubleValue)
        {
            return "Poor";
        }
        else if (2.0 == doubleValue)
        {
            return "Fair";
        }
        else if (3.0 == doubleValue)
        {
            return "Good";
        }
        else if (4.0 == doubleValue)
        {
            return "Great";
        }
        else
        {
            throw new ArgumentException("Unsupported value in RatingToStringConverter.");
        }
    }

    public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
    {
        throw new NotImplementedException();
    }
}

As computing devices have become more powerful, the trend has been toward more "fluid" user interfaces - interaction models that flow smoothly from one state to another. This differs from earlier approaches where resources were more limited and interactions tended to be Spartan and isolated from each another. Some of the motivation behind an increased focus on fluid UI is almost certainly the "wow" factor; modern interfaces can be quite attractive and fun to use! But there's also scientific research to back this up: people tend to find smooth transitions less disruptive to their workflow than abrupt ones - and the animation itself can help tie the "before" and "after" states together by showing how one becomes the other.

With that in mind, one of the things I've wanted to do is apply this principle to enhance the user experience for Silverlight applications on the Windows Phone platform. Specifically, I wanted to make it easy for developers to animate the orientation change of an application that occurs when the phone is rotated from its default portrait orientation to landscape. This is one of those cases where a picture is worth a thousand words, so I've created a short video showing the default behavior of a Silverlight-based Windows Phone application when the device (in this case the emulator) is rotated.

 

Click the image below to view a brief H.264-encoded MP4 video of the default rotation behavior:

For people who have never used the emulator: those two buttons I click rotate the device one quarter turn clockwise or counter-clockwise. I begin by rotating counter-clockwise once, then clockwise once back to the starting orientation, then clockwise three more times to loop all the way around.

 

What I show above is what you get for free when you create a new application - and it's great the device and platform support dynamic orientation changes without any special effort! But I thought it would be cool if I could extend that just a bit in order to animate those orientation changes - again, without requiring the developer to change anything (beyond a couple of superficial name changes).

Click the image below to view a short video of the animated behavior I've created:

As in the first video, I show the device rotating to landscape, then back, then all the way around. But this time I've included a little bit of fun at the end. :)

 

The custom rotation behavior is made possible by the AnimateOrientationChangesPage class I created which works by lying to the layout system (Now, where have I heard that before?). It's a small, self-contained class you insert into the default hierarchy and then never need to worry about again. AnimateOrientationChangesPage automatically gets involved with the necessary steps for rotation and even handles page-to-page navigation changes seamlessly.

My goal was to make it easy for Windows Phone applications to offer the kind of fluid rotation experience that's becoming common these days - and it seems like AnimateOrientationChangesPage does that. I hope you find it useful!

 

[Click here to download the AnimateOrientationChanges sample for the Windows Phone 7 platform.]

 

Notes:

• If you download the sample, please be sure to open MainPage.xaml in the development environment before hitting F5 to run it - otherwise deployment to the emulator might fail with the message "Object reference not set to an instance of an object." because of a bug in the tools.
• I created this sample using the public Windows Phone Developer Tools CTP - April Refresh bits, so anyone else with that toolset installed should be able to run it as-is. I also happened to have a chance to try things out on a more recent (internal) build of the tools - fortunately, things worked just as well there! However, due to a minor change to one of the platform APIs, please remove the following from the top of AnimateOrientationChangesPage.cs if you're trying to run on a more recent build:

  // Remove this #define when using more recent phone/tools builds
  #define APRIL_TOOLS

• Unfortunately, I don't have actual phone hardware to run this code on, so I can't be sure it runs as smoothly there. While the performance under the Windows Phone emulator is great on my laptop, even a laptop has beefier hardware than something pocket-sized like a phone. That said, the implementation is relatively straightforward: the orientation change notification starts a Storyboard with a single DoubleAnimation of a custom DependencyProperty. The change handler for this property updates the values of a RotateTransform and TranslateTransform and triggers an arrange pass (via InvalidateArrange). Everything so far is part of the Silverlight Performance team's recommendations for good performance, so the bottleneck (if there is one) might turn out to be the arrange pass (note: not measure; just arrange) which is always a recursive operation. However, arrange is a fundamental operation for the Silverlight platform, so I expect it to be optimized and pretty efficient in practice. That said, if I manage to get my hands on a device for long enough to play around, I'll see how things really perform...
• I wanted AnimateOrientationChangesPage to be as easy to use as possible. And while I couldn't go as far as enabling it with an attached property, I was able to do the next best thing: derive from PhoneApplicationPage. This means any existing Windows Phone application can be converted to use AnimateOrientationChangesPage simply by changing the base class of its pages to AnimateOrientationChangesPage. Specifically, here are the complete steps for converting the MainPage class of a newly created application:
  1. Verify the page supports multiple orientations by checking for the following code in the constructor (it's added by default, so it ought to be there):

     SupportedOrientations = SupportedPageOrientation.Portrait | SupportedPageOrientation.Landscape;

  2. Add the AnimateOrientationChangesPage.cs code file to the project/solution.
  3. Change the base class of MainPage to AnimateOrientationChangesPage in MainPage.cs:

     using System;
     // ...
     using Delay;
     
     namespace WindowsPhoneApplication1
     {
         public partial class MainPage : AnimateOrientationChangesPage
         {
             // ...
         }
     }

  4. Make the corresponding change to MainPage.cs.xaml:

     <delay:AnimateOrientationChangesPage
         x:Class="WindowsPhoneApplication1.MainPage"
         xmlns:delay="clr-namespace:Delay"
         ...>
     
         <!-- ... -->
     
     </delay:AnimateOrientationChangesPage>

  5. Run the application and enjoy the animations!
• These directions enable the default animation behavior which I've configured to use a 0.4 second duration and a reasonable easing function. However, if you'd like to customize things further, you can set the Duration property to a different TimeSpan and/or change the EasingFunction to the IEasingFunction implementation of your choice. Just in case, there's also an IsAnimationEnabled property that can be set to false to disable orientation change animations entirely. These properties can be set at any time; the new values take effect at the next orientation change.
• I reserve the right to change my mind and move some of this code up into a PhoneApplicationFrame subclass if it turns out that would be helpful. :) But for right now, the current implementation seems pretty effective - I've specifically tested it with navigation scenarios and it works well there, too.
• If you watch the video of the default behavior closely, you'll see a brief period of time right after the rotation occurs where the emulator is rotated but the screen isn't. I think this is an artifact of how the emulator works and doesn't represent something users would see on a real device. As it happens, I don't see that same glitch in the video with AnimateOrientationChangesPage enabled - but I'd apply the same caveat there, too.
• I've deliberately not supported the PageOrientation.PortraitDown enumeration value. This is not because it would be hard to do (it's quite trivial, actually), but rather because no device I've seen (including the Windows Phone Emulator) actually supports flipping completely upside down in portrait orientation. If this design decision is a problem for your scenario, full PortraitDown support requires only three trivial case statements to implement that will be obvious from looking at the code.

I've described the "app building" process before in this post about my HeadTraxExtreme sample for the Silverlight 3 Beta and a later in this update of HeadTraxExtreme for the Silverlight 3 RTW. The gist is that:

... everyone comes up with an idea for a medium-sized application they think could be built with the bits at hand - then goes off and tries to build as much of that application as they can before time runs out. The emphasis is on testing new scenarios, coming up with creative ways of integrating components, and basically just getting the same kind of experience with the framework that customers have every day. Coming up with a beautifully architected solution is nice if it happens, but not specifically a goal. Rather, the point is to help people take a holistic look at how everything works together...

App building is a great way to get exposure to parts of the product you don't normally deal with and can help give team members a more complete view of the platform they work on. I had another app building opportunity recently and my goal was to create a utility application I've been wanting for a while.

Here's where I got in the bit of time I had:

 

Disclaimer: In case it's not completely obvious, none of the file names above is accurate. :)

 

The Sales Pitch

Did you ever want an easy way to transfer files between two machines on semi-isolated networks (ex: home and work)? Looking for an easier way to publish content to the web? Tired of sending yourself files as email attachments all the time? Sneaker-net got you down? Well, your dreams have just come true!

BlobStore is the hot new craze that's taking the world by storm. It's a small, lightweight Silverlight 4 application that acts as a basic front-end for the Windows Azure Simple Data Storage and the Amazon Simple Storage Service (S3)! Just run the BlobStore app, point it at a properly provisioned Azure or S3 account (see below for details on provisioning), and all of a sudden sharing files with yourself and others becomes as simple as dragging and dropping them! BlobStore makes it easy to manage your files by providing a feature-rich (okay, that's an exaggeration) interface that allows you to view, download, or delete files and copy their URL to the clipboard easy-peasy. Logon credentials are stored on your machine so there's no need to remember long account passwords - once you've connected once, future connections are simple and painless.

But wait, there's more!

If you download right now, you'll also get the complete source code from which you can explore all the inner workings of this life-changing application. Included with every code download is a free REST wrapper for basic Azure and S3 blob access that handles all the tricky Authorization header details for you. It's almost guaranteed to make your next Azure/S3 application a snap to develop and a wild success in the marketplace.

So now how much would you pay? :)

 

 

Featured Silverlight 4 Features

• Asynchronous networking
  • Windows Azure REST API
  • Amazon S3 REST API
  • Authorization HTTP header
  • Custom HTTP verbs
  • Client HTTP stack
  • Real-time progress indication
• View/view model separation
  • INotifyPropertyChanged interface
  • ICommand interface
  • Simple DelegateCommand implementation
  • Extensive data binding
• Design-time experience
  • Design-time data
  • Design tool-friendly experience
• Isolated Storage
  • For user preferences
  • For files
• Controls
  • Custom DependencyPropertys
  • Visual State Manager
  • Custom control Templates
  • Custom UserControls
• Clipboard access
• Right click support
• Custom unhandled exception handler

Potential Enhancements (TODOs)

• Smooth various rough edges
• Support running out-of-browser
• Ability to automatically provision new Azure/S3 accounts
• Better handling of web service failures
• Encrypt logon information in isolated storage
• Additional metadata for each blob (file size, MD5 hash, etc.)
• Support Silverlight-based file downloads (i.e., SaveFileDialog)
• Support marking blobs private (i.e., not world-readable)

Potential v.Next Enhancements (features not supported by Silverlight 4)

• Set/get clipboard access for data (ex: images, files)
• Support for downloading by dragging files out of the plug-in

Notes

• In addition to supporting Azure and S3, BlobStore allows you to use Silverlight's isolated storage for the blob service. This works fine for playing around and general experimentation, but it's important to note that the web browser isn't able to download from isolated storage, so files "uploaded" to isolated storage can't be "downloaded" with the browser.
• Access to an isolated storage "account" requires a non-empty account name and key - any name and key will work.
• Isolated storage support is present only for testing purposes (and so people without a provisioned account can play around); I haven't verified that BlobStore works well if access to isolated storage has been disabled or runs out of space.
• Developer documentation for the two online services can be found at the following locations: Windows Azure, Amazon S3
• Despite my Silverlight Toolkit pedigree, BlobStore uses no Toolkit or SDK controls - it's 100% core framework-y goodness!

 

[Click here to run the BlobStore application in your browser.]

[Click here to download the complete source code for the Silverlight 4 BlobStore sample.]

 

 

Provisioning

Before BlobStore can access an Azure/S3 account, that account needs to be provisioned to allow access by a Silverlight browser-based application and permit unauthenticated third parties to download content. Steve Marx has a great overview of provisioning an Azure account - the basic steps are to create the special $root container, make it world-readable, and upload a clientaccesspolicy.xml file that lets Silverlight know the cross-domain access is okay. For an S3 account, the concept is the same, but the implementation is a bit simpler - just upload a clientaccesspolicy.xml file and make it world-readable.

These one-time provisioning steps can be done manually, in code, or with one of the public tools for Azure or S3. The clientaccesspolicy.xml file I use is taken from Steve's example with a tweak to make support for http and https more explicit:

<?xml version="1.0" encoding="utf-8"?>
<access-policy>
  <cross-domain-access>
    <policy>
      <allow-from http-methods="*" http-request-headers="*">
        <domain uri="http://*" />
        <domain uri="https://*" />
      </allow-from>
      <grant-to>
        <resource path="/" include-subpaths="true" />
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>

 

Summary

BlobStore was a fun project to work on and it gave me some nice exposure to Silverlight's networking stack (which I don't normally get a chance to use). There are some rough edges I didn't get around to smoothing over, but on the whole I think BlobStore turned out pretty well: it's small and quick to download, easy to use, it simplifies something I do every day, and it was a great learning experience!

Aside: You can even use BlobStore to publish Silverlight applications (just upload the XAP and HTML file), so it's got that recursive thing going for it, too...

I'd never claim BlobStore is the best example of application design, but I did try to follow "best practices" in most cases; there are some interesting techniques in there that some of you may not have seen in action. And if writing and sharing BlobStore helps others learn how to develop better Silverlight applications, we all win. :)

 

Enjoy!

I was contacted by Simon Weaver via Twitter about a problem where the Bindings for MenuItems of a ContextMenu on a DataGrid were acting as though they were associated with a different row than they really were. This seemed pretty weird until Yifung Lin, one of the original DataGrid developers, suggested this might be due to the row recycling behavior DataGrid uses to improve performance. It turns out he was right - but the rabbit hole goes much deeper than that...

Working from an internal reproduction of the problem Brian Braeckel created, I found that I was able to simplify the scenario significantly - to the point of removing ContextMenu and DataGrid entirely! Signs were pointing strongly to this being a bug in the Silverlight framework, but before I started crying wolf, I wanted someone to review my work to be sure I hadn't over-simplified things. Fortunately, RJ Boeke was around and not only confirmed the validity of my repro, but also pointed out further simplifications!

 

When all is said and done, the bug is pretty easy to describe:

If a Binding points to an element via its ElementName or Source parameters and the DataContext of a parent of that element changes, that change will NOT be propagated through the Binding. However, if the DataContext of the element itself changes, the change will be propagated correctly.

RJ and I were both kind of surprised to find this bug in Silverlight 4, but when Sage LaTorra looked into this from the QA side, he reported the same problem with Silverlight 3. Which - in a weird kind of way - is actually good news because it means things haven't gotten worse with Silverlight 4 and existing applications won't break unexpectedly!

Unfortunately, the DataGrid+ContextMenu scenario relies on this exact behavior to work correctly... When a ContextMenu is about to be displayed, a Popup is created, the menu UI is added to it, and it's shown. Because the Popup isn't in the visual tree, the ContextMenu won't see the right DataContext by default - so it sets up a Binding with its Source set to the ContextMenu's owner element. This works well and the DataContext then "flows" into the Popup where MenuItems can see it and bind to it successfully. The problem in the DataGrid scenario arises when DataGrid decides to recycle one of its rows by swapping one DataContext for another. Though this is a perfectly legitimate thing to do, it runs afoul of this bug and breaks the scenario.

 

Fortunately, there's an easy workaround. Even better: it works for all known instances of the problem, not just the DataGrid+ContextMenu kind! Here's an example of code that demonstrates the bug when the DataContext of a parent element is changed (which you can do in the sample application by clicking on the red or green background):

<!-- Simple example of the broken scenario -->
<Grid x:Name="SimpleBroken" Grid.Column="0" Grid.RowSpan="2" Background="Red">
    <TextBlock Text="{Binding DataContext, ElementName=SimpleBroken}"/>
</Grid>

And here's what it looks like with the workaround applied:

<!-- Simple example of the workaround -->
<delay:DataContextPropagationGrid x:Name="SimpleWorking" Grid.Column="1" Grid.RowSpan="2" Background="Green">
    <TextBlock Text="{Binding DataContext, ElementName=SimpleWorking}"/>
</delay:DataContextPropagationGrid>

Pretty similar, huh? The way this works is that the DataContextPropagationGrid class derives from Grid, listens for DataContext changes in the usual manner, then uses the fact that changes to the local value of DataContext work to "re-broadcast" the change to any Bindings targeting it via ElementName or Source. The important thing to note is that any Binding broken because of the underlying platform bug needs to be pointed at the DataContextPropagationGrid wrapper instead - and should then behave correctly.

Aside: I haven't historically considered Grid for workaround scenarios like this. However, it seems like a good fit: Grid can be wrapped around nearly anything without side-effects, it allows multiple children for scenarios where that might be necessary, it's familiar to developers and designers, and it keeps the workaround code simple!

 

Just to "close the loop", here's an example of a DataGrid+ContextMenu demonstrating the problem:

To reproduce it yourself, run the sample application, right-click on every row of the red DataGrid (everything will be correct), then scroll to the end of the list and do the same - you'll quickly find a mis-match like I show above. The fix is as easy as introducing the DataContextPropagationGrid class (as I did for the green DataGrid) - the important thing is to be sure to attach the ContextMenu to the DataContextPropagationGrid so the workaround has a chance to do its thing:

<!-- DataGrid+ContextMenu example of the workaround -->
<sdk:DataGrid Grid.Column="1" Grid.Row="1" AutoGenerateColumns="False" Margin="10">
    <sdk:DataGrid.Columns>
        <sdk:DataGridTemplateColumn Header="Values">
            <sdk:DataGridTemplateColumn.CellTemplate>
                <DataTemplate>
                    <delay:DataContextPropagationGrid>
                        <toolkit:ContextMenuService.ContextMenu>
                            <toolkit:ContextMenu>
                                <toolkit:MenuItem Header="{Binding}"/>
                            </toolkit:ContextMenu>
                        </toolkit:ContextMenuService.ContextMenu>
                        <TextBlock Text="{Binding}"/>
                    </delay:DataContextPropagationGrid>
                </DataTemplate>
            </sdk:DataGridTemplateColumn.CellTemplate>
        </sdk:DataGridTemplateColumn>
    </sdk:DataGrid.Columns>
</sdk:DataGrid>

 

If you run into this Silverlight bug in the DataGrid+ContextMenu scenario, please apply the DataContextPropagationGrid workaround and things should work properly. And if you happen run into the bug in some other scenario, the good news is that the DataContextPropagationGrid workaround should work there, too! Just be mindful to point the Binding's ElementName or Source at the DataContextPropagationGrid element, and you're good to go.

 

[Click here to download the complete source code for the SilverlightDataContextBugWorkaround sample.]

 

PS - Here's the code for the workaround:

using System.Windows;
using System.Windows.Controls;
using System.Windows.Data;

namespace Delay
{
    /// <summary>
    /// Class to help work around a Silverlight bug where DataContext changes to
    /// an element aren't propagated through Bindings on child elements that use
    /// ElementName or Source.
    /// </summary>
    public class DataContextPropagationGrid : Grid
    {
        /// <summary>
        /// Initializes a new instance of the DataContextPropagationGrid class.
        /// </summary>
        public DataContextPropagationGrid()
        {
            // Create a Binding to keep InheritedDataContextProperty correct
            SetBinding(InheritedDataContextProperty, new Binding());
        }

        /// <summary>
        /// Identifies the InheritedDataContext DependencyProperty.
        /// </summary>
        public static readonly DependencyProperty InheritedDataContextProperty =
            DependencyProperty.Register(
                "InheritedDataContext",
                typeof(object),
                typeof(DataContextPropagationGrid),
                new PropertyMetadata(null, OnInheritedDataContextChanged));

        /// <summary>
        /// Handles changes to the InheritedDataContext DependencyProperty.
        /// </summary>
        /// <param name="d">Instance with property change.</param>
        /// <param name="e">Property change details.</param>
        private static void OnInheritedDataContextChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
        {
            DataContextPropagationGrid workaround = (DataContextPropagationGrid)d;
            // Update local value of DataContext to prompt Silverlight to update problematic Bindings
            workaround.DataContext = e.NewValue;
            // Unset local value of DataContext so it will continue to inherit from the parent
            workaround.ClearValue(FrameworkElement.DataContextProperty);
        }
    }
}

Last week saw the release of the Windows Phone Developer Tools CTP - April Refresh, a free set of tools and an emulator that lets everyone get started writing Windows Phone 7 applications. Not only is the application platform for Windows Phone 7 based on the same Silverlight framework many of us already know and love, but the tools run on any standard Windows machine and the inclusion of the device emulator means you can test apps on the device without having a device. It's a great developer story and I'm a big fan!

 

However, because Windows Phone 7 is still under development, early adopters sometimes need to deal with a few rough edges... :) I'd heard of occasional difficulties when folks tried to update their applications to run on the April Tools Refresh, so I thought it would be a good learning experience to update an application myself. The obvious choice was my "Silverlight Data Visualization assembly running on Windows Phone 7" blog post sample. Here's how it went for me on a machine that already had the April Refresh installed:

1. Downloaded source code from my blog, unblocked the ZIP file, and extracted its contents.
2. Opened DataVisualizationOnWindowsPhone.sln in Visual Studio - which immediately showed a message that I was using a solution created with a previous release of the tools and listed a specific change that needed to be made to one of the files.
3. I would have been happy to let the tool make that change for me, but it didn't offer to, so I added the 9 new Capability entries to WMAppManifest.xml in the Properties folder just like it suggested:

   ...
   <Capabilities>
     <Capability Name="ID_CAP_NETWORKING" />
     <Capability Name="ID_CAP_LOCATION" />
     <Capability Name="ID_CAP_SENSORS" />
     <Capability Name="ID_CAP_MICROPHONE" />
     <Capability Name="ID_CAP_MEDIALIB" />
     <Capability Name="ID_CAP_GAMERSERVICES" />
     <Capability Name="ID_CAP_PHONEDIALER" />
     <Capability Name="ID_CAP_PUSH_NOTIFICATION" />
     <Capability Name="ID_CAP_WEBBROWSERCOMPONENT" />
   </Capabilities>
   ...

4. I tried running the application, but got a blank screen in the emulator and the dreaded FileLoadException that results from a bug in the April Refresh where it fails to run any application referencing an assembly with a digital signature. The System.Windows.Controls.DataVisualization.Toolkit.dll assembly used by the sample is from my Developer Release 4 which I build myself and don't sign, but the System.Windows.Controls.dll assembly it depends on is from the November 2009 Silverlight 3 release of the Silverlight Toolkit and is signed.
5. So I stripped the signing from the Silverlight Toolkit assembly using the steps Tim Heuer outlines in this blog post and replaced the signed assembly with the unsigned version I'd just created.

   Aside: Yes, this is super-goofy - but I'm told it's going to be fixed!

6. Having done that, I tried running the application again, but got the error "Object reference not set to an instance of an object.". But because I ran into that same problem with the previous tools release, I knew to open MainPage.xaml in Visual Studio and try running the app again.
7. This time around, it ran successfully and I spent some time admiring the beautiful pie chart in all its portrait and landscape glory. :)

 

So, when all is said and done, this ended up being more involved than I expected - but once I jumped through the hoops, my sample application worked exactly the same as it did when I wrote it. I'm happy to report that Charting still runs fine on Windows Phone 7 - and that I've updated the source code download with these changes so nobody else needs to repeat the process! :)

 

[Click here to download the updated Windows Phone 7 Data Visualization sample application.]

A few days ago, Martin Naughton and Tiago Halm de Carvalho e Branco independently contacted me to report a problem they were having with the new ContextMenu control in the April '10 release of the Silverlight Toolkit. In both cases, they were toggling the IsEnabled property of a MenuItem directly and reported that the control's visuals weren't updating correctly. I was a little surprised at first because I knew I'd tested dynamic changes to the enabled state and I'd seen them work properly. But once I created a test project to investigate the report, I saw how the problem scenario was different.

The approach I focused my testing on (and which works correctly by all accounts) is the ICommand (Command/CommandParameter) scenario where the enabled state of the MenuItem is controlled by the CanExecute method of the ICommand implementation. In this scenario, the MenuItem changes its own IsEnabled state and updates its visuals explicitly, so everything is always in sync. But the code from the bug reports wasn't using ICommand; it was manipulating the IsEnabled property directly. The bug is that MenuItem doesn't find out about those changes - the indirect reason being that it doesn't own the IsEnabled property (which it inherits from Control). Because MenuItem doesn't know about the change, it doesn't know to update its visual state. :(

Fortunately, there are some easy workarounds!

 

Workarounds

• Do nothing. I've already checked in a fix for this bug and it will be part of the next Silverlight Toolkit release. If the scenario doesn't matter to you before then, you don't need to worry about it. Otherwise, maybe you can...
• Patch the code, recompile the System.Windows.Controls.Input.Toolkit assembly, and use that in your project. I don't expect most people will want to take this approach, but if it suits you, then it's the next best thing to having a new Toolkit build. Here's the unified diff for the change to MenuItem.cs:

  @@ -143,6 +143,7 @@
           public MenuItem()
           {
               DefaultStyleKey = typeof(MenuItem);
  +            IsEnabledChanged += new DependencyPropertyChangedEventHandler(HandleIsEnabledChanged);
               UpdateIsEnabled();
           }
   
  @@ -301,6 +302,16 @@
           }
   
           /// <summary>
  +        /// Called when the IsEnabled property changes.
  +        /// </summary>
  +        /// <param name="sender">Source of the event.</param>
  +        /// <param name="e">Event arguments.</param>
  +        private void HandleIsEnabledChanged(object sender, DependencyPropertyChangedEventArgs e)
  +        {
  +            ChangeVisualState(true);
  +        }
  +
  +        /// <summary>
           /// Changes to the correct visual state(s) for the control.
           /// </summary>
           /// <param name="useTransitions">True to use transitions; otherwise false.</param>

  But if you're not sure how or where to apply that change (or what to do afterward), this is probably not the best option for you. Instead, you might...
• Switch from manually toggling the IsEnabled property to doing so indirectly via an ICommand implementation. In general, ICommand-based approaches are more consistent with the MVVM pattern and can be more architecturally pure. If you're not already familiar with the technique, it could be worthwhile to read about it: here's a overview of commanding in WPF. That said, it's not always convenient to make changes like this, and sometimes directly toggling IsEnabled really is the best approach. If so, then another option is to...
• "Bounce" the Template property to null and back after changing the IsEnabled property. The bug is mainly cosmetic: the internal state is correct, but the visuals aren't. Therefore, any change to MenuItem that prompts it to update its visual state will correct the problem. While giving the MenuItem focus would work, too, a less intrusive way is to change the value of the control's Template property. But because we don't really want to change the Template, it's necessary to restore the original value. The following code demonstrates this technique:

  // "Bouncing" the Template after toggling works around the issue
  menuItemBounce.IsEnabled = !menuItemBounce.IsEnabled;
  var template = menuItemBounce.Template;
  menuItemBounce.Template = null;
  menuItemBounce.Template = template;

  Because a well-behaved control updates its visual states after getting a new Template, and because MenuItem is well-behaved (usually!), this "bounce" is enough to solve the problem. But maybe you're setting the IsEnabled property with a Binding or don't want to incur the cost of swapping out visuals like this. No problem, you can always...
• Set the MenuItemIsEnabledWorkaround.IsActive attached property (from the code in my sample project) for a seamless workaround. Based on the observation that direct manipulation of the IsEnabled property is rarely associated with the use of an ICommand implementation and the fact that the ICommand scenario works properly today, I created a self-contained workaround that's easy to use. The MenuItemIsEnabledWorkaround class exposes an attached DependencyProperty and implements the ICommand interface. When IsActive is set to True on a MenuItem, an instance of the MenuItemIsEnabledWorkaround class is created and assigned to the MenuItem's Command property. This instance is also hooked up to the MenuItem's IsEnabledChanged event - when that event fires, the MenuItemIsEnabledWorkaround's CanExecuteChanged event is also fired and its CanExecute method reports the new value of the IsEnabled property. That may sound complicated, but it's simple in practice:

  <toolkit:MenuItem
      x:Name="menuItemWorkaround"
      Header="MenuItem with workaround active"
      delay:MenuItemIsEnabledWorkaround.IsActive="True"/>

  // Activating the workaround in XAML requires no code changes
  menuItemWorkaround.IsEnabled = !menuItemWorkaround.IsEnabled;

  By changing the IsEnabled scenario into an ICommand scenario, MenuItemIsEnabledWorkaround sidesteps the bug and saves the day!

 

Examples

I've created a sample application to demonstrate the use of the last two workarounds in practice. It contains a simple ContextMenu with three MenuItems and toggles their IsEnabled state every second (whether the menu is open or not). You'll see either of the last two workarounds is enough to keep the corresponding MenuItem's visual state up to date.

[Click here to download the MenuItemIsEnabledWorkaround sample application and source code.]

 

It's never fun when a bug sneaks by you. :( But it is nice when there are a variety of good options that don't involve jumping through hoops to implement. If you've run into this bug, I apologize for the trouble - and I hope these options help get you going again!

My DataVisualizationDemos application is a collection of nearly all the Data Visualization samples I've posted to my blog. And just like the Data Visualization assembly (get Silverlight/WPF Data Visualization Development Release 4 here!), the demo application runs on Silverlight 3, Silverlight 4, WPF 3.5, and WPF 4 and shares the same code and XAML across all platforms. It's a handy way to look at bunch of sample code running on any of the supported platforms. What's more, each demo page has hyperlinks to relevant blog post(s) for more detail about each scenario, so it's a good learning tool as well! :)

 

Click here to download the complete source code for the cross-platform DataVisualizationDemos sample application.

 

Of the two completely new demos, the prettiest is definitely the "Stacked Series" sample shown above. Its interface is simple - you choose one to three sets of stacked data for examples of all four stacking types and can control the nature of that data: positive/mixed/negative small/large ints/doubles. As you might guess, the corresponding value changes are fully animated, so it's pleasing to watch the charts flow from one configuration to another.

There's also a check-box for switching the examples from "normal" stacked mode into "100%" stacked mode. This transition is not animated because what goes on behind the scenes is a swap of the series types in use. Similarly, choosing a different kind of independent value from the combo-box (string, consecutive numbers, random numbers, or dates) re-creates the data and is not animated.

Disclaimer: As soon as you start playing around with negative values, you'll think you've found a bad rendering bug. But before you fire off an email telling me what a bone-head I am for getting things wrong, please finish reading this post... :)

 

The less attractive - but arguably more interesting - of the two new demos is the "Text-To-Chart" sample shown above. What it lacks in sophisticated UI polish, it makes up for in flexibility. The idea is that you (or me when I'm testing things!) can paste simple tabular data directly from Excel and see how it looks in any of the eight new stacked series types. The dependent values of a single series go down and different series go across (using tab, space, or ';' as a delimiter). It's flexible, so you can have any number of dependent values or series! Independent values are generated automatically according to row number; the only requirement is that every row needs to have the same number of values (i.e., no missing data). If everything checks out, you get a pretty chart of the data - if not, the text turns red to indicate a problem that needs to be corrected.

After a little while playing around with negative numbers, you might end up with the chart shown below;

Clearly, this is a rendering bug - that can't possibly be correct! Let's try it in Excel to see how it's supposed to look so we can tell the developer what a complete bone-head he is:

Oh, snap, it's not a bug after all! :) Whereas the behavior of stacked bar and column charts is fairly intuitively obvious in the presence of negative values, the behavior of stacked line and area charts is not. But it turns out that Excel implements a fairly simple algorithm here - and once I stared at things long enough to figure out what it was, my stacked series charts suddenly matched Excel in all the weird scenarios I've tried so far.

Of course, that's not to say there aren't still bugs in the stacked series implementation - there are bound to be because everything has bugs. But the good news is that I may not be a total bone-head after all. That said, if you run into a scenario where the output from the stacked series code differs from that of Excel, I'd love to hear about it - and "Text-To-Chart" provides a really easy way of sending a bug report! :)

 

The last thing I wanted to call out is that I've updated the "Performance Tweaks" sample (above) to allow the creation of a "Compatible" ScatterSeries (shown above) in addition to the normal kind. You can read more about what I mean in my detailed discussion of the new stacked series support. What's important to know is that holding down the Ctrl key switches the "Add Series" button to an "Add Compatible Series" button - and the resulting series name in the legend will be "Standard" or "Compatible" accordingly.

This makes it easy to see some of the performance improvements I discuss in that blog post for yourself. One good example is the following: Reset, Create Chart, Add Series, Populate, [watch as the points fade in], Change Values, [watch as they move], Change Values, etc.. Now repeat those same steps with a Compatible series and note how everything runs faster!

Aside: If you're on WPF, you may need to increase the number of points before you start seeing a difference.

 

And there you have it: cool new samples to go with the new Data Visualization features. The DataVisualizationDemos application is one of my favorite test cases because it implements a bunch of different scenarios with a variety of different techniques and it runs everywhere the Data Visualization assembly does. (Or at least it did until Windows Phone 7 showed up... Hum, maybe I'll port to that platform next time...)

DataVisualizationDemos has been a tremendous help for me and I hope you enjoy it, too!

The April '10 release of the Silverlight Toolkit brought stacked series support to the Data Visualization assembly on the Silverlight 4 platform! You can read an overview here and get a detailed description here. Almost simultaneously, the WPF team released WPF 4 as part of .NET 4 and Visual Studio 2010.

So it's time for an updated version of my Silverlight/WPF Data Visualization Development Release. Like the previous version, this one continues to support the four platforms of interest to most .NET developers: Silverlight 3, Silverlight 4, WPF 3.5, and WPF 4. But what about Windows Phone 7, the new fifth platform for .NET developers? Yeah, it's supported, too! :)

 

Silverlight/WPF Data Visualization Development Release 4

As with previous Data Visualization Development Releases, I've updated the code and binaries to match the most recent Toolkit release. The Silverlight 4 Toolkit shipped most recently, so the code in this Development Release is identical to what just went out with that. Which means people using Data Visualization on Silverlight 3, Windows Phone 7, WPF 3.5, or WPF 4 can also take advantage of the latest round of improvements by updating their applications to use the binaries included with this Development Release (or by compiling the included source code themselves).

Notes:

• The directions for using this release are the same as last time, so please have a look at earlier posts if you're new to this or need a refresher.
• It's easy to use Data Visualization on Windows Phone 7: simply add a reference to the pre-compiled System.Windows.Controls.DataVisualization.Toolkit.dll assembly from this Development Release and a reference to the System.Windows.Controls.dll assembly from the Silverlight 3 SDK (it contains the implementation of Legend's base class HeaderedItemsControl). Then write the same code/XAML you would for any of the other platforms - it's all interchangeable!

  Aside: The version of Silverlight used by Windows Phone 7 is conceptually equivalent to Silverlight 3 with a variety of Silverlight 4 enhancements throughout.

• All the same cross-platform shared code/XAML goodness of previous Development Releases still applies.

[Click here to download the SilverlightWpfDataVisualization solution including complete source code and pre-compiled binaries for all platforms.]

 

Windows Phone 7 Data Visualization Sample

Trying to use the November 2009 version of the Data Visualization assembly on Windows Phone 7 doesn't work because there's a bug in the Phone version of the .NET Framework that causes bogus exceptions. That bug will be fixed in a future drop of Windows Phone 7 developer bits, but for now it was simplest to work around it myself so folks could start playing around with Data Visualization on the phone today. I wrote the sample application below to show that the Silverlight 3 version of Data Visualization now works seamlessly on Windows Phone 7. And while I was at it, I went ahead and customized the default UI a bit (mostly just tweaking colors and backgrounds) so things really fit in with the overall look and feel of the platform:

As part of this, I made some trivial Template customizations for the Chart element and added just a smidge of code to switch Templates when the device orientation changes. This allows the sample application to make better use of the available screen space (note how the Legend moves and changes shape):

Notes:

• Please be sure to open MainPage.xaml in the development environment before hitting F5 to run the sample - otherwise it seems that deployment of the application to the emulator fails with the message "Object reference not set to an instance of an object.".
• For convenience, I've included the two required assemblies in the ZIP for the sample - all you need in order to build and run is the Windows Phone Developer Tools CTP which can be downloaded for free here.
• Though this is hardly the most interesting chart ever, I hope some of what I show here inspires others to achieve greater things! :)

 

[Click here to download the complete Windows Phone 7 Data Visualization sample application.]

A great way to test a new control is to make use of it in a real-world scenario. So one of the things I did just before we published the April '10 release of the Silverlight Toolkit (click here for my full write-up) was to take the ContextMenu code I'd written out for a little test drive. One of my "stretch goals" for ContextMenu had been to use it to implement a "split button" ever since teammate Ted Glaza brought up the idea during an API review. To make a short story even shorter: it worked! :)

<splitButton:SplitButton Content="Open" Click="Open_Click">
    <splitButton:SplitButton.ButtonMenuItemsSource>
        <toolkit:MenuItem Header="Open" Click="Open_Click"/>
        <toolkit:MenuItem Header="Open read-only" Click="OpenReadOnly_Click"/>
        <toolkit:MenuItem Header="Open as copy" Click="OpenCopy_Click"/>
    </splitButton:SplitButton.ButtonMenuItemsSource>
</splitButton:SplitButton>

 

To get us all on the same page, here's a discussion of split button and menu button in the Windows User Experience Interaction Guidelines. These controls are normal-looking buttons that show a popup menu of other items in certain cases. Because I wanted SplitButton to be a Button, I derived and added a single collection-typed property called ButtonMenuItemsSource which follows the same ItemsControl pattern everyone is already familiar with (and that ContextMenu uses for its items). That done, all that's necessary is to wire up a bit of additional code to support popping the menu when the little arrow (which I call the "split element") is clicked. The default Style/Template of SplitButton is a direct copy of the default for Button - the only change is that the original ContentPresenter has been replaced with a Grid that positions the split element and divider graphics just to the right of the replacement ContentPresenter. To enable complete customization of SplitButton, the ContextMenu is part of the default Template.

Here's how things look after the replacement:

<Grid>
    <Grid.ColumnDefinitions>
        <ColumnDefinition/>
        <ColumnDefinition Width="Auto"/>
        <ColumnDefinition Width="Auto"/>
    </Grid.ColumnDefinitions>
    <ContentPresenter x:Name="contentPresenter" Content="{TemplateBinding Content}" ContentTemplate="{TemplateBinding ContentTemplate}" VerticalAlignment="{TemplateBinding VerticalContentAlignment}" HorizontalAlignment="{TemplateBinding HorizontalContentAlignment}" Margin="{TemplateBinding Padding}"/>
    <Rectangle Grid.Column="1" Width="1" Fill="{TemplateBinding Foreground}" Opacity="0.4" Margin="0 4 0 4"/>
    <Grid x:Name="SplitElement" Grid.Column="2" Background="Transparent">
        <toolkit:ContextMenuService.ContextMenu>
            <toolkit:ContextMenu ItemsSource="{Binding ButtonMenuItemsSource, RelativeSource={RelativeSource TemplatedParent}}" Foreground="{TemplateBinding Foreground}" FlowDirection="{TemplateBinding FlowDirection}"/>
        </toolkit:ContextMenuService.ContextMenu>
        <Path Data="M 0,0 L 8,0 L 4,4 Z" Fill="{TemplateBinding Foreground}" Margin="2 0 4 0" VerticalAlignment="Center"/>
    </Grid>
</Grid>

What's great is that simply tweaking this template to make the split element be the background of the entire button gets most of the way to MenuButton! After that, all it takes is a subclass and two lines of code!

 

That's really all there is to it! To be clear, I didn't set out to build the world's best SplitButton ever - my primary goal was to get some good ContextMenu testing done. (Speaking of which, I found (and fixed) a bug in the process, so it was definitely worthwhile!) Just now, I spent a bit more time cleaning up my SplitButton implementation and adding some polish like XML comments, keyboard support, RTL support, etc., and at this point I think SplitButton and MenuButton could be used in many applications as-is. If you do that, I'd love to hear about it! :)

 

[Click here to download the complete source code for SplitButton/MenuButton and the sample application shown above.]

 

Note: The sample project is for Silverlight 4, but everything I do here can be applied to WPF as well. That said, if I were going to port this code to WPF, one of the things I'd look into doing differently (in addition to updating the Style/Template!) is the positioning logic. WPF's ContextMenu supports additional positioning logic via the Placement/PlacementTarget properties that could be used to simplify this implementation even further!

Yesterday's publication of the April '10 release of the Silverlight Toolkit includes a bunch of new functionality. If you haven't read my release notes post, now might be a good time to do so...

Okay, thanks. :) I intentionally didn't go into much detail about the improvements to the Data Visualization assembly in that post because that's the point of this post. So let's get started!

 

Motivation

Some of the top customer requests for Silverlight/WPF Data Visualization have been:

• Stacked series
• Better performance
• A pony

This release of the Toolkit delivers on two of those. (Sorry, you're going to have to wait a little while longer for the pony.)

 

 

Implementation

The primary goal for Data Visualization in this release of the Toolkit was to implement support for stacked series. I started out by looking at ways of adding that functionality to the existing series hierarchy (based on the DataPointSeries base class). There were two options that seemed interesting, so I played around with each for a bit. But while both definitely seemed viable, neither felt completely right to me. I was also very concerned about accidentally breaking existing scenarios with the addition of the new stacking code (i.e., primum non nocere). At the same time, I'd become curious about the merits of an alternate implementation we'd talked about a couple of times...

So I experimented with merging all the ideas by implementing stacking support with a new, distinct series hierarchy and building everything up from the ISeries interface. While this would obviously create more work in some respects (duplicating portions of existing functionality), it also meant that I could factor everything I learned from working with the original hierarchy into the new design. Along the way, I kept to a strict rule: no modifications to existing Charting code beyond necessary bug fixes (and there were only one or two of these). With this approach, I could be fairly confident about minimizing the risk to existing applications and scenarios. And besides, the fact that it's so easy to do is a great example of Charting's flexible extensibility model! :)

As a result, the new stacked series hierarchy is completely compatible with the original series hierarchy and all of the existing Chart/Axis/DataPoint/etc. infrastructure. (Although it doesn't usually make a lot of sense, you can even mix both hierarchies in the same chart!) The original hierarchy was fairly DataPoint-centric: everything revolved around DataPoint instances, their management, their display, etc.. Consequently, the base class of the original series hierarchy was named DataPointSeries. Now, while the new hierarchy also manages DataPoints, the heart of it is centered around definitions of each series (much like how the Grid class uses definitions to describe its layout). Therefore, the base class of the new hierarchy is named DefinitionSeries for consistency with the original hierarchy as well as the naming conventions used elsewhere by Charting. The definitions that control this new hierarchy are put inside an instance of the DefinitionSeries class to define individual series. The definition class is therefore named SeriesDefinition (in keeping with the same naming pattern and akin to Grid's RowDefinition).

If you've been paying close attention so far (or perhaps really if you haven't), you see that a DefinitionSeries contains SeriesDefinitions and might wonder "Golly, won't that naming juxtaposition be confusing?". Well, it's actually pretty easy to keep straight if you remember the naming pattern is DistinguishingCharacteristic+TypeName. :) But what's far more significant is that most code will never deal with the DefinitionSeries class directly - it's an abstract base class and can't be instantiated in XAML. What people will end up using are one of the eight new series types, all of which are fairly unambiguously named:

• StackedBarSeries
• StackedColumnSeries
• StackedLineSeries
• StackedAreaSeries
• Stacked100BarSeries
• Stacked100ColumnSeries
• Stacked100LineSeries
• Stacked100AreaSeries

The first four classes listed above are "normal" stacked implementations of a bar/column/line/area series; the last four types are their "100%" stacked variants. "Normal" stacked series render based on the actual values of the data involved (ex: 10, 3.25, 712) whereas the 100% stacked series display the dependent values as percentages of the whole (kind of like how pie charts work - everything always adds up to 100%).

 

 

Supplication

The first hierarchy was based on series instances which worked together at times (in the case of multiple column and bar series). The new hierarchy is based on a single instance coordinating an arbitrary number of constituent series definitions. Why the difference? Coordination. Where stacked series are concerned, data points from one member series have a very strong dependence - and effect - on the positions of points in the other series. While it would certainly be possible to coordinate this effort in the original model (as we do for columns that share the same category slot), there's a distinct lack of a conceptual "owner" and it's also not clear where to put properties that affect the stacked series as an whole (ex: an explicit axis). By creating a single entity to represent the stacked series "group", the answers become obvious. So the question becomes whether it makes sense to have a "simple wrapper with sophisticated children" or a "sophisticated wrapper with simple children". And it seems pretty clear that things will be easier all around if the parent/wrapper class is not just the place where common properties are set, but also where all the logic for managing the stacked series lives.

 

Inspiration

The original hierarchy was designed with extreme extensibility in mind - and one of the things customers frequently comment on is just how flexible things are and how easy it is to build on top of. But flexibility has its price - one of the other things customers comment on is how they'd like better performance. (And don't forget the pony.) Because the existing hierarchy seemed to have extensibility pretty well covered, what I wanted to do with the new hierarchy was focus on performance. To that end, one of the most significant changes I made is that the stacked series hierarchy keeps itself out of the business of managing the DataPoint lifecycle (something that causes a decent amount of overhead for the old hierarchy). Instead, DefinitionSeries uses an ItemsControl to handle the gory details of container creation, realization, deletion, etc.. What's particularly nice is that this is exactly what ItemsControl is designed and optimized for, so it's a great example of using the right tool for the job.

Another potential bottleneck for the original series stack is that it makes most changes "on demand" - by which I mean that as soon as a value change is detected for the user's data object, that change gets propagated through the entire system. Now, that's a perfectly reasonable approach to take and it nicely ensures everything is always up to date. But it also suffers from a pretty big drawback: when many things are changing at the same time, there's a whole lot of wasted effort. So when the new stacked series hierarchy finds out about a value change, it simply leaves itself a little reminder to update the relevant graphic during the next update pass - and then returns immediately without doing anything else. In the simple scenario of isolated onesey-twosey changes, the net result is about the same amount of work for both series hierarchies - but in scenarios where lots of things are changing at the same time, the new approach turns an ~O(N+) problem into an ~O(1) one because all those cascading, overlapping changes collapse into a single "update everything at once" operation. (Yes, I'm playing fast and loose with big O notation here - the idea is that instead of doing what amounts to the same positioning calculations over and over again, it's done just once.)

 

 

Duplication

If you think about it for a bit, it seems obvious that a StackedLineSeries plotting just one series should look more or less identical to a normal LineSeries plotting the same data. So it really ought to be possible to use a stacked series in most of the same places its non-stacked counterpart makes sense. Which would be little more than a superficial parlor trick if there weren't a compelling reason to use the seemingly more complex implementation in the simpler scenario... [Aside: Hold that thought for just a moment. :) ]

Even without a compelling functional reason to substitute like this, there's a very good testing reason to switch: suddenly every existing Charting application becomes a test case for the new stacked series hierarchy! If there were an easy way to substitute a stacked series (with its slightly different API) into an existing scenario, this would help identify all kinds of issues with the new hierarchy. (Trust me, I speak from experience.) And that's why I created the System.Windows.Controls.DataVisualization.Charting.Compatible namespace. It contains five classes named ColumnSeries, BarSeries, LineSeries, AreaSeries, and ScatterSeries which are API-wise virtually identical to the original series implementations of the same names, but use the new stacked series code under the hood. Which makes it trivial to substitute them for their non-stacked counterparts.

Aside: Where did a stacked implementation of ScatterSeries come from? Nowhere, actually - it's just a stacked LineSeries with an invisible line. :) Which means it suffers from some completely unnecessary overhead because it burns cycles managing a line nobody can see and it has all the overhead of supporting stacking. However, we'll find out in a moment that it can still outperform the original, unburdened ScatterSeries implementation!

These "Compatible" classes don't show up in the design tools because I don't want anyone to confuse the two same-named implementations of the same behavior. But if you want to make the switch, all it takes is a trivial XAML/code edit to convert many scenarios over. This conversion can be a tad more involved when there's a lot of code that directly manipulates the base classes of the old hierarchy, but the process is usually quite simple and straightforward. I should know, I performed this conversion for every public Charting sample I've written as part of my testing efforts!

 

Implication

I've probably way over-done the foreshadowing, so the following revelation isn't likely to surprise anyone: the stacked series hierarchy can be significantly faster than its non-stacked counterpart! Of course, I don't guarantee that every scenario is faster. In fact, I'd be very surprised if that were the case - there are certain aspects of the new implementation that I know to be suboptimal. However, some scenarios are very noticeably faster in practice. To demonstrate that, I've enhanced the "Performance Tweaks" page of my DataVisualizationDemos application (which I'll be releasing a new version of shortly!) to allow the creation of a "Compatible" ScatterSeries. Comparing the two implementations highlights some clear performance wins for the stacked hierarchy: configurations that bog down the system when using the original series hierarchy are reasonably snappy with the stacked one. Looking at it from the opposite direction, this means it can be possible to get the same level of performance with more points on the screen simply by switching to the new hierarchy.

Another interesting side effect of having a parallel implementation is that the two are not likely to have the same bugs. Specifically, there are some scenarios I know to be problematic with the original series implementation that literally "just work" when converted to the new implementation. I've already seen this happen in practice with two different customer apps - I was able to work around a problematic behavior in the original stack simply by switching to the new stack. Of course, no code is perfect - and as much as I've tried to find all the bugs in the new code, there are certain to be problems I don't know about yet. So this duality is hardly a panacea. That said, it's a nice trick to have in your back pocket for those times where it is relevant and can save you a bunch of time debugging something you didn't have to!

 

 

Enumeration

The new hierarchy looks and behaves basically the same as the old hierarchy in most respects - and all the concepts people are used to dealing with still apply. API-wise, nearly all the same properties are still available and do the same thing they've always done - they're just split across the DefinitionSeries classes and SeriesDefinition according to where they make the most sense. Though there is one deliberate omission and a few details have changed just a bit. Here's the scoop:

• Setting DependentValuePath or DependentValueBinding is now required (the former is the simple form that takes a property name to use as the path of a Binding; the latter is the advanced form that takes a full Binding which may be specifically customized by the developer). Similarly, setting IndependentValuePath or IndependentValueBinding is now also required. We'd originally thought it would be nice for users if we avoided the need to set these properties, but some people ended up confused anyway. Because supporting that behavior also complicated the implementation, the stacked series hierarchy doesn't try to be clever here. One of each pair must be set. Always.
• On a very related note, the exception type and message that result when the Binding/Path properties aren't set is not always as clear as it could be with the original series hierarchy. But because of the new hierarchy's stricter requirements, it's possible for to give a very relevant, specific error message in these cases.
• I mentioned that there's a single property that's absent from the new hierarchy: AnimationSequence. While the original idea of making it easy for users to stagger the show/hide transitions of the DataPoints seemed cool, very few people seemed to use this feature in practice. And like above, this feature required a non-trivial amount of rather involved code that occasionally tripped people up or caused problems. Therefore, AnimationSequence is not available on the stacked series classes.
• The base class of Legend was changed to HeaderedItemsControl in the previous Toolkit release, but the Title property wasn't removed in order to avoid breaking existing templates. Unfortunately, that left Legend with two different properties corresponding to the same thing: Title and Header (the latter coming from HeaderedItemsControl). While I think "Title" is a better name for what the properties mean for Legend, the duplication required synchronizing their contents and there were situations where this introduced problems. Therefore, Legend's Title property has been removed and all relevant templates have been updated to refer to the Header property.
• It used to be that attempts to customize the Legend's Visibility property via the Chart.LegendStyle were ineffectual. Regrettably, Legend itself stomped on its own Visibility property as part of its attempt to hide when it had no content to display. That annoying behavior has been corrected in this release and it's now possible to hide the Legend by setting its Visibility to Collapsed with the LegendStyle property.
• While doing performance measurements for the stacked series hierarchy, I discovered some unfortunate inefficiencies in the axis stack. The relevant code has been tuned for this release and the resulting performance improvements will be visible to all series implementations.
• The color of the line/area graphic for the original LineSeries and AreaSeries is derived from the Background of the effective DataPointStyle for the series. This makes sense and can be convenient - but it can also be confusing when users set the PolylineStyle or PathStyle properties, too. And because these two properties couldn't previously be set in the Palette of a Chart, the designer story wasn't as good as it could have been here. Therefore, I've added a DataShapeStyle property to the stacked series hierarchy which can be used just like DataPointStyle and is also fetched from the relevant ResourceDictionary palette entry. Similarly, I've added DataShapeStyle entries to the default Palette entries so the appearance of the stacked series classes should be more obvious and more readily customized.
• I mentioned above that DefinitionSeries uses ItemsControl for all its point management - but that's not quite true... It really uses ListBox, and because ListBox supports single- and multi-select modes, it was rather easy to plumb that support through to DefinitionSeries as well. Therefore, instead of exposing an IsSelectionEnabled property like the original series classes do, the stacked series classes expose a SelectionModes property which can be set to None, Single, or Multiple. The corresponding read/write properties SelectedIndex, SelectedItem, SelectedItems, and the SelectionChanged event (a true RoutedEvent on WPF) are also available and behave just like they do for ListBox.
• In one of those rare cases where the default behavior "just makes sense", the result of using the "Compatible" ColumnSeries or BarSeries to display a series with one or more items that share the same independent value is that the columns with shared values stack with each other. If that seems obvious to you, I agree! :) What's interesting is that we spent a decent amount of time discussing what *should* happen during the implementation of the original ColumnSeries before settling on the current "staggered" behavior. (There's an example of this near the middle of this post.) And while I still think staggering is the right behavior for the original implementation, I was quite pleased when I saw that the new implementation handled this edge case automatically and sensibly!

 

Consternation

Okay, this blog post ended up being heavy on explanation and light on code - so I apologize to all the code junkies out there. :) Don't worry, though, I've got your fix coming! In the next few days I'll be posting an updated version of my Silverlight/WPF Data Visualization Development Release along with an updated DataVisualizationDemos sample that includes two new samples to show off stacked series. And I'll be including a little treat just to keep things interesting...

 

Whew! If you've read this far, I commend you! I hope you learned something along the way or at least enjoyed the journey. My next post will focus on code - I promise. :)