In my current SilverLight project we required a variety of features that were not present in any of the online implementations. Features like multi-level treemaps, zooming, progressive reveal of information, selection events, filtering, dynamic views, etc were something we found missing in existing implementations. We wanted a single control that had all of these features. Instead of starting from scratch we took inspiration from the following places:

• SilverLight Treemap on CodePlex
• Descry
• Treemap by the Microsoft GPDE team

 A new custom control: TreeMapView

TreeMapView is the custom control I built that has many of the features mentioned earlier. Its built in SilverLight 3 and as expected does a lot of stuff via data-binding. It uses Visual State Manager (VSM) extensively for showing state changes and animating transitions. Some of the common features include:

Multi-level hierarchies: It can represent multiple levels of hierarchy, so you can visualize treemaps within treemaps! The figure below shows three levels of treemaps. 

Fine grained styling: One can style the root nodes, internal nodes and leaf nodes separately. It is very common to use a different style for the root level nodes, since you want them to stand out when you first see the map. Similarly, the leaf nodes require special visual treatment which is supported.

Drill downs: It is impossible to show every level legibly in one view but drill-downs make this easier. You can click and go deeper into the hierarchy and see more detail as you drill in. This is the notion of progressive reveal, which is taken care using special states. You can style the progressive reveal using VSM, giving you have complete power in choosing how and what to style and show (reveal).

Breadcrumb trail: The breadcrumb trail is useful when you are doing drill downs. The TreeMapView publishes a list of items indicating the path along a subtree. This path changes as you drill in/out. You can style this path and provide navigation support for your drill downs.

Filters: When viewing large datasets, filters make it easier to hone into the stuff you are interested. Again, the filtered state of the treemap can by stylized using VSM. The figure below shows one possible way of styling filtered items. Colored items are the ones that match the criteria.

Dynamic views: A treemap sizes the boxes based on some attribute of the data. You can change this attribute on the fly (by bindings) and see different views of the data. Quickly switching between different views gives you a better perspective of the kind of the data you are visualizing.

Coloring the tiles: This is a primary requirement of any treemap control. The color of a box indicates the weight of some attribute. You have complete control over this using bindings and converters. You can bind to the attribute you want to use for coloring the tile and use a converter to provide the different colors.

Virtualization: As you start visualizing large datasets, you cannot afford to create controls for every item. Virtualization helps in reducing the number of controls and improves the performance for this scenario. Since custom virtualization is not supported natively in SilverLight, I had to write my own version based on my experience with WPF. In principle it is similar to Deep Zoom.

Mouse hovers: Hovers can be styled using ToolTips

Selections: You can click a tile to select it, which automatically updates the SelectedItem property and also raises the SelectionChanged event. Selections can be styled via VSM.

Usage

The programming model is fairly straightforward and using it is also simple. Here is a Xaml snippet that shows the usage:

        <Controls1:TreeMapView x:Name="TM"
                               Controls:DockPanel.Dock="Left"
                               SizeBinding="{Binding Quantity}"
                               HeaderBinding="{Binding Name}"
                               ColorBinding="{Binding Status, Converter={StaticResource Converter}}"
                               ItemsSource="{Binding Traders}"
                               ChildItemsSourceBinding="{Binding ChildTraders}"
                               ItemStyle="{StaticResource DefaultItemStyle}"
                               ContainerStyle="{StaticResource DefaultItemStyle}"
                               RootContainerStyle="{StaticResource DefaultItemStyle}"
                               />

The TreeMapView creates instances of TreeMapTile for each item in a level. TreeMapTiles can contain child tiles to give you the nested view. The ChildItemsSourceBinding property of the TreeMapView can be used to create nested levels. SizeBinding is used to size the tiles and ColorBinding determines the color of each tile. Typically you would use the ColorBinding with a converter to map the data to a brush. ItemStyle is the style used for leaf tiles. ContainerStyle is for internal nodes and RootContainerStyle is for the top level tiles.

Video 

Here is a quick video showing all of these features in action:

Since there are many such areas in the UI, which have changeable views, there are many TransitionPresenters that act as the containers for the views. Swapping of the views typically happens via user interaction and there is also an action that needs to get invoked whenever a view changes. In the first iteration of my solution, I had some code-behind which would do the view-swap and call an action when the transition completed. It looked something like the snippet below.

private void ExecuteFlip(object parameter)
{
    string prevFace = (string) parameter;
    string nextFace = string.Empty;

    if (prevFace == "Preferences")
    {
        _flipTransition.Rotation = Direction.RightToLeft;
        nextFace = "Main";
    }
    else if (prevFace == "Main")
    {
        _flipTransition.Rotation = Direction.LeftToRight;
        nextFace = "Preferences";
    }

    EventHandler handler = null;
    handler = delegate
                  {
                      _transContainer.TransitionCompleted -= handler;
                      /* Do some action */
                  };
    _transContainer.TransitionCompleted += handler;
    _transContainer.ApplyTransition(prevFace, nextFace);
}

ExecuteFlip is called on some user-interaction, generally via a command invoked on a button-click. Depending on the parameter (which is the current view-name) I decide what should be the next view and also adjust the transition to use. Before invoking the transition, I attach an event-handler for the TransitionPresenter’s TransitionCompleted event. This is needed to invoke some actions after the transition completes.

As you can see, for a UI that has many such TransitionPresenters, the code-behind can get pretty repetitive and messy. It’s too much duplication and can easily overwhelm anyone maintaining this code. Fortunately, attached properties come to the rescue.

The need for a ViewManager

To simplify this process of invoking a transition, attaching to the TransitionCompleted event and doing some post-transition action, I have come up with the static ViewManager class that exposes a single attached property called ViewName (of type string). Within the property changed handler for this atttached property, I discover the parent TransitionPresenter and cache in a Dictionary. The Dictionary is just a map of view-name to TransitionPresenter. Here is the code that shows all of these pieces.

private static Dictionary<string, TransitionPresenter> _mapper;

public static readonly DependencyProperty ViewNameProperty = DependencyProperty.RegisterAttached(
    "ViewName", typeof (string), typeof (ViewManager), new PropertyMetadata(OnViewNameChanged));

static ViewManager()
{
    _mapper = new Dictionary<string, TransitionPresenter>();
}

public static void SetViewName(DependencyObject d, string name)
{
    d.SetValue(ViewNameProperty, name);
}

private static void OnViewNameChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
{
    UserControl view = d as UserControl;
    if (view == null) throw new ArgumentException("The ViewManager.ViewName attached can only be used on a UserControl");

    string viewName = (string) e.NewValue;
    if (string.IsNullOrEmpty(viewName)) throw new ArgumentException("ViewName cannot be null or empty");

    view.Loaded += FindTransitionPresenter;
}

private static void FindTransitionPresenter(object sender, RoutedEventArgs e)
{
    UserControl view = (UserControl) sender;
    view.Loaded -= FindTransitionPresenter;

    DependencyObject parent = VisualTreeHelper.GetParent(view);
    while (parent != null && !(parent is TransitionPresenter))
    {
        parent = VisualTreeHelper.GetParent(parent);
    }

    if (parent == null)
    {
        throw new Exception("Could not find a TransitionPresenter in the parent chain of view");
    }
    TransitionPresenter presenter = (TransitionPresenter) parent;
    string viewName = (string)view.GetValue(ViewNameProperty);
    _mapper.Add(viewName, presenter);
}

The interesting part here is the fact that I hook into the view’s (UserControl) Loaded event to discover the TransitionPresenter. The Loaded event is fired when WPF has created the visual tree and run a first pass of layout and rendering. Hooking into this event gives us a safe way to navigate the visual tree. The actual discovery of the TransitionPresenter happens in the FindTransitionPresenter method. This method also adds the link between the view-name and the TransitionPresenter and stores it in the map. At the end of this, we have a way to know the TransitionPresenter, given the string view-name.

 Time for transition

Before we can invoke the transition, we need to associate the ViewName attached property to all of our views. Additionally these views need to be nested inside a TransitionPresenter, since we check for that in the FindTransitionPresenter method. Here is a snippet of adding this attached property:

        <Controls:TransitionPresenter Transition="{StaticResource FlipTransition}"
                                      Focusable="False"
                                      KeyboardNavigation.IsTabStop="False">
            <Views:PreferencesView x:Name="Preferences"
                                   Controls1:ViewManager.ViewName="Preferences" />
            <Views:MainView x:Name="Main"
                            Controls1:ViewManager.ViewName="Main" />
        </Controls:TransitionPresenter>

With that done, we are now in a position to actually invoke the transitions and to do that we have the ViewManager.SwitchView method. Since for a transition you need two views, SwitchView takes the view-names as its parameters. We actually have three different overloads of this method:

public static void SwitchView(string fromView, string toView)

public static void SwitchView(string fromView, string toView, Action onViewSwitchCompleted)

public static void SwitchView(string fromView, string toView, Action onViewSwitchCompleted, Action<TransitionPresenter> configure)

The first overload should be obvious, it does a simple transition between the views and nothing more. The second overload gives you a callback method that will be invoked once the transition is complete. The last overload gives you the additional capability to configure your TransitionPresenter before the transition happens. I have used this overload to change the transition for some views. Now lets look at the SwitchView method. I am just showing the third overload, as the other two just call into it.

public static void SwitchView(string fromView, string toView, Action onViewSwitchCompleted, Action<TransitionPresenter> configure)
{
    TransitionPresenter fromTP = _mapper[fromView];
    TransitionPresenter toTP = _mapper[toView];

    if (fromTP != toTP) throw new Exception("TransitionPresenters of From and To views don't match");

    EventHandler handler = null;
    handler = delegate
    {
        fromTP.TransitionCompleted -= handler;

        if (onViewSwitchCompleted != null)
        {
            onViewSwitchCompleted();
        }
    };
    fromTP.TransitionCompleted += handler;

    if (configure != null)
    {
        configure(fromTP);
    }
    fromTP.ApplyTransition(fromView, toView);
}

The code here checks if the two views share the same TransitionPresenter and throws an exception otherwise. It then hooks into the TransitionCompleted event and fires the callback when the transition completes. It also calls the configure callback to do any pre-transition configuration on the TransitionPresenter. You can see how the boilerplate code from the first implementation is nicely wrapped up over here.

Using the ViewManager

If you have already setup the ViewName attached properties, using the ViewManager is as simple as calling SwitchView with the correct view-names. If you have some action to be carried out at the end of the transition, you can also pass in an Action delegate. I use the Action delegate to set focus on some controls or set some UI properties. The ExecuteFlip method that I mentioned earlier now looks like so:

private void ExecuteFlip(object parameter)
{
    string prevFace = (string) parameter;
    string nextFace = prevFace == "Preferences" ? "Main" : "Preferences";

    Action onSwitch = () => { /* Do some action */ };
    Action<TransitionPresenter> configure = (tp) =>
                                                {
                                                    FlipTransition t = (FlipTransition)tp.Transition;
                                                    t.Rotation = prevFace == "Preferences" ? Direction.RightToLeft : Direction.LeftToRight;
                                                };
    ViewManager.SwitchView(prevFace, nextFace, onSwitch, configure);
}

Some Takeaways

• One can argue that using strings for view-names is not type-safe and should instead be enums. But then you limit yourself to a particular enum-type and need to constantly update it as new views are added. One way to have type safety would be to expose static string constants on your App and use them instead.
• You can also have some setup methods on the ViewManager to do any global configuration. You could call this once your main window is loaded. I use it to setup some default durations on all TransitionPresenters.
• One big advantage of the ViewManager is that a transition on any part of the UI can be invoked from any other part of the UI. All I need to know are the view-names that are involved in the transition and just call ViewManager.SwitchView. Internally the correct TransitionPresenter is determined and used for the transition. This has been a great feature for me as there are some non-user-events that cause transitions on some views.

Similar Posts:

• TransitionContainer: Easy transitions between views
• A Design Pattern for communication between UI and ViewModel
• How to do Sort / Filter / Group in your custom control
• Drag & Drop with attached properties – Part 2
• Techniques for UI Auditing on WPF apps

• A Service Model (SM), which is essentially a web-service with a bunch of data-contracts
• A View Model (VM) which talks to the SM on a background thread and notifies the UI whenever an operation completes. The VM also stores a reference to the Dispatcher, which is used to communicate with the UI
• …and finally the UI – the WPF powerhouse

A redesign

The first time I designed the communication channel, there were events on the VM that mirrored the operations that were present on the SM. These VM-events were fired on the UI thread using Dispatcher.BeginInvoke. The UI subscribed to all of these events and did some visual changes. This model worked great for the initial set of operations that we had in the SM. As the number of operations grew (currently there are about 8 different ones), I realized that the event model is not scaling well.

Instead of the VM raising an event on the UI thread, I decided to use the power of delegates to automatically invoke them on the UI thread whenever an operation completed. Let me explain this more clearly.

As mentioned earlier, the VM already has a reference to the Dispatcher. Note that when I say the VM has reference to the Dispatcher, it is really the root of the ViewModel, a singleton, that stores the reference to the Dispatcher. Instead of mirrored Service Model events, the VM now exposes methods with an Action delegate as a parameter. Let me show you the most commonly used method, EnqueueTask:

public void EnqueueTask(ServerTaskType task, Action completedUIAction)
{
    if (task == ServerTaskType.Initialize)
    {
    EventHandler<FeedDownloadedEventArgs> handler = null;
    handler = (sender, args) =>
    {
        _controller.HistoryDownloaded -= handler;
        OnHistoryAvailable(args, completedUIAction);
    };
    _controller.HistoryDownloaded += handler;
    _controller.Initialize();
    }
    else if (task == ServerTaskType.Reload)
    {
    EventHandler<FeedDownloadedEventArgs> handler = null;
    handler = (sender, args) =>
    {
        _controller.HistoryDownloaded -= handler;
        OnHistoryAvailable(args, completedUIAction);
    };
    _controller.HistoryDownloaded += handler;

    _controller.ReloadHistory();
    _controller.GetPeerList();
    }
}

The above method does the actual subscription to the Service Model event and also unsubscribes when the operation completes. It then raises the completedUIAction delegate. This action is invoked using Dispatcher.BeginInvoke so it always happens on the UI thread. Here is the OnHistoryAvailable method, which does the job of updating the ViewModel and then calling the action to update the UI (using a custom InvokeOnDispatcher convenience method). Note that we are passing the action delegate to this method.

private void OnHistoryAvailable(FeedDownloadedEventArgs e, Action completedAction)
{
    InvokeOnDispatcher(
    delegate
    {
        // Update the ViewModel 
        // <Code deleted for brevity>

        // Finally call the completed action, which will update some UI 
        if (completedAction != null)
        {
            completedAction();
        }
    });

}

So what’s the advantage?

Good question! As you can see, I no longer need to expose any further events from the VM, which the UI subscribes to. The event handler code on the UI is now passed in as an Action delegate which the VM nicely calls on the UI thread. Also this technique is scalable to a large number of Service Model events. All I change on my side is the switch case for the operations.

[Currently I am using this technique to show/hide progress bars and other animations. The animation starts before a call to EnqueueTask and stopped in the completedUIAction.]

Possible improvements

If we have a large number of SM-events, we can have a simple mapping table that maps the operation-type to a method on the VM. We can then simply lookup that method from the table and pass it the completedUIAction delegate. This can save us a long switch-case in EnqueueTask.

We can also use generic Action<T> delegates that could be used to pass some state information back to the UI.

Hopefully you will find this technique useful in your own apps !

Similar Posts:

• Drag & Drop with attached properties – Part 2
• Using Attached Properties for view transitions, the ViewManager
• Huge limitation of a MarkupExtension
• Drag & Drop with attached properties – Part 3
• Drag & Drop with attached properties

I had lot of trouble making it work with issues like: XDebug not being recognized, Apache webserver crashes, etc. However I finally got it working and below are the steps I took on my Windows Vista machine:

• If you doing WordPress development, most probably you are using XAMPPLite to run a local webserver. If not, you should definitely get it. The rest of the steps assume that you have XAMPPLite on your machine.
• To set up XDebug, first get hold of the latest DLL from the XDebug website.  The site recommends version 2.0.x for a PHP version of 5.2.x. At the time of writing this post, I used php_xdebug-2.0.4-5.2.8.dll
• Edit your php.ini file in <xampplite-install-folder>/apache/bin/. Note that you should edit the php.ini file in apache/bin and NOT in <xampplite-install-folder>/php/. This is the biggest mistake most people make, including me.
• Add these lines at the end of the .ini file:
  

  [xdebug]
  zend_extension_ts="<xampplie-install-folder>/php/ext/php_xdebug-<version-number>.dll"
  xdebug.remote_enable=1
  xdebug.remote_host=localhost
  xdebug.remote_port=9000
  xdebug.remote_handler=dbgp

• Next increase the memory limit of your PHP script to 128M, by modifying the memory_limit variable in php.ini. It is usually around line 246 in that file.
  

  memory_limit = 128M      ; Maximum amount of memory a script may consume (16MB)

• Save the .ini file and restart the Apache server. I typically do this via the XAMPPLite control panel.

• Now if you go to http://localhost/xampp/ and click on the phpinfo() link on the left-hand sidebar, you should see a spew of xdebug information. Here is how mine looks:

• If you see the above in your output, you are all set and XDebug should start working within NetBeans. You can now happily set breakpoints in your script and debug all your PHP worries

I hope in the future this process becomes a lot simpler, but until then this post will definitely remain useful!

Similar Posts:

• Playing with Wordpress, PHP, Photoshop, CSS, XHTML

At the recent MVP Summit, I got a chance to catch up with other MVP buddies who also provided some valuable feedback on the content. Interestingly, my publisher was also at the Summit and it was the first time meeting him. He can be sure now that it is not a robot writing the book.

In the last few weeks, I got emails from many of you asking about the status of the book. I hope this post will tell you that things are moving towards completion. Some of you have offered to review the book, which was quite flattering for me. I will try to reach out to you once I incorporate the feedback from my current reviewers.

If you are curious to know more about the book, try Amazon. We already have a placeholder for the book!

BTW, this is going to be a full color book with rich set of examples, controls, figures and of course syntax-highlighted code!

Similar Posts:

• Working on a Book !
• Details of my upcoming Book
• [FluidKit Update] Fixed bugs, added stuff
• File encodings matter when writing Pixel Shaders
• Drag & Drop with attached properties – Part 3

The technique I am using to do this animation is with Clipping Masks. The graph starts out with a Rectangular mask with zero-width and ends with the full-width of the graph after the animation completes. The height of the mask is the same as that of the graph. The following figure shows how my mask grows in size.

In Xaml, this can look like so:

<Grid x:Name="GraphContainer">
    <!—Line Graph -->
    <Grid.Clip>
        <RectangleGeometry />
    </Grid.Clip>
</Grid>

The above snippet shows the container on which the Clip mask has been applied. The line graph is inside the GraphContainer. The Storyboard looks like:

<Storyboard x:Key="GraphClipAnimator">
    <RectAnimation Duration="0:0:1"
                   Storyboard.TargetProperty="Clip.(RectangleGeometry.Rect)"
                   Storyboard.TargetName="GraphContainer"/>
</Storyboard>

Note the use of RectAnimation for expanding the size of the mask. It starts out with a Rect(0, 0, 0, GraphContainer.ActualHeight) and ends with a Rect(0, 0, GraphContainer.ActualWidth, GraphContainer.ActualHeight). We set the From/To values of the RectAnimation inside the Loaded event for the containing Window/UserControl.

The advantage of this technique is that you can choose a more elaborate clipping mask (think of arbitrary PathGeometry) to achieve more fluid graph animations. Also we are not affecting the actual graph in any way and all of the animations are happening on its container. This makes it easy to reuse the technique on multiple graphs.

Similar Posts:

• Super Fast alternating row colors in a ListBox
• TransitionContainer: Easy transitions between views
• Don’t forget to pass the Input brush to the Shader
• Quick tip to get a striped background
• Automatic form layouts with the TreeView

Steps

1. Lets start out by picking a Square brush shape. We need to reduce the Roundness to get the horizontal dash and also increase the Spacing to see the spacing between dashes.

2. Now if you notice in the preview area, you will see that the dashes are not oriented along the direction of the curve. This can be easily fixed by going into the Shape Dynamics section. Here we change the Angle Jitter’s Control to Direction. Notice how the preview has changed to align the dashes along the curve.

3. Now if I draw something on my layer with my newly created brush, I get some nice dashed outlines!

I think the best use of such a brush is for shapes like Rectangle, Circle, etc

Hope you Photoshop-ers find this useful !

Similar Posts:

• Playing with Wordpress, PHP, Photoshop, CSS, XHTML
• My first shot at Wordpress themes

Organizing assets

If you have few assets, you could just keep them under a folder in your main assembly. However if you have a variety of assets and in large numbers, you are better off keeping them in separate assemblies. Each assembly can now serve as a theme for your application. Within the assembly you could break up your assets into a folder structure. As a simple example, you could have a structure like so:

You can come up with a more elaborate structure depending on the variety and the number of assets that you have. Since this post is more about referencing assets than organizing them, I am going to jump to that now. I assume you already have a folder structure for your assets that is similar to the one I mentioned above.

Referencing assets

If you are to store your assets in a separate assembly, the referencing Uri can be rather long, something like:

pack://application:,,,/Company.ThemeName;component/Images/Icons/Large/up.png

Try typing few of those Uri’s and I can guarantee the beginnings of a Carpal tunnel . This is where a MarkupExtension can be very useful. It will abstract out those long paths and only keep the part that is essential. So you could be seeing something like:

<ImageBrush x:Key="SelfFill"
            ImageSource="{ln:Asset Icons/marker/self_fill.png}" />

Surely this is more readable than the previous path. If you are a bit more adventurous, you can also add a prefix to the path that will further abstract the actual location of the resource. For example the above MarkupExtension usage could be: {ln:Asset MarkerIcons:self_fill.png}. Note the MarkerIcons: prefix, which will internally map to the Images/Icons/marker path. You can come up with your own prefixes that will simplify the paths, as you see fit for your project.

The AssetExtension class contains the logic to parse the paths and create the appropriate resources. Just like every other MarkupExtension, the ProvideValue() method is where the bulk of the logic is. In the case of AssetExtension, there is a Regex that parses the path and identifies the kind of resource we are dealing with.

Here is the Regex that I am using:

        private static Regex ResourceRegex = new Regex(
                @"
                        (?<Image>(.png|.jpg|.bmp)$)
                        | (?<Font>#.+$)
                        | (?<Xaml>.xaml$)
                ",
                RegexOptions.Singleline | RegexOptions.Compiled |
        RegexOptions.IgnorePatternWhitespace |
                RegexOptions.IgnoreCase | RegexOptions.CultureInvariant);

Once we know the resource-type, we create it inside of ProvideValue() and return that as the output. The core methods are below. ResourceType is an enum that I am using internally.

public static Uri GetResourceUri(string path)
{
    string asmName = Assembly.GetExecutingAssembly().GetName().Name;
    string uriString =
     string.Format("pack://application:,,,/{0};component/{1}",
                           asmName, path);
    Uri uri = new Uri(uriString);

    return uri;
}

public override object ProvideValue(IServiceProvider serviceProvider)
{
    IProvideValueTarget ipvt =
    serviceProvider.GetService(typeof (IProvideValueTarget))
                                           as IProvideValueTarget;
    if (ipvt == null) return null;

    ResourceType type = ParseResourceType(Path);
    switch (type)
    {
        case ResourceType.Image:
            BitmapImage image =
                        new BitmapImage(GetResourceUri(Path));
            return image;

        case ResourceType.Font:
            FontFamily family =
                       new FontFamily(GetResourceUri(""), Path);
            return family;

        case ResourceType.Xaml:
            return GetResourceUri(Path);
    }

    return null;
}

private ResourceType ParseResourceType(string path)
{
    ResourceType type = ResourceType.None;

    Match match = ResourceRegex.Match(path);
    if (match.Groups["Image"].Success) type = ResourceType.Image;
    else if (match.Groups["Font"].Success) type = ResourceType.Font;
    else if (match.Groups["Xaml"].Success) type = ResourceType.Xaml;

    return type;
}

Summary

So if you have project that uses a ton of assets, it is probably easier to use a MarkupExtension to reference them instead of hard-coding paths. Besides simplifying the paths, it also helps you in refactoring. If you wish to relocate the assets to a different assembly or change the folder structure, it is much easier now, since you only change the AssetExtension.

The attached source file contains all the code. Note that it does not contain the code for parsing prefixes. I’ll leave that as an exercise for the readers!

Download AssetExtension.cs

Similar Posts:

• Don’t forget to pass the Input brush to the Shader
• TransitionContainer: Easy transitions between views
• Huge limitation of a MarkupExtension
• Quick tip to get a striped background
• Automatic form layouts with the TreeView