Silverlight Scratchpad

Designing for Browser-Zoom: Part 2

noreply@blogger.com (Phil Middlemiss) — Thu, 03 Feb 2011 01:40:00 +0000

[UPDATED: Fixed broken links for download]

The ability to adjust the magnification level in your browser (using zoom + or -) has the potential to ruin your carefully crafted UI design. In Part 1 we took a look at the mechanisms involved in browser zoom and the effect it can have on your Silverlight app (particularly the EnableAutoZoom setting).

In this part we are going to handle browser zoom with visual states and use an attached behaviour that allows us to integrate zoom management into our views and control templates from Blend, without having to write any code.

A Demonstration

Here is the sample application we will be working with. This is just a mock layout of a simple utility app – it is contrived for the purposes of showing how scaling can affect your design:

to launch this in a separate window and use the the browser’s zooming feature to zoom in to 150%, 200%, then back to 100%. This demonstrates the desired behaviour. You will see the spacing content change at each of those zoom levels – and at 200% the images are no longer visible. There is a link for the source code at the end of the article.

If this app is zoomed into 200% within the same available space, without adjusting the design for the zoom level, then the result is the undesired behaviour which looks like this:

As you can see, the title bar now takes up half the available height, a complete row of buttons is missing, and the button captions are cut off. Remember, if the user has their DPI settings set to show large text this could already be happening to your existing Silverlight apps!

Using Visual States for Zoom Levels

I’m going to make an assumption here for the sake of demonstration. I’m going to assume that some user research was carried out and showed that people were zooming in (or it was happening automatically based on the host computer’s DPI setting) because they liked large text – the images are not important to them.

Given this assumption, I need to be able to adjust the layout for different zoom levels, giving priority to the text in the application (headings, button captions etc). Visual States are ideal for showing the same information in a different way. I’ll use Blend to show how I have set up the visual states here:

The image above shows the VisualStateGroup “ZoomStates” with three VisualStates in the group: Unzoomed, Zoomed150, and Zoomed200. In each of these states I have adjusted the spacing available for the header and adjusted the margins around each of the panels (which are HeaderedContentControls).

I have a problem though: I have customized the control templates for the HeaderedContentControl and the Button controls. How do I include changes to the control templates as part of a visual state for the main view? I can’t! I could create 3 different control templates for each control I was customizing, but that would quickly become a maintenance nightmare for a decent sized project.

There is another answer to this problem that I will discuss below, but for now we have to work out how to switch states as the browser zoom changes.

The Application.Host.Content.Zoomed Event

The Content class in the System.Windows.Interop namespace (part of the Silverlight System.Windows assembly) is described by the documentation as follows:

“Reports details about the Silverlight-based application's instantiation settings, and exposes some of the HTML DOM values for the hosted Silverlight plug-in instance. System.Windows.Interop.Content contains APIs that specifically relate to the Silverlight content area (the area declared by the width and height in the initialization).”

One of its members is the Zoomed event. If the browser starts up and responds to the host system’s DPI settings, or if the user manually zooms, then this event is fired. We can hook into this event in the Loaded event of our main view and respond to changes in the zoom like this:

   1: public partial class MainPage : UserControl

   2: {

   3:     public MainPage()

   4:     {

   5:         // Required to initialize variables

   6:         InitializeComponent();

   7:         Application.Current.Host.Content.Zoomed += this.Content_Zoomed;

   8:     }

9:

  10:     private void Content_Zoomed(object sender, EventArgs e)

  11:     {

  12:         var zoom = Application.Current.Host.Content.ZoomFactor;

  13:         if (zoom <= 1)

  14:         {

  15:             VisualStateManager.GoToState(this, "Unzoomed", true);

  16:         }

  17:         else if (zoom <= 1.5)

  18:         {

  19:             VisualStateManager.GoToState(this, "Zoomed150", true);

  20:         }

  21:         else if (zoom <= 2)

  22:         {

  23:             VisualStateManager.GoToState(this, "Zoomed200", true);

  24:         }

  25:     }

  26: }

The above code hooks into the Zoomed event and, when it fires, checks what the current ZoomFactor is. It then uses that value to determine which visual state it should transition to.

Now we have a mechanism to adjust our design to the current zoom level, but we still have a few problems:

We still can’t reach into control templates to adjust margins and content
We have to re-write this code (paying careful attention to state names) for every view we create
We have to write code! Not very friendly for dedicated designers who are working with Blend

Behavioural Zoom Management

An attached behaviour could help us solve all three of these problems. Let's look at each problem in reverse order:

Unfriendly to a designer: An attached behaviour is drag-n-drop easy and we can use a Blend SDK attribute to help us pick the state to transition to.

Re-writing code: An attached behaviour encapsulates the code and lets us reuse it with ease.

Reaching into the control template: Hmmm, this one is a little more interesting. A control template already comes with pre-defined states (some controls have none) and using VisualStateManager.GoToState does not work for any additional states you add by hand (our ZoomedStates group). So if we customize a control template and add our new zoom states to it, can we find a way to transition to those states? As it turns out, there is a way: A visual state is a wrapper around a storyboard – so we could write our attached behaviour to locate the appropriate state, reach inside it for the storyboard, and just play the storyboard. This actually works, but there is a caveat that I will discuss below.

You can download the code for the ZoomResponder attached behaviour here. Without giving a full listing, I’ll go over the main parts of the code.

First up, here are the dependency properties for the attached behaviour:

   1: public static readonly DependencyProperty ZoomRangeStartProperty = DependencyProperty.Register(

   2:     "ZoomRangeStart", typeof(double), typeof(BrowserZoomStateBehavior), null);

3:

   4: public static readonly DependencyProperty ZoomRangeEndProperty = DependencyProperty.Register(

   5:     "ZoomRangeEnd", typeof(double), typeof(BrowserZoomStateBehavior), null);

6:

   7: public static readonly DependencyProperty StateNameProperty = DependencyProperty.Register(

   8:     "StateName", typeof(string), typeof(BrowserZoomStateBehavior), null);

Each dependency property also has a public class property with a getter and a setter.

This attached behaviour is responsible for one zoom state (“StateName”). To respond to the 150% and 200% zoom levels we need 3 of these attached behaviours (the third one is to transition back to the unzoomed state). The “ZoomRangeStart” is inclusive and the “ZoomRangeEnd” is exclusive. Therefore, the behaviour for switching to the 150% will have ZoomRangeStart = 1.5 and ZoomRangeEnd = 2 since there will be a different instance of the behaviour responsible for switching to 200%.

The public class property for the StateName property is decorated with the CustomPropertyValueEditor attribute from the System.Windows.Interactivity namespace:

1:

   2: [CustomPropertyValueEditor(CustomPropertyValueEditor.StateName)]

   3: public string StateName

   4: {

   5:     get

   6:     {

   7:         return (string)this.GetValue(StateNameProperty);

   8:     }

   9:     set

  10:     {

  11:         this.SetValue(StateNameProperty, value);

  12:     }

  13: }

That attribute lets Blend know that the property is the name of an existing state in the XAML. It changes the property editor for the the StateName property from a text box to a drop down combo box that lists the available states that have been defined. Handy!

So the view will have three of these templates attached to its root:

Here is the main code that handles the state change:

   1: private void UpdateZoomedState()

   2: {

   3:     var zoomed = Application.Current.Host.Content.ZoomFactor;

   4:     if (zoomed >= this.ZoomRangeStart && zoomed < this.ZoomRangeEnd)

   5:     {

   6:         if (!VisualStateManager.GoToState(

   7:             this.AssociatedObject,

   8:             this.StateName,

   9:             true))

  10:         {

  11:             if (null == this.AssociatedObject.Parent &&

  12:                 VisualTreeHelper.GetParent(this.AssociatedObject) is Control)

  13:             {

  14:                 // play the storyboard - we are probably inside a control template

  15:                 var stateGroups = VisualStateManager.GetVisualStateGroups(

  16:                     this.AssociatedObject);

  17:                 foreach (VisualStateGroup stateGroup in stateGroups)

  18:                 {

  19:                     foreach (VisualState visualState in stateGroup.States)

  20:                     {

  21:                         if (null != visualState.Storyboard &&

  22:                             visualState.Name.Equals(this.StateName))

  23:                         {

  24:                             visualState.Storyboard.Begin();

  25:                             return;

  26:                         }

  27:                     }

  28:                 }

  29:             }

  30:         }

  31:     }

  32: }

The behaviour first tries to use the VisualStateManager to transition to the associated state. If the result of the call to VisualStateManager.GoToState is false then we know the call failed, possibly because the associated object is inside a control template (as discussed above). The code checks to see if the logical parent of the associated object is null and if the visual parent of the associated object is a control. If both of these conditions are true then we will assume we are attached to a control template and try to find a matching state associated with it. If we find one, we grab its storyboard and play it.

Caveats

There is one thing to be aware of when using this inside a control template. Do not use storyboards with “From” values in the key frames, otherwise you will end up with bizarre animations playing when they should not. For example, if you had the visual state for “Unzoomed” specify a “From” value for a key frame, you would end up playing that storyboard regardless of the zoom factor the browser was last set at, including values that fall between the different states (e.g. 125%).

Summary

In these two posts I have shown how the browser zoom can play a big part in how your design appears to the end user. Introducing visual states to accommodate different zoom levels is one way to handle it. An attached behaviour that wraps up the management of switching states in response to the zoom event provides an elegant response to this issue that designers can use.

You can grab the code here.

Designing for Browser-Zoom: Part 1

noreply@blogger.com (Phil Middlemiss) — Wed, 02 Feb 2011 00:35:00 +0000

Zooming is good for you

The ability to zoom your web browser content is often over-looked when designing either traditional or Silverlight web applications - but it can also be a feature, rather than a problem. Silverlight’s native ability to respond to the browser-zoom provides the potential to really enhance your user’s experience of the application.

I was recently giving a demo of a Silverlight mock-up (with Sketch Flow) and one of the clients complained that he liked to increase the DPI setting on his computer because he had difficulty reading standard sized text. I showed him, on the demo computer, how he could zoom the content in the browser (in IE it’s Ctrl + and Ctrl – to zoom in and out) and the Silverlight app scaled along with it. Thankfully, the mock-ups happened to scale nicely and everything still fit snuggly in the available screen-space.

But it got me thinking about how to respond better to the browser content zooming in and out. I happen to manage the UX side of my current employer’s software development and it occurred to me that if a Silverlight application didn’t respond well to the zoom setting, it could completely ruin the user’s experience of that Silverlight Application.

So this will be a two-part series on how the user experience of your Silverlight application can be enhanced by accounting for the browser zoom feature:

The first part (this part) will cover the zoom mechanism and the different pieces that are involved.
In the second part I will show you how to adjust your design with a little bit of code and some visual states.I will also present an attached behaviour you can use in Blend to respond to the zoom event without having to write code.

How zooming works

There are four things you should know about the zooming feature of a browser and it’s interaction with Silverlight:

1. EnableAutoZoom

All the big-name browsers support zooming the page content. Internet Explorer (possibly others too) also respects the DPI settings on the host computer and automatically zooms the browser content to match it. In Windows 7, one way to change this DPI value is through the Control Panel –> Display settings page:

If these settings are changed then, by default, when IE starts it will scale your whole web page, including your Silverlight application, automatically to reflect these DPI settings. The effect is the same as if you had scaled the whole page manually. The Internet Explorer team call this Adaptive Zooming.

If your Silverlight application takes up the whole page, or is part of a page design that uses the remaining space that other scalable elements don’t need, then this may cause problems for your layout. You may end up with headers or footers that unnecessarily take up way too much room and leave too little room for grids and lists of details.

At the very least, you should know how to disable this automatic behaviour if you don’t plan on accommodating it; you can control this behavior with the Silverlight object embed “EnableAutoZoom” setting which looks like this:

<object ...>
  <param name="enableautozoom" value="bool"/>
  ...
</object>

To turn it off, set it to “False”. But I would recommend, instead of turning it off, that you use it to your advantage and keep your application usable at different zoom levels.

2. OnZoom

If you are writing JavaScript for your page for custom layout effects etc, then you can add a handler for the zoom event by attaching it to the OnZoom event on the Silverlight object. I only mention this in passing for the sake of completeness since I am focusing here on the Silverlight side of things. For more information on this event, you should read about the Html Bridge between managed and unmanaged code.

3. Content.Zoomed

You can respond to zoom events in managed code, inside your Silverlight app, by attaching a handler to the Content.Zoomed event like this:

Application.Current.Host.Content.Zoomed += new EventHandler(this.ContentZoomed);

This event will fire when the user manually zooms the page (e.g. Ctrl + and Ctrl - in IE) and will also fire when the application first loads (for IE at least) if the DPI settings for the computer have been changed from the standard setting.

The event handler takes the standard sender object and a basic EventArgs that contains no useful information. So how do we know what the current zoom settings is? With the Content.ZoomFactor property.

4. Content.ZoomFactor

The Content.ZoomFactor gives the current zoom ratio for the whole page including your Silverlight Application. A value of 1 means 100%, 1.5 means 150% etc.

What to do about zoom?

So how do we take advantage of this built in ability to scale the whole application? How do we accommodate the users who like having their DPI settings increased? We need to think carefully about how our screen layouts and designs would look when scaled to different zoom levels.

Just as an experiment, between now and the next post, fire up one of your full screen Silverlight apps, resize the browser to the smallest size where everything still fits nicely, and then zoom in to 150%, or even 200%. How does it look?

In the next post I’ll discuss a way that we can design for this feature and still have our screens look beautiful.

Two-Way Binding on TreeView.SelectedItem

noreply@blogger.com (Phil Middlemiss) — Tue, 30 Nov 2010 08:12:00 +0000

In this post I’m going to describe an attached-behavior for a TreeView control that allows you to achieve two-way binding on the SelectedItem property. You can grab the source code here.

[UPDATE 6 Dec 2010]: I fixed a bug that was causing it to fail to update the TreeView when the selected node was set (through binding) before the view had loaded.

Background

If you have ever tried using the TreeView control with it’s ItemsSource bound to some kind of data context then you probably know how frustrating it can be to work with the SelectedItem property. This is especially true if you are trying to follow an MVVM pattern.

Typically when you use an ItemsControl you want to create a two-way binding on two of its properties: ItemsSource and SelectedItem. But TreeView, unlike other ItemsControl subclasses, has a read-only SelectedItem property which means no two-way binding like this:

<sdk:TreeView 
    ItemsSource="{Binding TreeNodes}" 
    SelectedItem="{Binding SelectedNode, Mode=TwoWay}"/>

There are a number of workarounds for this challenge (and it is a challenge – just try a Google search for Silverlight TreeView SelectedItem) but most of the solutions I’ve read either seem too complex to use, require you to compromise the MVVM pattern, or are unfriendly with Blend. Wouldn’t it be nice if you could just attach a behavior to the TreeView to make it work?

BindableTreeViewSelectedItemBehavior

Yeah – it’s a long name for a behavior, but at least you know what it does just by reading its name. Using it in Blend is pretty easy:

Just drop it on the TreeView control and set its Binding property.The XAML binding will look like this:

<sdk:TreeView ItemsSource="{Binding TreeNodes}" ...>
    <i:Interaction.Behaviors>
        <Behaviors:BindableTreeViewSelectedItemBehavior 
            Binding="{Binding SelectedNode}"/>
    </i:Interaction.Behaviors>
</sdk:TreeView>

You don’t need to make it a two-way binding, the behavior looks after that for you. Here is a sample application that has two TreeView controls bound to the same data context. If you change the selected item on one TreeView it will update the selected item on the other TreeView:

Under The Hood

This attached behavior works by acting as a go-between using the TreeView.SelectedItemChanged event, the TreeView.SelectedItem property, and a private two-way binding on the data context. Here is a diagram that shows how the behavior wires itself up:

Click on the diagram to see a larger version. The diagram can be broken down as follows:

The behavior examines it’s Binding property and uses that information to create a private two-way binding between the property on the data context of the tree view (in our example it’s against the SelectedNode property) and the behavior’s private SelectedItemProperty DependencyProperty.
When the value for the DataContext’s SelectedNode property changes, the change event for the SelectedItemProperty DependencyProperty (AssociatedObjectSelectedItemChanged) fires and we set the new value on the TreeView using the TreeView.SelectedItem property. This allows the tree view to have its selected item set from the data context.
The behavior also attaches an event handler for the TreeView.SelectedItemChanged event (also called SelectedItemChanged) which fires whenever the user changes the selected item.
When the SelectedItemChanged event handler is called, the behavior updates the value of its SelectedItemProperty DependencyProperty. This allows the data context to have its SelectedNode value updated when the user changes the selected item in the TreeView.

Summary

In this post I described an attached behavior that lets you achieve two-way binding on the TreeView.SelectedItem property. The behavior is especially useful if you are using the MVVM pattern to keep your views and view models separate, and want to avoid code in the View’s code-behind file. The source can be downloaded here.

A Behavior for Remembering Settings

noreply@blogger.com (Phil Middlemiss) — Tue, 23 Nov 2010 08:18:00 +0000

I have been unusually busy for the last couple of months and have been neglecting my blog. Things are still pretty busy, but I hope to squeeze out a few posts if I can.

In this post I’m going to describe a behavior that you can attach to your controls and bind to a property on that control. The behavior will monitor the value of that property and store any changes to it in Isolated Storage. The next time you start the application the behavior will look in Isolated Storage and load the value if it can find it, then restore the value to the control. This is a handy behavior for things like grid splitters, sliders, or similar types of controls (dial’s too!) where you want any changes the user makes to be remembered the next time they run your app.

Demo Application

You can grab the behavior here. And this is the behavior in action:

If you refresh this page, the application will remember the opacity value for the border control, the position of the grid splitter, and the selected index of the list.

Using the behavior looks like this:

   1: <Border x:Name="border">   2:     <i:Interaction.Behaviors>   3:         <TotalRecall:TotalRecallBehavior Binding="{Binding Opacity, ElementName=border}"/>   4:     </i:Interaction.Behaviors>   5: </Border>

There are two things worth discussing about this behavior; the Binding to a control’s property and the the storing/retrieving using Isolated Storage.

Binding to a Control’s Property

The XAML above shows the TotalRecallBehavior being used to remember the opacity of the border element. Internally, the behavior needs to know when the property being bound to (in this instance it is the Border.Opacity property) changes value so it can store it away for next time. To do this, the behavior has an internal DependencyProperty called BindingValueProperty that it uses to create another two-way binding to the same property on the control. BindingValueProperty has an event handler for when the value changes so it can store the new value in Isolated Storage.

The code that uses the behavior’s Binding property to set up a private two-way binding looks like this:

   1: private void CreateBindings()   2: {   3:     var expression = this.ReadLocalValue(BindingProperty) as BindingExpression;   4:     var watcher = new Binding();   5:     if (expression.ParentBinding.Source != null)   6:     {   7:         watcher.Source = expression.ParentBinding.Source;   8:     }   9:     else  10:     {  11:         watcher.ElementName = expression.ParentBinding.ElementName;  12:     }  13:    14:     watcher.Path = new PropertyPath(expression.ParentBinding.Path.Path);  15:     watcher.Mode = BindingMode.TwoWay;  16:     BindingOperations.SetBinding(this, BindingValueProperty, watcher);  17:    18:     this.recallValue = new RecallValue(this.AssociatedObject.GetType().Name + "." +   19:         AssociatedObject.Name + "." + expression.ParentBinding.Path.Path);  20: }

The call to “this.ReadLocalValue(BindingProperty) as BindingExpression” is exactly what UIElement.GetBindingExpression() does, but the Behavior is not a UIElement so I just make the same call. Getting hold of the BindingExpression is important since it gives us access to the correct binding source and property path. The BindingExpression only exists on the source object of the binding (even if it is two-way), so on line 2 of the XAML snippet the binding is set on the behavior and must therefore be read from the behavior with the call to ReadLocalValue (line 16 of the C# code above). If you try and read the BindingExpression on the element being bound to you will get null returned.

The behavior sets up the binding and creates an instance of the RecallValue class. I have future plans for the RecallValue class, but for now it is simply a wrapper around a string value.

Using the ApplicationSettings on IsolatedStorage

You can use isolated storage to store all kinds of information on the user’s local machine. You can read all about local storage in Silverlight here. One of the less frequently covered uses of Isolated Storage is the IsolatedStorageSettings.ApplicationSettings static property. This property is an IDictionary and has an indexer you can use to read and write with. These are very handy for storing atomic name-value pairs; exactly the kind of thing I want to do with this behavior.

The code that read’s the value from isolated storage is as follows:

   1: if (IsolatedStorageSettings.ApplicationSettings.Contains(this.recallValue.Key))   2: {   3:     this.recallValue.Value = (string)IsolatedStorageSettings.ApplicationSettings[this.recallValue.Key];   4: }   5: if (null != this.recallValue.Value)   6: {   7:     this.SetValue(BindingValueProperty, this.recallValue.Value);   8: }

The value is read from isolated storage if it exists, and set as the value for our private BindingValueProperty dependency property, which is by now two-way bound to the control’s property. The IsolatedStorageSettings class takes care of creating a location in isolated storage for the values so there’s no other code needed for setting up file streams and creating directories etc.

Similarly, the code for writing to the isolated storage settings is as follows:

IsolatedStorageSettings.ApplicationSettings[behavior.recallValue.Key] = behavior.recallValue.Value;

The rest of the behavior is just plumbing.

Future Improvements

As I said earlier, I have plans for the RecallValue class. I want to support the saving/restoring of complex objects and values that don’t parse easily to and from string.

I would also like to improve the design-time experience – the Binding type doesn’t play very nice with Blend’s element binding design tool, so I can’t use the CustomPropertyValueEditor attribute. I would really like the design time property editor for the Binding to list the properties on the attached object the same way the ChangePropertyAction does.

Summary

In this post I’ve described a behavior that remembers the value of a property on the control it is attached to. I described the use of the BindingExpression class to create a private two-way binding, and described how to use the IsolatedStorageSettings.ApplicationSettings dictionary. In the code download there are examples of the behavior being used on different kinds of controls and properties.

A Tiled Image Brush for Silverlight

noreply@blogger.com (Phil Middlemiss) — Mon, 06 Sep 2010 09:00:00 +0000

The Silverlight ImageBrush does not support the TileMode property that exists in WPF, and as a result there is no built in way to have tiled images as a background brush for your controls and styles.

The following control may be useful to you if you find yourself wanting to achieve the same things as a WPF tiled image brush.

You can grab the source here. It is a control that behaves like a Border control, except that it also has a TiledImageSource property that you can use to select an image resource from the project.

The TiledBGControl control (um, didn’t think too hard about naming it) is a viewless control, so you can change its default control template the same way you can for any other control. This is the structure of the default control template:

The template has a grid with two Border controls in it. The back-most Border (the first one) is a control part that must exist, the source code of the control looks for this control and applies a shader effect to it to produce the tiled effect. The second Border is simply to provide the visible border around the control. I can’t use the first Border control to draw the visible border because all the pixels of that Border control (including the visible border) are replaced by the shader effect. The ContentPresenter is placed in the second Border control so that it appears on top of the tiled background.

The following two sections give a quick description of the pixel shaders and then an overview of how the control works.

Wrapping up a Pixel Shader

I’ve gone looking for a tiled image brush for Silverlight before. It’s just not possible (to the best of my knowledge) to create in Silverlight the same kind of tile brush that WPF has. The closest I’ve seen to accomplishing this effect is with a pixel shader. A pixel shader is a set of instructions that can change the pixels in a given area. For example, the built in Silverlight blur and drop-shadow effects uses a pixel shader. The instructions are written in a language called HLSL, compiled, and wrapped up in the .Net framework ShaderEffect class.

Walt Ritcher’s excellent free Shazzam tool can be used to create and test pixel shaders. It comes with a shader called “Tiler”, authored by A.Boschin, that allows you to achieve the tiled background effect but it is a little awkward to use as-is for a fluid interface. The Tiler shader has four properties for controlling how it is applied:

VerticalTileCount – how many tiles to squeeze in vertically in the given space
HorizontalTileCount – how many tiles to squeeze in horizontally in the given space
HorizontalOffset – a horizontal offset to apply to the first tile
VerticalOffset – a vertical offset to apply to the first tile

Using a shader like this is a little awkward because a shader doesn’t know how big an area it is being applied to (in pixels). It processes each location in the area by using a value between 0 and 1 for an x and y coordinate. If you want to keep the tile image at a 1:1 scale, you need to calculate how many tiles fit into the area the shader is applied to, and update this every time the area changes size. In WPF, the pixel shaders are executed on the GPU which saves the CPU for application logic, but Silverlight does not use the GPU (and probably never will), so the shaders must be used sparingly to prevent the CPU from slowing to a crawl.

I used the Tiler sample shader as a starting point and modified it, replacing the properties above with these ones:

TextureMap – the tile image to repeat as a background
DestinationHeight – the height of the destination area. This needs to be updated as the target area changes size
DestinationWidth – the width of the destination area. This also needs to be updated as the target area changes size
TileHeight – the height of the tile to be repeated as a background
TileWidth – the width of the tile to be repeated as a background

The main reason I did it this way was to learn HLSL; I could have just as easily used the same approach as the Tiler shader and calculated the number of vertical and horizontal tiles when the container changed size. The code for my pixel shader is as follows:

   1: /// <class>TilerXY</class>   2: /// <description>Pixel shader tiles the image to size according to destination width and height</description>   3: ///   4:     5: // Created by P.Middlemiss: phil.middlemiss@gmail.com   6: // blog: http://silverscratch.blogspot.com/   7:     8: sampler2D TextureMap : register(s2);   9:    10:    11: /// <summary>The height of the target area.</summary>  12: /// <minValue>0</minValue>  13: /// <maxValue>3000</maxValue>  14: /// <defaultValue>300</defaultValue>  15: float DestinationHeight : register(C1);  16:    17: /// <summary>The width of the target area.</summary>  18: /// <minValue>0</minValue>  19: /// <maxValue>3000</maxValue>  20: /// <defaultValue>300</defaultValue>  21: float DestinationWidth : register(C2);  22:    23: /// <summary>The height of the tile.</summary>  24: /// <minValue>0</minValue>  25: /// <maxValue>500</maxValue>  26: /// <defaultValue>100</defaultValue>  27: float TileHeight : register(C3);  28:    29: /// <summary>The width of the tile.</summary>  30: /// <minValue>0</minValue>  31: /// <maxValue>500</maxValue>  32: /// <defaultValue>100</defaultValue>  33: float TileWidth : register(C4);  34:    35: sampler2D SourceSampler : register(S0);  36:    37: float4 main(float2 uv : TEXCOORD) : COLOR  38: {  39:     float xx = ((uv.x * DestinationWidth % TileWidth) / TileWidth);  40:     float yy = ((uv.y * DestinationHeight % TileHeight) / TileHeight);  41:     float2 newUv = float2(xx , yy) ;  42:     float4 color= tex2D( TextureMap, newUv );  43:     float4 source = tex2D( SourceSampler, uv);  44:     color *= source.a;  45:     return color;  46: }

I’m still learning HLSL so I’m sure the code above could be improved. I have a fairly new computer and the CPU doesn’t really budge at all when using this component, but I would be interested to hear back from anyone with an older PC to see if performance is an issue, or from anyone who can suggest improvements to the HLSL.

The TiledBGControl

The TiledBGControl wraps up all of the awkwardness of using the pixel shader and lets you just supply the image source to use. The OnApplyTemplate method is overriden and carries out the following tasks:

The control looks for the template part called “PART_TiledBorder” and attaches the above shader effect to it.
An ImageBrush is created using the supplied TiledImageSource value and set as the value of the TextureMap property of the shader.
An event is attached to the border that updates the DestinationHeight and DestinationWidth when the border changes size.

The TileWidth and TileHeight properties of the shader have to be updated whenever the TileImageSource changes. The TileImageSource is a property of type ImageSource and is used as the value for the ImageBrush. There are a couple of things to know about the ImageBrush and ImageSource classes:

An ImageSource is not evaluated until is used, which means you don’t necessarily know the size of the image when you assign it.
The ImageBrush fires an ImageOpened event when the ImageSource is resolved
The resolved image is cached, so if you set the ImageSource to a value that has already been resolved you won’t get an ImageOpened event fired again.
The ImageSource, once resolved, can be cast to the BitmapImage type which has the PixelWidth and PixelHeight properties
Setting the ImageBrush.Stretch mode to None does not give the desired result – I thought it would just render the image in its actual size, but it doesn’t. I used Stretch.Fill instead

The code for creating the ImageBrush from the provided ImageSource is as follows:

   1: ImageBrush brush = new ImageBrush();   2: brush.ImageSource = this.TiledImageSource;   3: bool isOpened = 0 != ((BitmapImage)brush.ImageSource).PixelWidth;   4: if (!isOpened)   5: {   6:     // we don't have the size yet so work that out when the ImageSource is resolved   7:     brush.ImageOpened += (sender, args) =>   8:         {   9:             brush.Stretch = Stretch.Fill;  10:             this.tilerXY.TileWidth = ((BitmapImage)brush.ImageSource).PixelWidth;  11:             this.tilerXY.TileHeight = ((BitmapImage)brush.ImageSource).PixelHeight;  12:         };  13: }  14: else  15: {  16:     brush.Stretch = Stretch.Fill;  17:     this.tilerXY.TileWidth = ((BitmapImage)brush.ImageSource).PixelWidth;  18:     this.tilerXY.TileHeight = ((BitmapImage)brush.ImageSource).PixelHeight;  19: }  20: this.tilerXY.TextureMap = brush;

The tile images in the sample above are from www.repeatxy.com. I’ve put the control up on the Expression Gallery, so feel free to grab the source and use it according to the license there.

Redial – A Dial Custom Control

noreply@blogger.com (Phil Middlemiss) — Mon, 23 Aug 2010 08:46:00 +0000

In the last post I described a Dial User Control and promised I would turn it into a Custom Control. Re-doing it as a viewless custom control means it can be visually redesigned without having to write any behavior code.

Here is the control with a couple of different styles, with some of the dials bound to an items source. I also added an animation for the dial positions being added and removed. You can see this by changing the value of the big dial in the bottom left corner; its value sets the MaxValue of the top left dial.

You can grab the source here.

There are a couple of features in this control that weren’t in the User Control:

The ItemsSource property can be bound to a data source for the dial position items. If you use this then don’t use MaxValue since that is automatically determined from the data source.
If you don’t use an items source, the positions are auto-generated using the StartValue and MaxValue properties.
I added very basic support for the mouse wheel, but it needs improvement.
I changed the behavior of the RotationAngle property to take into account any initial rotation of the list box path, and also the span of the path.
You can click and drag around the dial positions to set the value

A Simple Style

The template to the left shows the entire template for the black speaker-style dials in the top right of the sample application above. This is a good starting point for creating styles for the dial since it is very simple.

There are three key elements to note:

The “itemPath” element is the ellipse that defines where the dial positions end up.
The “DialList” element is the path list box that uses the itemPath. The Dial control won’t work without this. Any style for the Dial control must include a PathListBox control called “DialList”.
The “Knob” grid contains the visual elements that are rotated – more about this below.

The remaining elements are not doing anything interesting other than adding to the visual appearance of the knob.

In order to get the knob to rotate, I have bound it to the RotationAngle property:

   1: <Grid x:Name="knob" Margin="10" RenderTransformOrigin="0.5,0.5">   2:     <Grid.RenderTransform>   3:         <CompositeTransform Rotation="{Binding RotationAngle, RelativeSource={RelativeSource TemplatedParent}}"/>   4:     </Grid.RenderTransform>   5:     6:     ...   7:     8: </Grid>

The RotationAngle property calculates the correct position by looking at the DialList PathListBox, determining the rotation of it, and the span. You may have noticed that I used the “RelativeSource” syntax inside a regular Binding instead of using the TemplateBinding syntax. I did this out of habit, since elsewhere I use property converters on bindings in the other templates, and the TemplateBinding class does not support converters.

Here is an example that uses a converter:

   1: <LinearGradientBrush EndPoint="0.5,1" MappingMode="RelativeToBoundingBox" StartPoint="0.5,0">   2:     <LinearGradientBrush.RelativeTransform>   3:         <CompositeTransform CenterY="0.5" CenterX="0.5"    4:             Rotation="{Binding RotationAngle, RelativeSource={RelativeSource TemplatedParent}, Converter={StaticResource negativeConverter}}"/>   5:     </LinearGradientBrush.RelativeTransform>   6:     <GradientStop Color="Black" Offset="1"/>   7:     <GradientStop Color="#FF3B3B3B"/>   8: </LinearGradientBrush>

Feel free to use this control in your own projects.

A Dial (User) Control

noreply@blogger.com (Phil Middlemiss) — Sat, 31 Jul 2010 07:24:00 +0000

I’ve had a busy month on the road visiting clients (and catching up afterwards), so my blog has been pretty quite. But I’ve finally had some time to sit down and play with a couple of ideas I’ve had around using the path list box. I’ve been wanting to make a dial control for quite a while and when the path list box came along in Silverlight 4 it sparked a couple of ideas of how I might do it fairly easily.

Here is a sample application with a single Dial UserControl scaled to a couple of different sizes. At the moment, the only way to change the value of the dial is to click on one of the numbers or lights (one goes to eleven):

You can grab the source here, although at this stage it is still in the “experimental” phase (and I think I left a couple of unused test control templates in there) so play with it at your own risk. There is a bit of left over unused code from the process of trying different things out. I also don’t do much in the way of error or bounds checking so it’s probably quite easy to set the Value and MaxValue to values that cause Silverlight and/or Blend to die horribly. I am going to turn it into a fully skinnable custom control with all the right kinds of checks, but thought it worth putting a post up now and going over some of the challenges I faced with this particular control. It has been nearly a month after all.

Working with the PathListBox

I used the PathListBox control for the dial numbers and lights. If you haven’t used the Path ListBox before then here is a good series on it. The finished UserControl has a MaxValue property that lets you specify how many numbers should appear on the dial, but at the start I just had a the shapes for the dial and used a PathListBox with some fixed items in it.

The first challenge was to get the PathListBoxItem control template to show a mix of orientations. There are two kinds of orientations you can have with a PathListBox: None and OrientToPath. The effects of each of these settings can be seen in the image to the right. If I used Orientation = None the numbers end up being rotated. If I use OrientToPath the light ends up below the number.

What I needed was a way to have the numbers use Orientation = None, and the lights to use Orientation = OrientToPath.

The solution was to change the control template setting that Blend creates by default. The outermost grid in the control template has the following XAML when the template is created:

   1: <Grid Background="{TemplateBinding Background}" RenderTransformOrigin="0.5,0.5">   2:     <Grid.RenderTransform>   3:         <TransformGroup>   4:             <ScaleTransform/>   5:             <SkewTransform/>   6:             <RotateTransform Angle="{Binding OrientationAngle, RelativeSource={RelativeSource TemplatedParent}}"/>   7:             <TranslateTransform/>   8:         </TransformGroup>   9:     </Grid.RenderTransform>  10:    11:     ....  12:    13: </grid>

I changed this to use two child grids and moved the binding to OrientationAngle into one of the child grids:

   1: <Grid Background="{TemplateBinding Background}" RenderTransformOrigin="0.5,0.5">   2:     <grid>   3:         <Grid.RenderTransform>   4:             <TransformGroup>   5:                 <ScaleTransform/>   6:                 <SkewTransform/>   7:                 <RotateTransform Angle="{Binding OrientationAngle, RelativeSource={RelativeSource TemplatedParent}}"/>   8:                 <TranslateTransform/>   9:             </TransformGroup>  10:         </Grid.RenderTransform>  11:    12:     .... items in this grid will be oriented to the path  13:    14:     </grid>  15:     <grid>  16:    17:     .... items in this grid will not be oriented  18:    19:     </grid>  20: </grid>

Now with the PathListBox.Orientation=OrientToPath, only the first grid (containing the light) will rotate, the second grid (containing the number) will be unaffected. Even though the light itself is round and isn’t visually affected by the Orientation, its placement is affected.

Creating the Dial Numbers

I added a Value and a MaxValue dependency property to the UserControl. The MaxValue determines how high the dial goes up to, and the Value determines the current value of the dial. The UserControl has it’s own internal list of items that it recreates whenever MaxValue changes. The PathListBox binds to this list for it’s ItemsSource, and the data template for the PathListBoxItem binds to values on the classes inside the list. This approach reflects a half solution for something that I may or may not do when converting it to a custom control, but the relevant part here is that the list items are driven by the MaxValue property on the UserControl.

Making the Knob

The dial knob presented a couple of challenges. The first was to create the ridged look around its edge. I played with a couple of ideas, but the simplest solution was to use the Star RegularPolygon, which is available under the “Shapes” category in Blend. The RegularPolygon has an InnerRadius property which I set to 98% so that the points are only on the edge, and it has a PointCount property to determine, unsurprisingly, the number of points around the edge. The challenge was that I wanted the dial to work at different sizes, but the PointCount that works for a large dial doesn’t work for a small dial.

I used the Width of the dial to drive the PointCount with a new property on the UserControl and a ValueConverter. I was originally going to just use a ValueConverter and bind to ActualWidth, but there is a known bug where the notification for the change in ActualWidth is not being fired so this always returns 0 to the converter unless the form is resized. The suggested work around is to attach to the SizeChanged event and force a re-layout, but I decided that was too much of a hack, so I added my own DialWidth dependency property and set that to the actual width in the SizeChanged event.

I wrote the ValueConverter to be a generic division converter that returned an integer number; the ConverterParameter can be set to the desired denominator. In the end I could probably have done away with the value converter and DialWidth property and just added my own PointCount property that was recalculated on SizeChanged – and I may yet do that when I convert this into a custom control.

The second challenge was to have the knob rotate to the correct value (including the ridges, center graphic, and position light), but keep the LinearGradient brush fills oriented the same so the light still appears to come from the top:

The knob is contained within two child grids (I used two to have the lights sit above the drop shadow of the dial). The topmost grid has it’s rotation translation template-bound to a new RotationAngle dependency property on the UserControl which is calculated whenever the Value property changes. The gradient brushes of the shapes that make up the knob have their rotation translation bound to the RotationAngle too, but they also use another simple ValueConverter I wrote to return the negative of the value passed to it. So the gradients are rotated anti-clockwise the same amount that the grid containing the dial is rotated clockwise.

The Next Step

As part of converting it to a custom control, I plan to add some better interaction support. Currently the only way to interact with it is by clicking on the lights or numbers to spin the dial to that position. I will add support for the mouse wheel, and (hopefully) support for clicking the knob and dragging it to the desired position (with snapping). I also plan to structure it so that it’s easy to skin and produce some nicely different styles of dials.

So grab the source if you want to have a look, but be warned – it’s a little messy in there, and the documentation is almost non-existent.

Custom Controls – Extending the TextBox

noreply@blogger.com (Phil Middlemiss) — Thu, 01 Jul 2010 04:54:00 +0000

The good folks over at Silverlight Show have just put up my article about writing a custom control. One of my earliest posts was on using a UserControl to create a WatermarkedTextBox. I’ve been meaning to follow up on it for a while on how to achieve the same thing (but better) using a Custom Control. In the example below it’s wired up as a filter for the list box. You can check the “Styled” box to apply a different style to the whole app, including the WatermarkedTextBox.

Go over to Silverlight Show to grab the source and read the full article.

A Chrome and Glass Theme- Part 8

noreply@blogger.com (Phil Middlemiss) — Mon, 28 Jun 2010 07:21:00 +0000

Introduction

In this post I’m going to show you how to make the radio buttons I blogged about previously. These buttons have gone through many iterations and I’m still not sure I’m quite happy with them just yet, but I’ll cover them anyway since they introduce a few interesting attached properties. Here is the sample I’ve been building up, now with the radio buttons:

You can grab the source here.

This post is the 8th in a series. If you are not familiar with styling controls in Blend, or working with Resource Dictionaries then I would recommend that you start at the beginning of the series.

The Radio Button

When I first attempted this button I ended up with horribly complicated arrangement of shapes to get it to scale properly. I had placeholders and spacers and grids within grids, with some of them having their height bound to their widths (which doesn’t work very well). And I had half circles on the ends with gradient blends merging seamlessly into the gradient blend on a rectangle in the middle. It was pretty awful.

The previous blog about Automatic Rectangle Radius X and Y should give you an idea of a simpler way to achieve the look. In the end I went with the attached properties since they work nicely both at run-time and design-time. If you grab the source from the link above, you may have to build it in Blend to get it to use the attached properties on the design surface.

The RadioButton inherits from the ToggleButton, as does the CheckBox. They all have a common theme of the button being checked, unchecked, or indeterminate; The radio button just has a different visual appearance, and adds the GroupName property. This style could be adapted for the ToggleButton too, but it wouldn’t really work as a style for a CheckBox.

The contents for this button are grouped in a grid with two columns; the left column contains the orb, the right column contains the ContentPresenter element.

Creating a custom style template for a radio button shouldn’t be difficult at all if you have been following along with the series, but I thought it might be worthwhile to look at some of the elements that make up this button.

Scalable Rounded Ends

A rectangle has the RadiusX and RadiusY properties that let you turn the sharp corners into rounded corners. For this button I want the rounded ends to stay rounded, at the right proportion, regardless of the size of the button. Unfortunately, there is no easy way to set those properties to be half of the height of the rectangle.

As mentioned in the post about Automatic Rectangle Radius X and Y I used an attached property to achieve the rounded ends since that gave me the best result when working with Blend. I use 3 rectangles in the button: one for the rim using the ChromeBorder resource brush, one for the main body using the ChromeFill resource brush, and one the same size that uses the ChromeDarkeningLinear resource brush to make the white text stand out better.

The ellipse is used on the right end of the button to add some dark shading to make the button look rounder, and the Orb grid uses the same principle as this post.

I created an attached property called IsRounded that, when true, uses another attached property called RoundCapsRatio (which defaults to 0.5 if unset) that it multiplies against height or width (whichever is smaller) and applies to the RadiusX and RadiusY properties of the rectangle it is attached to. You may have to build the solution once in Blend to have it applied properly, but then the corner radius automatically updates in blend as the rectangle it is applied to changes size.

Scalable Orb

The other attached properties I created are WidthRatio and HeightRatio (not used in this example). I use the WidthRatio attached property on the Orb grid to keep it perfectly square so the ellipses inside it stay round. I can’t have this happen without an attached property because there is no other way (that works in Blend) to set the width of an element to be relative to the height. I set the WidthRatio to the value “1” to achieve this. I could have just used a Boolean attached property, but having the ratio makes it more reusable.

If you use both the attached properties on a visual element, the handler will prefer the WidthRatio over the HeightRatio. Here is the method that applies the property values. It only applies the values if they have actually been set:

   1: private static void UpdateSizeRatio(FrameworkElement element)   2: {   3:     double ratio;   4:     if (element.ReadLocalValue(WidthRatioProperty) != DependencyProperty.UnsetValue)   5:     {   6:         ratio = (double)element.GetValue(WidthRatioProperty);   7:         double height = element.ActualHeight;   8:         if (!double.IsNaN(height) && height > 0)   9:         {  10:             element.Width = height * ratio;  11:         }  12:     }  13:     else if (element.ReadLocalValue(HeightRatioProperty) != DependencyProperty.UnsetValue)  14:     {  15:         ratio = (double)element.GetValue(HeightRatioProperty);  16:         double width = element.ActualWidth;  17:         if (!double.IsNaN(width) && width > 0)  18:         {  19:             element.Height = width * ratio;  20:         }  21:     }  22: }

Conclusion

As far as radio buttons go, these are fairly limited in their application since they are so big. They are too big to use in the same way as you would normally use a radio button, but they do make quite good navigation buttons instead of using tabs.

The use of Attached Properties seems the best solution for adding behavior to a visual element that works at design time in Blend, but it’s not ideal – I would really rather have a way to do this using Blend that didn’t need me to swap into the XAML.

References:

The icons are from the Tango Desktop Project.

Capturing a Silverlight App Screen

noreply@blogger.com (Phil Middlemiss) — Tue, 22 Jun 2010 03:09:00 +0000

Here's a demo Silverlight application that captures the application screen and uses it a couple of different ways.

You can grab the source here.

The “Swap” button uses a screen capture to create a fun transition between two different views. The “Capture Filmstrip” button starts a timer that captures the screen every second and shows a thumbnail view of it. The “Animate Background” button plays a supporting role for the “Capture Filmstrip” button; it animates the background so the filmstrip captures are different from each other even if you don’t interact with the controls. You can click on one of the captured thumbnails to save it to disk.

This article at the excellent Silverlight Show e-magazine has more details on how (and why) to do this.

Blog Administration

noreply@blogger.com (Phil Middlemiss) — Sun, 20 Jun 2010 01:04:00 +0000

I've been using the new features of Blogger to update the theme for Silverlight Scratchpad. As a result a lot of the code samples have been messed up.

So this is a pre-apology that there may be some reposting of old articles as I go through and clean up the code.

Automatic Rectangle Radius X and Y

noreply@blogger.com (Phil Middlemiss) — Mon, 14 Jun 2010 14:46:00 +0000

Introduction

I created a design for a radio button that looks like this:

I'm going to write a future post on how to do this button, but I want to refine it a bit first. In this post I’m going to describe the approach I used for the rounded end-caps in the hopes that someone will help me perfect it.

I have the following requirements for this radio button style:

It must be re-sizable
The rounded ends must stay perfect half circles in proportion to the height of the button
It must behave correctly in Blend
Optional Extra: It would be nice to not have to manually edit XAML in Blend

I have the first three ticked off but the best approach so far still requires editing the XAML by hand. Here is a simple graphic to illustrate the end result when applied to a Rectangle element. The RadiusX and RadiusY are set to half the height of the rectangle:

Having the RadiusX and RadiusY calculated automatically is crucial to this design since I want it to be fully scalable (within reason).

I’ve been through several different approaches trying to get the full 4 marks, but 3 is the best I can manage. If you can spot any improvements or alternative approaches I would welcome suggestions.

Attached Property: 3 out of 4

The winning approach so far is to use an Attached Property that calculates the radii when the rectangle changes size. I made the attached property a little more generic by adding another attached property for specifying a ratio; 0.5 (the default) would give the result above. I also made it work off the lesser of the height and width values to cater for rectangles that are longer than they are wide. Here is the code for the attached property:

   1: using System;   2: using System.Windows;   3: using System.Windows.Shapes;   4:     5: /// <summary>   6: /// Contains attached properties for specifiying rounded ends on a Rectangle   7: /// </summary>   8: public static class RoundCaps   9: {  10:     /// <summary>  11:     /// Attached Dependency Property for the IsRounded property  12:     /// </summary>  13:     public static readonly DependencyProperty IsRoundedProperty = DependencyProperty.RegisterAttached(  14:         "IsRounded",  15:         typeof(bool),  16:         typeof(RoundCaps),  17:         new PropertyMetadata(false, IsRoundedChanged));  18:    19:     /// <summary>  20:     /// Attached Dependency Property for the RoundCapsRatio property  21:     /// </summary>  22:     public static readonly DependencyProperty RoundCapsRatioProperty = DependencyProperty.RegisterAttached(  23:         "RoundCapsRatio",  24:         typeof(double),  25:         typeof(RoundCaps),  26:         new PropertyMetadata(0.5, RoundCapsRatioChanged));  27:    28:     /// <summary>  29:     /// Gets a value indicating if the Rectangle is rounded.  30:     /// </summary>  31:     /// <param name="d">The rectangle.</param>  32:     /// <returns>true if the rectangle is rounded, else false</returns>  33:     public static bool GetIsRounded(DependencyObject rectangle)  34:     {  35:         return (bool)rectangle.GetValue(IsRoundedProperty);  36:     }  37:    38:     /// <summary>  39:     /// Sets a value indicating if the Rectangle is rounded.  40:     /// </summary>  41:     /// <param name="rectangle">The rectangle.</param>  42:     /// <param name="value">true if the rectangle is rounded, else false.</param>  43:     public static void SetIsRounded(DependencyObject rectangle, object value)  44:     {  45:         rectangle.SetValue(IsRoundedProperty, value);  46:     }  47:    48:     /// <summary>  49:     /// Gets the roundedness ratio of the rectangle.  50:     /// </summary>  51:     /// <param name="rectangle">The ratio, relative to the lesser value of the rectangle's height and width.</param>  52:     /// <returns>The ratio currently applied when calculating the roundedness</returns>  53:     public static double GetRoundCapsRatio(DependencyObject rectangle)  54:     {  55:         return (double)rectangle.GetValue(RoundCapsRatioProperty);  56:     }  57:    58:     /// <summary>  59:     /// Sets the roundedness ratio of the rectangle.  60:     /// </summary>  61:     /// <param name="rectangle">The ratio, relative to the lesser value of the rectangle's height and width.</param>  62:     /// <returns>The ratio to be applied when calculating the roundedness</returns>  63:     public static void SetRoundCapsRatio(DependencyObject d, object value)  64:     {  65:         d.SetValue(RoundCapsRatioProperty, value);  66:     }  67:    68:     private static void IsRoundedChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)  69:     {  70:         Rectangle rect = d as Rectangle;  71:         if (null == d)  72:             return;  73:    74:         bool isRounded = (bool)e.NewValue == true;  75:         if (isRounded)  76:         {  77:             rect.SizeChanged += RectSizeChanged;  78:             UpdateRectangle(rect);  79:         }  80:         else  81:         {  82:             rect.SizeChanged -= RectSizeChanged;  83:         }  84:     }  85:    86:     private static void RoundCapsRatioChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)  87:     {  88:         Rectangle rect = d as Rectangle;  89:         if (null == rect)  90:         {  91:             return;  92:         }  93:    94:         UpdateRectangle(rect);  95:     }  96:    97:     private static void RectSizeChanged(object sender, SizeChangedEventArgs e)  98:     {  99:         Rectangle rect = sender as Rectangle; 100:         if (null == rect) 101:         { 102:             return; 103:         } 104:   105:         UpdateRectangle(rect); 106:     } 107:   108:     private static void UpdateRectangle(Rectangle rect) 109:     { 110:         double ratio = (double)rect.GetValue(RoundCapsRatioProperty); 111:   112:         rect.RadiusX = Math.Min(rect.ActualHeight, rect.ActualWidth) * ratio; 113:         rect.RadiusY = rect.RadiusX; 114:     } 115: }

This is how the XAML looks (without the RoundedRatio property which defaults to 0.5 anyway):

This approach works nicely at both run time and design time (1 point each) and is fully scalable (1 point). Given the awkwardness of the other approaches I’ve tried, this is the winning solution so far.

Here are the two other approaches I’ve tried that didn’t fare so well.

Value Converter: 1 Out Of 4

One approach was to bind the RadiusX and RadiusY properties of the rectangle to itself and use an IValueConverter to calculate the values based off the height and width of the rectangle. In case you’re interested, here is the code for the value converter:

   1: public class RatioConverter : IValueConverter   2: {   3:     4:     public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)   5:     {   6:         FrameworkElement element = (FrameworkElement)value;   7:         double height = element.ActualHeight;   8:         double number = height;   9:         double ratio = double.Parse((string)parameter);  10:         return number * ratio;  11:     }  12:    13:     public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)  14:     {  15:         throw new NotSupportedException();  16:     }  17: }

The converter doesn’t work at all at run time because it evaluates during the Measure and Arrange cycle for the visual tree, which means that ActualHeight and ActualWidth haven’t actually been calculated and are still 0. I will give it half a point because if I explicitly set the height rather than use “Auto” it does work; but having to explicitly set the height is not good if I’m using this approach inside a resizable Button’s control template.

I will also give it 0.5 for working in Blend – almost. Again, if I explicitly set the height it works in Blend. Blend does somehow manage to apply it correctly for Auto height but only when I build the project (no extra points).

I tried a couple of variations around this, such as binding against the width and height of a sibling element (or cousin) but it started getting a little bit ridiculous and the code-smell was pretty terrible.

Attached Behavior: The Wrong 3 Out Of 4

Another thing I tried was writing an attached behavior for a Rectangle that would automatically set the corner radius values based on the dimensions of the rectangle. That works fine for a running application, but behaviors don't execute in Blend, so the design-time experience is ruined since the corners remain square.

This is the code for the behavior:

   1: public class RoundCapsBehavior : Behavior<Rectangle>   2: {   3:     public static readonly DependencyProperty RoundedRatioProperty = DependencyProperty.Register(   4:         "RoundedRatio", typeof(double), typeof(RoundCapsBehavior), new PropertyMetadata(0.5, RoundedRatioChanged));   5:     6:     public double RoundedRatio   7:     {   8:         get { return (double)this.GetValue(RoundedRatioProperty); }   9:         set { this.SetValue(RoundedRatioProperty, value); }  10:     }  11:    12:     protected override void OnAttached()  13:     {  14:         base.OnAttached();  15:         this.AssociatedObject.SizeChanged += AssociatedObjectSizeChanged;  16:     }  17:    18:     protected override void OnDetaching()  19:     {  20:         base.OnDetaching();  21:         this.AssociatedObject.SizeChanged -= AssociatedObjectSizeChanged;  22:     }  23:    24:     void AssociatedObjectSizeChanged(object sender, SizeChangedEventArgs e)  25:     {  26:         this.UpdateRadiusXY();  27:     }  28:    29:     private void UpdateRadiusXY()  30:     {  31:         this.AssociatedObject.RadiusX =  32:             Math.Min(this.AssociatedObject.ActualHeight, this.AssociatedObject.ActualWidth)  33:             * this.RoundedRatio;  34:         this.AssociatedObject.RadiusY = this.AssociatedObject.RadiusX;  35:     }  36:    37:     private static void RoundedRatioChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)  38:     {  39:         RoundCapsBehavior behavior = d as RoundCapsBehavior;  40:         if (null == behavior)  41:             return;  42:         behavior.UpdateRadiusXY();  43:     }  44: }

It’s pretty simple – it just attaches a handler to the SizeChanged event and recalculates the corners when the event fires. It uses a property on the behavior that you can change the ratio with; the default 0.5 so the radius values will be half the height or width (whichever is larger).

It gets 1 point for working perfectly at run time, and 1 point for being scalable. It also gets the bonus point for not requiring any direct editing of the XAML, which gives it 3 out of 4, but one of those 3 was optional and it missed the third required point.

This one is probably the most frustrating because it feels like it should work. Behaviors, after all, were created as a convenience for the design surface – attached properties can do everything a behavior can – but the OnAttached and OnDetached methods are not called when the behaviors are used inside Blend.

Summary

So the Attached Dependency Property is currently winning the race, and unless someone comes up with a better solution, it will be the method-of-choice for the radio button style at the top. I just wish that Blend exposed a visual mechanism for adding custom attached properties to elements. Attached Behaviors were meant to give us that, but the OnAttached and OnDetached don’t get called so the behavior is not applied in the design surface.

A Chrome and Glass Theme - Part 7

noreply@blogger.com (Phil Middlemiss) — Mon, 07 Jun 2010 06:47:00 +0000

This is part 7 of an ongoing series on building a Silverlight theme for use in Blend 3 (I'll move it over to Blend 4 when it's no longer a Release Candidate). The first post in the theme can be found here. If you haven't done much styling of controls before then I recommend you start there since it introduces practices to keep your styles manageable.

This far in the series, I'm focusing on specific parts of the more complex controls.

In this post, we are branching out into the Silverlight Toolkit to style the Accordian control; here it is in the finished Chrome and Glass style:

You can grab the source here.

There are three control templates that we need to customize for this control: the main Accordian template, the AccordianItem template, and the AccordianButton template. You can probably guess that this control inherits from ItemsControl, hence the AccordianItem template which is the ItemContainerStyle from the ItemsControl.

Blend does not play nicely with this control and it can be a little awkward changing styles. I recommend you create the template resources inside the MainPage.xaml while you edit them and then when you are finished, move them into the resource dictionary. This will help, but you will still need to frequently run the Silverlight app to see what your changes look like.

The Accordian Control Template
As you can see, the main control template is fairly simple; basically just a ScrollViewer and an ItemsPresenter.

After creating the "AccordianChromeStyle" resource, I had to reset the margins to 0, the width and height to Auto, and the horizontal and vertical alignment to Stretch. I've then set the BorderBrush on the template style to the "ChromeBorder" resource brush, and set the Foreground brush to white.

Back inside the template, I've set the CornerRadius on the Border control to 5, to stay consistent with the rest of our theme. I've also added a margin of 2 to all edges of the ScrollViewer control to give a little space around the edges of the items in accordian.

The Accordian Item Control Template
It pays to create some dummy (or actual) AccordianItem elements before styling this template. You can add these by right clicking the Accordian control and selecting the "Add AccordianItem" menu. Then add some controls inside the Accordian Items.

I called the "Generated Item Container" resource the "AccordianItemChromeStyle" - this template too is fairly simple. The two elements of importance are the ExpanderButton and ExpanderSite elements; their names making obvious their functions.

You may have some trouble here getting the Accordian to behave properly inside Blend - it doesn't always expand correctly to show you the active accordian item.

On the AccordianItemChromeStyle style resource I have set the Background and BorderBrush both to "No brush". Inside the template I've removed the template-bound Background brush from the top level Grid element and instead put it on the "Background" Border element. I did this because I've also set the corner radius on the Border element to 8 (the default was 1), and the Grid doesn't support rounded corners. This means that if I decide to give the template a background color (instead of "No brush") then there won't be any square corners poking out around the rounded border.

You can ignore the ExpanderButton and ExpandSite elements. The ExpandSite element doesn't need to be customized (it's essentially just a content control), and the ExpanderButton custom template should be customized from the main control, rather than the AccordianItem template.

The Accordian Button Control Template
The Expander button is the workhorse of the Accordian control (at least, visually) and has the largest template. The template to the left shows an extra Border element called "Darkening" that I added to the default template - other than that, the layout is the same.

On the style resource itself, I've set the Background to the "ChromeGlassFill" resource brush. Inside the template I've set the "ExpandedBackground" Border element's Background brush to the ChromeFill resource brush, and the "Darkening" Border element's Background to the "ChromeDarkeningLinear" resource to provide a little more contrast behind the white foreground text of the button. The "Darkening" element has its Opacity set to 0% since it will only be made visible in the "Expanded" state. I've also set the CornerRadius of those two Border elements, and the "MouseOverBackground" Border element, to 3. The "MouseOverBackground" also has it's Background brush set to the "ChromeDarkeningLinear" resource.

The only other changes to the default template are the "arrow" shape has its Stroke changed to black, and the "header" element has it's Vertical Alignment set to Stretch and it's top and bottom margins set to 6 and 0 respectively.

The AccordianButton template has quite a few State groups. I have ignored the ExpandDirectionStates - which causes the headings to expand from one of the four edges - because the ChromeBackground brush doesn't look any good when stretched vertically so I'm not supporting the "Left" and "Right" expand directions in this style, and the "Top" and "Bottom" states work just fine as they are.

The ExpansionStates contains the "Collapsed" and "Expanded" states; the "Expanded" state effectively being the "selected" state. As mentioned earlier, I show the "Darkening" element in this state to provide extra contrast. There is also a "CheckStates" group, since the AccordianButton inherits from the ToggleButton, but these states are ignored by the Accordian.

I've made one or two other small changes to the states, so grab the source and have a dig around inside.

Separating Content and Presentation with the ContentControl

noreply@blogger.com (Phil Middlemiss) — Wed, 26 May 2010 19:41:00 +0000

The ContentControl is often overlooked when building Silverlight apps. It’s used inside many controls such as the Button or ChildWindow, but it also turns out to be quite useful on it’s own for separating content from presentation.

Here is a sample of the technique I will be describing. The buttons swap between two completely different “themes” for the same UserControl but the XAML for the UserControl doesn’t contain any theme elements at all, just layout and content. It’s not Picasso, but it will do to illustrate the concept:

You can grab the source files and read my full article on Silverlight Show here.

Backlighting a ListBox

noreply@blogger.com (Phil Middlemiss) — Tue, 25 May 2010 06:25:00 +0000

This little Silverlight sample is purely to satisfy my curiosity. I was styling a list box the other day and wondered if it would be possible to simulate backlighting on a selected list box item. The kind of thing you see on a game-show scoreboard where the current dollar value is lit up and casts reflected light over its surroundings. The bit I wondered about was getting a list box item to escape it's boundaries to light up the area around it.

It's completely unrelated to anything I am currently working on (or ever likely to for that matter), but it was something I wanted to do and that is as good a reason for doing it as any!

Here is the finished result and I'll explain how it's done below (try it full screen with the button in the top right corner):

You can grab the source here.

The challenging bit was getting the selected item in the list box to cast a glow on the things around it. The glow seems to escape the list box itself. The reason this wasn't straight forward is that the ListBox control clips its content to keep everything inside the scrollable area. My first instinct was just to set negative margins on something inside the ListBoxItem's template (ItemContainerStyle), but that's when it became obvious that it was being clipped.

So how did I do it? By diving into the ListBox's control template, and then into the ScrollViewer control's template (inside the ListBox control's template) and setting negative margins on the ScrollContentPresenter there. This effectively increases the area the ListBox requires. I then adjusted the ListBoxItem's control template, by setting the margins of the parent Grid to adjust to the extra room in the margin. Here's the steps.

Step 1
I'm assuming you have created a list box. Select it, right click it and select "Edit Template" and "Edit a Copy...". Expand the object tree and find the ScrollViewer element. Right click the ScrollViewer and use the same menu items to edit a copy of the ScrollViewer's control template.

Locate the ScrollContentPresenter element in the object tree view and select it. We need to change its margins, but first use the Advanced Property Options menu (the little yellow box next to the margin boxes) to "Reset" the existing margins, which are bound to the parent style. Once they are reset, change them to -ve values. In my example, I have set all the margins -10.

Step 2
Use the breadcrumb toolbar to exit editing the templates, back out to the main page again. Right click the ListBox and select "Edit Additional Templates" and "Edit Generated Item Container (ItemContainerStyle)" and "Edit a Copy...". This is the control template for the container that will hold each list box item.

At this point you create whatever elements you want in order to create the look you are after. You will have to work out which parts of the template you don't want encroaching into the extra space created by the -ve margins, and increase their margins by the appropriate amount.

In the example above, I have set the top margin of the top level Grid to -10, and the bottom margin set to 10. This counters the -ve top and bottom margins we set on the ScrollContentPresenter and makes the list box items drop back down into the list box area.

Then I've created a child Grid that contains all the elements that are visible when the list box item is not selected. I've set the left and right margins to 10 for those items so they don't poke out the side of the list box.

I've also created a child Grid for the elements that are only visible in the Selected state. That grid has -ve top and bottom margins to counter the values I set on the parent Grid. The items in this child grid will use up the extra 10px all around the list box item. The image to the left show the boundaries of this child grid (the items themselves are hidden).

Step 3
You may have noticed that the list box item elements that extend out of the ListBox now appear over the top of the ListBox border. To fix this, go back into the ListBox control template and drag the ScrollViewer control above it's parent Border. This should make them siblings, with the border just below the ScrollViewer (items lower in the object tree are rendered above items higher up in the object tree). Now the border should render over the top of the list box items.

Other Points of Interest

When you are adding elements that use the extra space from the -ve margins, it will look like every list box item is overlapping, but you should only be allowing the overlap for the items that will show in the Selected state so only one will end up showing at a time (assuming you leave the SelectionMode at "Single"). It may help to select the Selected state and turn off recording by clicking the red light in the top left corner of the design area. Don't forget to turn it back on when you are ready to record again.
The style is really only for a list box that can show all it's items without scrolling. I completely turned off the scroll bars for the list box since it would just get in the way. I wanted to achieve something very specific and was not interested in creating a style that I could reuse over and over again for any number of items (of any size) in the list.
I used a PNG image for the opacity mask for the glow that escapes the ListBox. The linear and radial gradients couldn't give the right shape I was after for the feathered edges.
The rest of the visual content is just bling really, and is only there to make the whole thing make sense. Without it I think the example would be a lot less interesting.

So grab the source and have a play. Leave a comment if you like it!

A Chrome and Glass Theme - Part 6

noreply@blogger.com (Phil Middlemiss) — Mon, 10 May 2010 09:52:00 +0000

This is the 6th in a series on creating a "Chrome and Glass" Silverlight theme in Expression Blend. The purpose of the theme is to look at all the common controls and point out any interesting or difficult aspects of styling their templates. If you haven't styled many controls before then I recommend you begin with the first post in the series.

This post is about the TabControl. The TabControl is a control I have not been looking forward to writing about. Not because it's boring, but because it is tedious to style unless you only ever want your tabs on one side. The TabControl's control template is really 4 different templates rolled into one; one template for each edge of the TabControl. You use the TabControl.TabStripPlacement property to position the tabs on any of the four sides. Actually it's five control templates if you include the control template for the TabItem (which you should).

Here is a the Chrome and Glass styling of the control:

You can grab the source here. I used a slightly different approach to styling this control - I saved the custom control templates "TabControlChromeStyle" and "TabItemChromeStyle" in the same page as the tab control itself (MainPage.xaml) and then cut and paste it into the ChromeGlass.xaml resource dictionary when I was finished. This makes things just a little bit easier for styling since you are editing the style in-place and it retains the context of the controls you have placed inside it. I would recommend this approach for the TabControl, otherwise you will be styling blind and unable to see the effect of most of the changes you make.

I've only styled two of the four placement options: the top or the bottom. This isn't laziness - it's a valid design decision (truly!). I just don't think tabs sticking out of the side works for the glass and chrome look. When the tabs are on the side they take up far too much horizontal space, and they just don't fit the concept of the theme.

Left-overs from ItemsControl
The TabControl inherits from ItemsControl, which means that it has the "Generated Items (ItemTemplate)" data template, and the "Layout of Items (ItemsPanel)" control template. Neither of these are actually used! You can create custom templates for them if you like, but they are completely ignored by the TabControl. The TabControl handles the collection of items itself and shows only one at a time, using the relevant control template part. The ItemsSource property is another property that you will probably not use unless you are going to manage a collection of TabItems yourself.

The TabControl Control Template
This is the control template for the TabControl. There is a grid for each configuration of the TabControl. The "TemplateTop" grid is made visible when the TabStripPlacement is set to "Top". You can probably figure out the other three...

All four templates follow the same theme: position a TabPanel (just a strip of tabs) and a ContentPresenter. The actual content of the tab pages is kept in the inherited Items property, managed by the TabControl. As a tab from the TabPanel is clicked, the TabControl loads the associated item into the ContentPresenter of whatever grid is being used based on the TabStripPlacement property. Unlike the ListBox, which also inherits from the ItemsControl, the TabControl isn't designed to use a single DataTemplate to show each item it manages. It is designed to have it's tabs and individual item templates created at design time.

I've changed the control template for the TabControl around a little bit (for both the "TemplateTop" and "TemplateBottom" parts). I had to do this because I wanted the selected tab to look like it was the same "piece" as the content area. The default template had the border around the content so there was a line separating the tab from the content. Taking the "TemplateTop" as an example, I've grouped the "TabPanelTop" element into a grid with three columns. The TabPanelTop is in the middle column, and the two side columns have Border controls configured to show lines joining the bottom of the outside tabs to the border around the page content.

The TabItem Control Template
The TabItem template (shown on the right) is the more complex one, and the more tedious one. It contains the template that determines how the actual tab looks (the bit that sticks out). It contains two templates for each position the tabs can be located: one for when the tab is selected, and one for when the tab is unselected. That's a total of 8 templates to style! (unless of course you make the brilliant design decision that you only want one or two positions to be used in your style).

The changes I've made to the TabItem template are to reduce the number of Border controls and to get rid of the gradients and solid fills for the remaining elements. The only background fill is used for the unselected tabs.

The other changes I made were to the states; instead of graying out the whole control I've made them partially transparent. This follows the pattern I've been using for similar controls already completed in the theme.

The TabItem Control Template
One last thing about the TabControl is that it is a pain to style in Blend because the compiled code for the control interferes with normal Blend behavior. For example, if you are editing the TabItem template and use the eye icon in the Object tree to hide or show an element, Blend doesn't always restore the view of the item. The same can happen if you change Visibility between Visible and Collapsed. To make things appear properly again you have to exit out of editing the template, then go back in.

So grab the solution and have a play! Leave a comment if you like it (or if you hate it - or anything in between).

Quick and Easy Scalable Rounded Bevels

noreply@blogger.com (Phil Middlemiss) — Thu, 06 May 2010 20:06:00 +0000

Too Much Photoshop
I was watching a UI design video yesterday where the presenter imported a Photoshop design into Blend and turned it into a Silverlight GUI. One thing I noticed was that he kept a lot of the raster layers from the Photoshop image as graphical elements inside the Silverlight app. If you have a carefully crafted design that uses filters and effects that aren't available in Blend then you have no choice if you want to retain the fidelity of the design mock-up. That usually means, though, that the Silverlight app is going to be at a fixed width/height to match the Photoshop design - since raster graphics don't usually scale well.

I don't like fixed width and height Silverlight apps. I kept thinking "there must be a way to do that in nothing but XAML". Some of the graphics were understandably left as raster since there would be no equivalent way to achieve the same result in Blend. But the elements that bothered me were usually simple panels or buttons that had a common visual theme - they had rounded corners, and they had some kind of bevel that made them appear raised or lowered. This is the sort of thing I mean:

Let's pretend it was a proof done in Photoshop (it was actually an old copy of Paint Shop Pro) and we brought it into Blend. The gradients are easy enough to do in Blend, but what about the shading around the edges of the buttons and panel, giving them a raised appearance?

A lot of the button styles that I've seen people blog about tend to follow 2 or 3 themes: glassy styles with inner glows and highlights; ellipses with radial gradients; or linear gradients. These buttons are either all elliptical buttons, or they don't bother trying to give rounded shading at the edges like the image above.

The problem is the corners. If it weren't for the rounded corners on those rectangles, you could just use thin rectangles hard up against each edge with an appropriate linear gradient. But even then you run into difficulty at the corners where those rectangles meet. There's no easy way to make the gradients from each edge's rectangle meet smoothly.

You could probably do it on a fixed size button with paths shaped specifically for the corners and edges, but then it wouldn't scale well.

This got me thinking about how to achieve the kind of look in the top image, in a way that scales to any kind of size, or roundedness. While the method described below doesn't have the flexibility of the filters and effects that you find in Photoshop, it is a fairly good approximation, and is easy to achieve.

Fuzzy Borders
The approach I came up with is to use Border controls with two sides missing, and the Blur effect applied to make it fuzzy. Here is a working example:

The idea is to use a Border control with a White BorderBrush, the top and left edge thickness set to 3, and the bottom and right edge thicknesses set to 0. Then add another Border control, but with a Black BorderBrush, and the opposite edges showing. The blur effect is set at 4 and the borders are offset by 1 (using the Margin) from the edges. The Opacity of the borders is down at about 30%. That's it - just two borders on top of whatever background you want. And it scales to any size.

The example above uses the same technique for the buttons and for the panel containing the bigger buttons. The only difference in the object tree for the buttons is that there are a couple of extra rectangles to manage States (eg MouseOver, Disabled etc). The buttons swap the colors from black to white and vice-versa for the MouseDown state, and offsets the ContentPresenter element too.

Here are the object trees for the panel and for the button:

You can see that I have copied the elements from the button template into the grid on the right to be used as a panel (should have renamed the element "PanelBorder" instead of "ButtonBorder").

You could also use this as a Control Template for a ContentControl and have a nice reusable 3D panel style.

Here are the files in case you want to play with it.

A Chrome and Glass Theme - Part 5

noreply@blogger.com (Phil Middlemiss) — Sun, 02 May 2010 01:35:00 +0000

This is the fifth in an on-going series on creating a theme that you can use in Silverlight 3 or 4 (eventually).

If you haven't been following along and want to learn the techniques then it is best to start at the beginning with Part 1 here.

By now you should be pretty comfortable with editing control templates so I won't give step by step instructions except for techniques I haven't covered, or for tricky template parts.

In this post we are going to have a look at the ProgressBar and Slider controls. This is what the final result will look like:

You can grab the files here.

The ProgressBar Control
The control template for the ProgressBar control looks like this:
The red circle is around the Control Part icon. That icon indicates that the control expects there to be an element in the template called "ProgressBarTrack", and it usually has to be a control of the same type as is used in the default control template - in this case a Border control for "ProgressBarTrack" and a Rectangle element for "ProgressBarIndicator".

A Control Part is critical to a control - the compiled code that manipulates the visual elements expects to find those named parts and won't work without them. Fortunately their names indicate what they do. "ProgressBarTrack" is obviously the track that the progress runs along and "ProgressBarIndicator" is the part that grows to show progress.

For the ProgressBar control, this means that we are restricted to a single Rectangle element to show the progress.

Styling the progress bar is not hard. The points that are possibly worth mentioning are:

The "ProgressBarTrack" has it's Border and Background brushes bound to the same named properties on the control (template bindings), so change these values on the style, not the "ProgressBarTrack" element. The same goes for the "ProgressBarIndicator" - its Fill brush is bound to the Foreground property on the parent control.

The "IndeterminateRoot" contains elements that are shown when the "IsIndeterminate" is set to true. The storyboard for the IndeterminateState has an animation that is set to loop Forever. I'll cover this more below.

The ProgessBar control doesn't have a Disabled state since it doesn't receive focus and is not intended to be interacted with

If you select the "Indeterminate" state you can click on the storyboard name just under the "Objects and Timeline" tab, and see its properties in the Properties panel. The RepeatBehavior for this storyboard is set to "Forever". The idea here is that when you wish to show that progress is being made but you have no way of calculating the progress (such as carrying out a time-consuming task on the server), you can set the progress bar's IsIndeterminate property to true and it will continually animate until you set it to false. For that reason, if you change the appearance of the Indeterminate state for the ProgressBar, it is advisable to keep some kind of continual animation happening.

Of course, there is no reason why you are limited to an angled gradient moving across the bar - you could instead show pixies dancing from side to side, or a conveyor belt dropping toys in a box. Go wild! The only restrictions are that the Control Parts must be kept and used to show the progress when it is not Indeterminate.

The Slider Control
The Slider control is fairly straight forward - the control template is shown on the right. Like the Scrollbar control, there is a vertical and a horizontal template. I have created a separate resource for a Thumb control and assigned it to both the HorizontalThumb and the VerticalThumb. To do this, you would carry out the following steps:

Select the HorizontalThumb element

Create a copy of its control template, saving it (for now) as "HorizontalThumbGlassStyle"

Make your changes to the thumb template

Exit the Thumb control template, back to the Slider control template

Use the Advanced Property Options button next to the "Style" property for the "HorizontalThumb" element (in the "Miscellaneous" group) to "Convert to new resource...", and saving it as "ThumbGlassStyle"

You can then delete the "HorizontalThumbGlassStyle" from the Resources tab, and assign the "ThumbGlassStyle" to the VerticalThumb's Style property.

There's one more thing to be aware of. The Thumb style resource I created for the slider has a 1 pixel gap between the border of the "Background" element and the "BackgroundGradient" element. I noticed that moving the mouse over the thumb caused the MouseOver state to quickly show, then hide, and then show again. This was because of the gap between the border and the fill - the "Background" Border element has a null brush for it's Background property. Since there was no element of the Thumb under the mouse when it was over the gap, Silverlight considered that the mouse had left the element and put the Thumb into the Normal state. To fix this, I set a solid background color for the top level grid, and set the Alpha for the color to 0. Doing this ensured that there is a solid control under the mouse in the gap, even if it is fully opaque.

A Chrome and Glass Theme - Part 4

noreply@blogger.com (Phil Middlemiss) — Mon, 26 Apr 2010 00:35:00 +0000

[UPDATED]: Fixed the links to the final source.

So back to the series on building a theme. Apart from describing the steps to style each of the controls for this particular theme, I've been trying to describe some of the techniques and knowledge that can be applied generally to any theme or style.

In part 1 we covered creating style resources in a resource dictionary.
In part 2 we covered editing control templates as part of a style, including states.
In part 3 we knocked off a couple of the easier controls to style, although we added some extra elements to the control template.

In this post, we are going to dig down into a control that is made up of a collection of other controls: the ListBox. But we are going to begin by styling the other controls that make up the ListBox. If you haven't been following along, grab the files from the end of part 3 here and load them up in Blend. This is what the final result will look like (with sample data):

Parts of a ListBox
A list box has a number of templates that it uses and it's important to get a good understanding of how it hangs together. Here is the break-down:

A list box has a control template that contains a ScrollViewer control. A ScrollView control has a control template that contains two ScrollBar controls. And the ScrollBar controls have their own template as well (which is divided up into horizontal and vertical elements).

Additionally, the ListBox uses two other templates (there is a third that is not part of the reusable style that we will discuss briefly at the end): another control Template (inside the ListBox.ItemContainerStyle) that determines what the items in the ListBox look like, and an ItemsPanelTemplate (ListBox.ItemsPanel) that determines how the items are laid out (eg horizontally, vertically etc).

When you are looking at a styled ListBox, the items in the list look the way they do because of the ListBox.ItemContainerStyle template, which is a ControlTemplate. They are laid out the way they are (usually vertically) because of the ListBox.ItemsPanel which is an ItemsPanelTemplate that contains a stack panel by default, and they are "framed" the way they are (the background, scrollbars etc) because of the ListBox.Template which is a ControlTemplate. We won't bother changing the ListBox.ItemsPanel in this post since we still want the behavior that we get with the default vertical StackPanel.

The ScrollBar
It's easy to get lost in template editing if you dig down and down through the control templates. We are going to approach things in a fairly simple-to-follow way by styling the resources we need from the innermost controls, and work our way back up to the top level control. The first control, buried deep inside the ListBox control, is a ScrollBar. Strangely enough, the ScrollBar is probably the most time consuming of the controls we will style even though it seems a simple control. You'll see why as we go along.

Drag a scroll bar onto our glassy panel - it will be vertical by default. Use the breadcrumb toolbar to edit a copy of the control tempate; call it ScrollBarChromeStyle and remember to save it in our ChromeGlass.xaml resource dictionary.

The template doesn't have any size defined, but Blend allows us to define a Design-Time only size. Select the "Root" element in the Object tree and use the bottom blue drag handle to make our scroll bar a bit taller.

If you expand the "VerticalRoot" element you will see that the scroll bar is made up from three rectangles and five controls. We are only going to need two of those rectangles, so delete the second one in the Object tree under the "VerticalRoot" grid. Set the Fill of the first Rectangle to our GlassFill resource brush, and the stroke of the second Rectangle to the "ChromeBorder" resource brush we defined in Part 1.

Select the "VerticalSmallDecrease" element - it's a RepeatButton control, as are the other small and large decrease buttons. Use the breadcrumb toolbar to edit the current control template. The Repeat button is a specialized kind of button that does not contain any content of its own (like a regular Button does), but still has button states. Select the "Background" rectangle element, change its Fill brush to the "ChromeGlass" resource brush, it's Stroke to empty, and its Opacity to 100%.

Select the "BackgroundMouseOver" Rectangle element, change its Fill to empty, and its Stroke brush to the "ChromeBorder" resource brush.

Select the "BackgroundGradient" Rectangle element, drag it up to be above the "BackgroundPressed" Rectangle in the Object tree, and change to following properties (don't worry about any warnings of animations being removed):

Set its Fill to the "ChromeFill" resource brush
Set its Stroke to the "ChromeBorder" resource brush
Set its Margin to 2 for all edges

Select the "BackgroundPressed" Rectangle element and change its Margin values to 2 for all edges. Select the "Highlight" Rectangle element and change its Margin to 0 for all edges.

Finally, select the unnamed path element and change it's foreground to White. Now to set the values for the different states.

Select the "MouseOver" state (in the "States" tab) and change the Opacity of the "Background" Rectangle to 0%. Select the "Pressed" state and set the Opacity for the "Background" element to 0%, the "BackgroundGradient" element to 100%, the "BackgroundPressed" element to 20%, and the "Highlight" element to 20%.

The good news is, that the VerticalSmallDecrease element is now styled. The bad news is, that we have to repeat this process for the VerticalSmallIncrease the HorizontalSmallDecrease, and the HorizontalSmallIncrease. Since the VerticalSmallIncrease element is essentially the same as the VerticalSmallDecrease element, I won't bother repeating the same instructions. Go ahead and follow the same instructions for the VerticalSmallIncrease RepeatButton; I'll wait for you...

...and we're back. Now lets style the "VerticalThumb" element. Select it and use the breadcrumb toolbar to edit the current template. You should see it's made up of nothing more than five Rectangle elements. Here we go (you may wish to select the top Grid element and use the Design Time size handles so you can see what the changes look like):

Change the "Background" element's Fill brush to empty, and its Stroke to the "ChromeBorder" resource.

Move the "BackgroundGradient" element up under the "Background" element, change its Fill to the "ChromeFill" resource and its Stroke to the "ChromeBorder" resource, and set its margin to 2 for all edges.

Change the "BackgroundMouseOver" element's Fill to White, its stroke to empty, and it's Margin to 2 for all edges.

Change the "Highlight" element's Margin to 0 for all edges.

Select the "MouseOver" state, and change the "BackgroundMouseOver" element's Opacity to 20%. Select the "Pressed" state and change the "BackgroundPressed" element's Opacity to 30% and the "Highlight" element's Opacity to 30%.

That's the vertical layout elements styled; now we have to do the horizontal layout elements. Normally, the easiest way to style the horizontal layout would be to click the "[scrollbar]" button on the breadcrumb trail and change the Orientation of the ScrollBar to Horizontal (you will want to resize it too), and then use the breadcrumb trail to go back into the template and expand the "HorizontalRoot" grid element.

However, at this point Blend seems determined to make things hard for us; it insists on only showing the design template for the vertical orientation regardless of the value of the Orientation property. So we are going to have to do this blind, but we will be guided by what we have done with the vertical scrollbar. You can also switch back and forth between "ChromeGlass.xaml" and "MainPage.xaml" to see the results of your changes. If we had chosen to save the template in "MainPage.xaml" instead of our resource dictionary then we would have been editing "in-place" and would be able to see our changes reflected in the design surface. We probably should have done that, and then moved the template into the resource dictionary when we had finished.

Here are the steps for the "HorizontalRoot" template:

Horizontal Root

Delete the second Rectangle element - we don't need it, there should be three left.

Set the Fill brush for the first Rectangle to the "GlassFill" resource brush.

HorizontalSmallDecrease

Select the "HorizontalSmallDecrease" element and use the breadcrumb trail to edit it's template.
Select the "Background" Rectangle element and set its Fill to the "ChromeGlassFill" resource brush, its stoke to "No brush", and its Opacity to 100%.
Select the "BackgroundMouseOver" Rectangle element and set its Fill to "No brush" and it's Stroke to the "ChromeBorder" resource brush.
Select the "BackgroundPressed" Rectangle element and set its Margin to 2 for all edges.
Select the "BackgroundGradient" Rectangle, drag it up in the Objects tree to be above the BackgroundPressed Rectangle, set its Fill to the "ChromeFill" resource brush, its Stroke to the "ChromeBorder" resource brush, and it's Margin to 2 for all edges.
Select the "MouseOver" state and set the Opacity of the "Background" Rectangle to 0%, the "BackgroundMouseOver" Rectangle to 100%, and the "BackgroundGradient" Rectangle to 100%.
Select the "Pressed" state and set the Opacity of the "Background" Rectangle to 0%, the "BackgroundGradient" Rectangle to 100%, the "BackgroundPressed" Rectangle to 20%, and the "Highlight" Rectangle to 30%.
Select the "Highlight" Rectangle element and set its Margin to 0 for all edges.
Select the "[Path]" element and set it's Fill to a solid white color.

HorizontalSmallIncrease
Use the breadcrumb trail to go back out to the scrollbar template, select the "HorizontalSmallIncrease" element. For some strange reason, this one template is implemented differently by default than the other 3 small increase RepeatButton elements in the ScrollBar template. There is no "BackgroundPressed" Rectangle element, so select the "BackgroundGradient" Rectangle, press Ctrl+C followed by Ctrl+V to create a copy, select the copy, click its name once and rename it to "BackgroundPressed". Drag it up so it sits just below the "BackgroundGradient" Rectangle, and set its Fill to a solid color with the value "#FF448DCA", its stroke to "#00000000", and its margin to 2 for all edges. Also change the name of the "BackgroundAnimation" Rectangle to "BackgroundMouseOver". You can now follow the same steps as for the "HorizontalSmallDecrease" element, with one additional step: in the "Pressed" state, you will have to set the Opacity for the (now named) "BackgroundMouseOver" element to 0%.

HorizontalThumb
You can follow the same steps for the "VerticalThumb" element to style the "HorizontalThumb".

That's the hard work done, the rest of the ListBox template styling goes quickly now.

The ScrollViewer
Go back out to MainPage.xaml design surface and place a ScrollViewer control inside the grid containing our other controls. The ScrollViewer isn't available on the control toolbar fly-outs so you can either use the ">>" chevron at the bottom of the toolbar to list all controls and find the ScrollViewer in there, or you can select the "Assets" tab and enter "scroll" into the search box and Blend will filter all available controls that contain the search term:

Once you have created the scroll viewer, use the breadcrumb trail to edit a copy of its template, saving it as "ScrollViewerChromeStyle" in the "ChromeGlass.xaml" resource dictionary.

The only thing we need to change in the template is the style of the scroll bars. We can do that by right-clicking the VerticalScrollBar element, and selecting "Edit Template" | "Apply Resource" | "ScrollBarChromeStyle". Do the same to the HorizontalScrollBar. Now select the "[Rectangle]" element and delete it. That's it for the template, we just need to set the border brush on the style resource.

Click the artist's palette on the breadcrumb toolbar to edit the style of the ScrollViewer and change it's Border to the "ChromeBorder" resource brush. We also want to have the inside of the ScrollViewer subtly differentiated from the outside of it so set its Background brush to a "#26000000" Solid brush. The style may show the foreground as Black, but since we have applied a White Foreground to our UserControl, the foreground will default to White when we actually use the control in our MainPage.xaml.

That's the ScrollViewer done. Here is what it looks like on our main page, with a couple of Scrollbars too:

We could have used the "GlassFill" resource brush for the background of the scrollable area, but the ScrollViewer is going to be used in the ListBox template, and the angled shine of the Glassfill brush would end up looking odd with multiple ListBox elements of different sizes on the same screen, since the shine would be at different angles depending on the size of the ListBox.

The Listbox Control Template
Finally, we get to the ListBox control. There are two templates we need to edit here, the control template for the ListBox, and the ListBoxItem template that will hold each item in the ListBox.

You can delete the ScrollViewer control on the MainPage.xaml screen and replace it with a ListBox control. Create a new resource template for the ListBox called "ListBoxChromeStyle" in the "ChromeGlass" resource dictionary.

Expand the template in the Objects tree and right click the "ScrollViewer" element. Select "Edit Template" | "Apply Resource" | "ScrollViewerChromeStyle". You will see that the background is still white from the default template because the Background brush is template-bound to the parent Background brush for the ListBox control. We could reset the Background brush for the ScrollViewer, but that would mean that any changes we make to the Background brush would be ignored for individual ListBox controls that use this style. So select the artists palette on the Breadcrumb toolbar for the actual Style of the ListBox and set the Background to a solid color of "#22000000" - the same that we used for the ScrollViewer style template. The Border brush of the "[Border]" element in the ListBox template is also template-bound to the style, so change the style's BorderBrush to the "ChromeBorder" resource brush. The Foreground color of the parent control is not passed onto child ListBoxItems, so set the Foreground of the ListBox style to white.

That's the main chrome of the ListBox done, so now lets do the ItemContainerStyle.

The ItemContainerStyle
Go back out to the MainPage.xaml view and select the ListBox. Use the breadcrumb trail to edit, under "Edit Additional Templates", a new copy of the "Generated Item Container". Call it "ListBoxItemChromeStyle" and save it in the resource dictionary.

Select the "fillColor" Rectangle element and change its Fill the the "ChromeGlassFill" resource brush. Select the "fillColor2" Rectangle element and change its Fill also to the "ChromeGlassFill" resource brush, and it's Stroke to the "ChromeBorder" resource brush. Select all three Rectangle elements by holding Ctrl and clicking on each one, and change the RadiusX and RadiusY values to 3.

Now select the "MouseOver" State, and set the Opacity of the "fillColor" Rectangle to 50%. Select the "Focused" State and set the Opacity of the "FocusVisualElement" Rectangle to 30%. Select the "Selected" State and set the Opacity of the "fillColor2" Rectangle to 100%. Finally, select the "Disabled" State, delete the Opacity adjustment for the "contentPresenter" element and set the Opacity of the "grid" element to 55%.

One thing that has always annoyed me about the list box is that the default template for the ListBoxItem has the HorizontalAlignment set to Left - which means that the selected item highlight doesn't stretch across the whole ListBox. To change this, select the "contentPresenter" element and use the Advanced Property Options box to reset it's HorizontalAlignment, and then change it to Stretch instead of Left.

That was the last part of the reusable ListBox template that we needed to style, but there is one more thing to do. Currently, the ListBox control that we created has its "ItemContainerStyle" property set to the "ListBoxItemChromeStyle" resource that we just created. But we really want this to be set on the "ListBoxChromeStyle" style resource rather than on the ListBox itself. So select the ListBox, and from the "Object" menu, select "Edit Style" | "Edit Current" to edit the "ListBoxChromeStyle" resource. Expand the "Miscellaneous" group heading and, from the advanced property options box on the right hand side of the "ItemContainerStyle" property, select the local resource "ListBoxItemChromeStyle". Finally, exit out of editing the template and, back on the ListBox itself, use the advanced property options to reset the value of the ListBox's "ItemContainerStyle" property. So now, whenever we use our "ListBoxChromeStyle" resource, it comes already connected to the "ListBoxItemChromeStyle" resource.

That is the last thing we needed to do to our ListBox style, so now lets add some sample data to test it with.

Adding Sample Data
Blend has built in functionality to create sample data that we can use when designing our layouts to test how those layouts work with actual data.

Select the "Data" tab and click the "Add sample data source" button. Select the "Define New Sample Data..." option and accept the default Data source name "SampleDataSource", creating it in the Project, not the Document.

Blend will have created two fields for you by default. You can use the little arrow on the right edge of the property to change what kind of sample data is generated. Rename the two fields "Name" and "Company" and add a third one named "Image". Use the "Change Property type" arrows to select the right kind of data to be generated for each field.

To bind the generated data to your ListBox, click and drag the "Collection" item in the SampleDataSource tree onto the ListBox. Blend will automatically create a data template for it and show the data stacked vertically in a StackPanel control, but we're going to change that now.

Editing the ItemTemplate
The last template is the Listbox.ItemTemplate. It is a DataTemplate that will be applied to the data inside each ListItemBox. It has nothing to do with our reusable "ListBoxChromeStyle" resource, and is something that you customize specifically for each ListBox you use. I'm covering it briefly here just for the sake of putting all the ListBox templates in context.

Use the Breadcrumb toolbar to edit the current "Generated Items (ItemTemplate)". I'm not going to give any instructions on what to do here since it is unrelated to our style sheet. Just find a nice layout for the items that are there, or grab my one using the link at the end of this post. You will notice that you are editing this template "in-place" since it was created inside the MainPage.xaml file, rather than the resource dictionary.

So here are the things we have covered in this post:

It's easier, with complex controls, to style the child controls that it uses first.
The different templates that make up the list box and how they relate to each other.
How to create reusable styles and templates for each of them.
The ListBox.ItemTemplate is specific to each instance of a ListBox, so it's not part of our resource dictionary.

You can grab the final solution files here.

Changing Data-Templates at run-time from the VM

noreply@blogger.com (Phil Middlemiss) — Thu, 08 Apr 2010 06:42:00 +0000

[Updated – Fixed code samples]

What do you do when you have a list box or data grid that has a collection of items to display - but some items need to be presented differently than others? For example, I may have a collection of company staff members to display in a single ListBox, but the managerial staff need to have extra information displayed (they always do!), and each level is styled slightly differently like this for example:

In this post I'll describe a technique I have used successfully before - I'll stick with the list of staff example above to illustrate the solution, but the class types are going to be a little contrived for the sake of simplicity.

The Data

Lets define a StaffMember class like this:

   1: public enum StaffRoleType { Manager, MiddleManager, LowerManager, Pleb, Contractor }   2:     3: public enum CoffeeType { Espresso, Cappuccino, HotChocolate, Other }   4:     5: public class StaffMemeber     6: {   7:     public string Title { get; set; }   8:     public string FirstName { get; set; }   9:     public string LastName { get; set; }  10:     public StaffRoleType StaffRole { get; set; }  11:     public CoffeeType CoffeeType { get; set; }  12:     public Color FavouriteColor { get; set; }  13:     public string CarType { get; set; }  14: }

The StaffRoleType will be used to differentiate the managers from the plebs so we can display the really important information for managers like what kind of coffee they drink and what their favourite color is. If this was real code we might have a different class for each role type, and they would all implement the INotifyPropertyChanged interface. But that class will do for demonstration purposes.

Different Data = Different Data Templates

A nice way to solve this problem would be if we could somehow use different data templates to display each type of staff- but do this inside the existing controls like a ListBox. Ideally we could use Blend to design these different data types too. Of course, the ListBox doesn't let us define more than one data template for the ListBoxItem; but rather than try and rewrite the ListBox, we can achieve our goals with a couple of simple additions to the ContentControl:

   1: using System.Collections.ObjectModel;   2: using System.Linq;   3: using System.Windows;   4: using System.Windows.Controls;   5: public class SelectableContentControl : ContentControl   6: {   7:   public static readonly DependencyProperty TemplateNameProperty = DependencyProperty.Register(   8:      "TemplateName",   9:      typeof(string),  10:      typeof(SelectableContentControl),  11:      new PropertyMetadata(string.Empty, TemplateNameChanged));  12:     13:   private readonly ObservableCollection<DataTemplate> templateCollection = new ObservableCollection<DataTemplate>();  14:     15:   /// <summary>  16:   /// Gets the collection of templates  17:   /// </summary>  18:   public ObservableCollection<DataTemplate> Templates  19:   {  20:      get  21:      {  22:          return this.templateCollection;  23:      }  24:   }  25:     26:   /// <summary>  27:   /// Gets or sets the name of the template to use  28:   /// </summary>  29:   public string TemplateName  30:   {  31:      get  32:      {  33:          return (string)GetValue(TemplateNameProperty);  34:      }  35:     36:      set  37:      {  38:          SetValue(TemplateNameProperty, value);  39:      }  40:   }  41:     42:   /// <summary>  43:   /// Select the appropriate DataTemplate when the Content changes.  44:   /// </summary>  45:   /// <param name="oldContent">The old Content value.</param>  46:   /// <param name="newContent">The new Content value.</param>  47:   protected override void OnContentChanged(object oldContent, object newContent)  48:   {  49:      base.OnContentChanged(oldContent, newContent);  50:      this.SelectTemplate();  51:   }  52:     53:   private static void TemplateNameChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)  54:   {  55:      ((SelectableContentControl)d).SelectTemplate();  56:   }  57:     58:   private void SelectTemplate()  59:   {  60:      if (!string.IsNullOrEmpty(this.TemplateName))  61:      {  62:          DataTemplate namedTemplate =  63:              this.Templates.FirstOrDefault(  64:                  t => t.GetValue(FrameworkElement.NameProperty).Equals(this.TemplateName));  65:          if (null != namedTemplate)  66:          {  67:              this.ContentTemplate = namedTemplate;  68:              return;  69:          }  70:      }  71:     72:      // default to the first template  73:      if (this.Templates.Count > 0)  74:      {  75:          this.ContentTemplate = this.Templates[0];  76:      }  77:   }  78: }

The new control has two key properties:

Templates - an ObservableCollection of DataTemplate
TemplateName - a string representing the name of the template to choose.

The Templates property allows us to declare multiple DataTemplates in the XAML, and the TemplateName property allows us to bind to a property on the data to select which template to use. If we had multiple class types in our list, such as a Manager class etc, then we could bind on the ClassName, or even the class itself with a value converter.

This is what the XAML for a ListBox may look like:

   1: <ListBox ItemsSource="{Binding StaffList}" >   2:     <ListBox.ItemTemplate>   3:         <ss:SelectableContentControl TemplateName="{Binding StaffRole}" Content="{Binding}">   4:             <ss:SelectableContentControl.Templates>   5:     6:                 <!-- default for unmatched StaffRoleType values -->   7:                 <DataTemplate>   8:                     <local:PlebianUC />   9:                 </DataTemplate>  10:    11:                 <!-- Contractor template -->  12:                 <DataTemplate x:Name="Contractor">  13:                     <local:ContractorUC />  14:                 </DataTemplate>  15:    16:                 <!-- Contractor template -->  17:                 <DataTemplate x:Name="MiddleManager">  18:                     <local:MiddleManagerUC />  19:                 </DataTemplate>  20:    21:                 <!-- Contractor template -->  22:                 <DataTemplate x:Name="Manager">  23:                     <local:ManagerUC />  24:                 </DataTemplate>  25:             </ss:SelectableContentControl.Templates>  26:         </ss:SelectableContentControl>  27:     </ListBox.ItemTemplate>  28: </ListBox>

So what's going on here?

The ListBox has it's ItemsSource bound to a property on the DataContext called StaffList, which contains a collection of StaffMember instances. The ListBox.ItemTemplate contains a single SelectableContentControl with its TemplateName property set to "StaffRole" and it's Content bound to the DataContext of the ListBoxItem. At run time when a DataTemplate is being created for each item in the listbox and the item is databound to it, the SelectableContentControl will read the StaffRole property and find a template with the same name as the StaffRole value. The first DataTemplate in the Templates collection will be used for any data items that have a StaffRole value that doesn't match a Template name. We don't even need a value converter in this example, since the StaffRole property will convert to a string without one.

In order to make this technique friendly to Blend you need to create a UserControl for each of the DataTemplates so that the content can be styled in Blend. If you are more comfortable writing XAML than using Blend then you can skip the UserControls and put the content directly in the DataTemplates. Either way, you will still need to specify the DataTemplate collection by hand in XAML since Blend doesn't provide and easy way to edit a collection of DataTemplate instances (at least that I know of)

Feel free to copy the code above and use it in your own projects. Let me know if you find it useful.

A Chrome and Glass Theme - Part 3

noreply@blogger.com (Phil Middlemiss) — Thu, 08 Apr 2010 06:30:00 +0000

In the first two parts I covered how to use Blend to create reusable resources for brushes and styles, and we styled a Border control and a Button control.

In this post we are going to style two more relatively simple controls: a TextBox, and a CheckBox. So start by re-opening your solution from last time (you can grab it here if you haven't been following along). This is what the final styles will look like:

You can grab the solution containing these styles here.

First: Improve the Button

But first, I want to quickly revisit the Button style we created last time - after playing around with it some more, I don't like the way it looks when it's disabled. We didn't change the default disabled state appearance, which grays-out the control by changing the opacity of the "DisabledVisualElement" rectangle. The problem is that when the button is disabled, it actually stands out more than any enabled buttons around it - which it shouldn't.

To fix it, we are going to give it a glassy look when it's disabled.

Select the button we created last time and use the bread crumb trail to edit the control template. Open up the Object tree and select the grid control under the "Background" Border control. Click the Advanced Properties Options button on the right of the Background brush and select "Reset" to get rid of the link to the template background color.

Select the "DisabledVisualElement" and change it's Fill to a linear gradient with the following markers:

#FFFFFFFF Position: 12.7%
#FFCDCDCD Position 32.8%
#FF898989 Position 35.2%
#FFC2C2C2 Position 39.6%
#FFB3B3B3 Position 49.3%
#FFFFFFFF Position 52.4%
#FF252525 Position 55.6%
#FF808080 Position 100%

And click the little down arrow below the brush editor to show the advanced properties of the gradient brush, and change the Opacity of the whole brush (not the rectangle) to 31%. Now convert that to a new resource called "ChromeGlassFill" in our ChromeGlass resource dictionary.

Finally, select the "Disabled" state, set the Opacity of the BackgroundGradient rectangle to 0%, the Opacity of the DisabledVisualElement rectangle to 100%, and the Opacity of the ContentPresenter to 50%. And set the margins of the DisabledVisualElement to 2. Use the Bread Crumb Trail to exit the style template back into the MainPage. The image to the left shows the button now in it's different enabled states.

The TextBox Control

Before we create a TextBox control we have to group our existing button into a Grid since a Border can only contain one control. Right click the button and press Ctrl + G to group it into a Grid control. Blend will have set the margins on the grid to fit exactly around the button, and changed the button horizontal and vertical alignments to Stretch so reset the margins of the new Grid back to 0, make sure the horizontal and vertical alignments are both Stretch, and the Width and Height are both Auto. Of course now our button takes up the entire grid, so change it's width back to 140, and it's height back to 30. And drag it back into place.

Now add a TextBox control to the Grid, make it about the same size as the button. From the Object menu, select "Edit Style" | "Edit Copy..." and save it as "TextBloxGlassyStyle" in our ChromeGlass resource dictionary. Set it's Background brush to our new "ChromeGlassFill" brush, and it's border to the "ChromeBorder" fill. Set the Foreground brush to a white solid color, the CaretBrush to a white solid color, and the SelectionForeground to black.

Now use the Breadcrumb Trail to edit the current template and open up the object tree. Select the self-named "Border" control and reset it's Background brush to be empty - we are going to animate the opacity of the background, but if we do it on the Border then it will also affect it's child controls.

Create two new rectangles inside the Grid called "UnfocusedBackground" and "EditingBackground" positioned as the first children of the grid as shown in the image to the left. Make sure the margins of the rectangles are reset to 0, the horizontal and vertical alignments are set to Stretch, and the Width and Height set to Auto.

Select the UnfocusedBackground rectangle and use the Advanced Property Options button on it's Fill to use Template Binding to the Template's Background property. Set it's stroke to No Brush.

Select the EditingBackground rectangle, set it's Fill to #4CFFFFFF, and it's Opacity to 0%.

Make the following changes to the Focused State:

Set the UnfocusedBackground Opacity to 0%
Set the EditingBackground Opacity to 100%
Set the FocusVisualElement Opacity to 50%
Set the FocusVisualElement Margins all to 0

And these changes to the Disabled State:

Set the Border Opacity to 75%
Set the ContentElement Opacity to 50%
Set the DisabledVisualElement Opacity to 0%

That's our TextBox done. Exit the Style Template and run the solution to try it out.

The CheckBox Control

Create a CheckBox control and use the same technique as for the TextBox control to create a style called "CheckBoxGlassyStyle" in our resource dictionary.

While editing the style, set the BorderBrush to our ChromeBorder LinearBrush resource and set the Foreground to White. Now use the Breadcrumb Trail to edit the control template and make the following changes to the controls inside the template (you can ignore the warnings about animations being removed):

Set the Background control's Fill to our GlassFill resource
Set the BoxMiddleBackground control's Fill to our ChromeFill resource (you will have to Reset it first)
Set the BoxMiddle control's Fill to our ChromeGlassFill resource and it's Stroke to our GlassBorder resource
Set the CheckIcon control's Fill to white
Set the IndeterminateIcon control's Fill to our ChromeFill resource

You can see the benefit of saving our linear gradient brushes as resources - that saves us a lot of time!

Now we just need to update the states:

MouseOver State

Set the BackgroundOverlay Opacity to 30%
Set the BoxMiddleBackground Opacity to 30%

Pressed State

Set the BackgroundOverlay Opacity to 0%
Set the BoxMiddleBackground Opacity to 100%

Focused State

Set the ContentFocusVisualElement Opacity to 50%

And that's it! Exit the template back into the Main Page and run your solution.

In the sample at the top of the post I've bound the IsEnabled property of the TextBox and Button to the CheckBox so you can see what they look like disabled.

You can grab the solution containing the above styles here.

A Chrome and Glass Theme - Part 2

noreply@blogger.com (Phil Middlemiss) — Sun, 04 Apr 2010 03:55:00 +0000

Well - it's a long weekend here in New Zealand due to the Easter holidays, so I have some spare time to do another post in this series earlier than I would otherwise have had.

In the last post we created a resource dictionary and defined some brush and style resources to create a glassy panel. In this post we are going to define some more brush and resource styles for a chrome looking button. Here is what the button will look like:

Open up the solution from the last post - if you haven't been following along so far, you can grab the solution so far here.

Editing the Button Style

Select the Border control and create a button inside it about 140x30 in size. Click the "[Button]" button on the breadcrumb trail bar and edit a copy of the button template. Call the new style "ButtonChromeStyle" and be sure to select the "Resource Dictionary" option to create it in our ChromeGlass resource dictionary.

Blend has created a copy of the default style and control template of the button. But before we change the appearance of the elements inside the control template, click the "artists palette" icon in the breadcrumb trail so that we are editing the style itself, and not the control template inside the style.

We are going to define the chrome-looking border so select the BorderBrush property on the Properties tab. The button already has a linear gradient so add 3 more markers to the three already there and define the locations and colors as follows:

#FFDCDCDC Position 0%
#FF656565 Position 44.8%
#FFD8D8D8 Position 68.9%
#FF2B2B2B Position 92.6%
#FFE9E9E9 Position 94.8%
#FF494949 Position 97.2%

We are going to want to reuse this brush again so click the Advanced Properties Options button on the right of the BorderBrush property and select "Convert to new resource...". Call it "ChromeBorder".

Select the Foreground property on the style and change it to white - for some reason, the Button control doesn't seem to inherit the white foreground we set on the UserControlStyle from Part 1 in this series, so we must set it on the style.

Editing the Control Template

Now click the "Template" button on the breadcrumb trail to go back to editing the template which looks like the picture on the left.

Select the Background border element in the object tree and select it's BorderBrush. The BorderBrush is bound to the template style that we defined on the actual style - which is the chrome border. Blend sometimes gets confused so if it still shows the old blue linear gradient, don't worry; when we compile and run the solution it will do the right thing.

Now select the Background property and change the "A" (Alpha) value to zero, which should leave a transparent gap inside the button border.

We're going to define our Chrome gradient for the inside of the button so select the BackgroundGradient rectangle in the Object tree and select it's Fill property which is already a linear gradient. The button states (which we will get into later) contain some animation settings for the markers in this existing gradient. We want to clear them and the easiest way to do that is to change it to a solid color, and then change it back to a linear gradient. When you do this you will see a warning appear briefly at the top of the design area warning you that some animations have been deleted. Which is what we want.

Change the color and position of the 5 markers on the linear gradient to these values:

#FFFFFFFF Position 12.7%
#FF878787 Position 51.6%
#FF393939 Position 53.2%
#FF858585 Position 94.8%
#FFFFFFFF Position 100%

And change the RadiusX and RadiusY properties both to 2. Also change the CornerRadius of the BackgroundAnimation border element to 2.

Again, we are going to reuse this gradient later so select the BackgroundGradient element (if it's not already selected), click the Advanced Property Options button and convert it to a local resource called "ChromeFill".

Although we are going to reuse this gradient, it's a little bit to bright for the button since we have specified White as the foreground (text) color on the style. We are going to use another rectangle in the button template to correct this rather than change the gradient brush resource we just created.

Select the [Grid] control inside the Background border control in the object tree, and double click the Rectangle icon on the tool palette. Reset it's margin property (which Blend has probably changed) all to 0s and set it's Stroke property to NoBrush. Also, change it's RadiusX and RadiusY values to 2.

Select it's Fill property and set it to be a linear gradient brush with the following 3 markers:

#4C5F5F5F Position 0%
#4CDCDCDC Position 23.4%
#4C000000 Position 65.7%

We may need to use this gradient again so convert it to a local resource called "ChromeDarkeningLinear" (yup - we are going to create a radial one in a later post). The white text back on the button will now show clearly against the background.

Changing the Visual States

The last thing to do is to change the appearance for the various states that the button can be in. Click the "States" tab and you will see all the various states that a button can be in.

Select the "MouseOver" state - any changes we make to element properties now will only take effect when the mouse is over the control (in the running application). The BackgroundAnimation element already has an animation to change the opacity from 0 to 100 (it has the little red circle on it's icon in the object tree), so select the BackgroundGradient element in the Object tree and change it's opacity to 85%. This will allow a bluish color to show through.

Select the "Pressed" state. There will already be an animation for the Background border element (near the top of the object tree), but we want to change it:

Select the Background border element and set it's background brush to black, but change the A value to 50%.
Select the BackgroundAnimation element and change it's Opacity to 50%
Select the BackgroundGradient element and change it's Opacity to 50%

The last thing to do is to introduce a small animation to move between the Normal and MouseOver states a little more smoothly. Click the down arrow on the "Normal" state and choose the "Normal -> MouseOver" menu item. Set the transition duration that appears to 0.2. Now do the same for the MouseOver state (choosing the "MouseOver -> Normal" item).

Make sure you save your progress, and click the "[Button]" button on the breadcrumb bar to go back out to our main design area. That's the button finished, so run your application and try it out. The final design area should look something like this:

You can download a project containing the above resources here.

In the next post we are going to

A Chrome and Glass Theme - Part I

noreply@blogger.com (Phil Middlemiss) — Fri, 02 Apr 2010 02:03:00 +0000

This is the first in a series of posts that will cover how to build a nice looking chrome and glass theme. The chrome style will be applied to controls and the glass look will be a balancing style to avoid an overload of shiny; it will also give us a nice gentle background appearance.

In this post we are going to define some gradients and color resources for a glass style that can be applied to a Border control. Here is what the finished button will look like:

We are going to end up with a resource dictionary that we can use with both the ImplicitStyleManager from the Silverlight Toolkit for Silverlight 3, or directly with Silverlight 4. The only difference between the two approaches is that we don't need to add the x:Key="StyleKeyName" attribute on each style, or set the Style property on each control if we want to use it in Silverlight 4.

Setting up our Theme
First we need to create our solution. Start Blend and create a new project (call it something like "ChromeAndGlassTheme". Under the Project menu select "Add new item...", and add a new Resource Dictionary called "ChromeGlass.xaml".

Styling From the Top

The first thing we want to define is the foreground color for text on most of the controls styles we will end up with - which will be white. So select the "[User Control]" root in the Objects tree, and change the foreground to white. We want this setting to be part of the resource dictionary we created, so we do the following to achieve that:

Click the "Advanced Property Options" button (the little square button to the right of the Foreground box)
Select "Convert to New Resource..."
Give it the name (key) "WhiteForeground"
Choose "Resource Dictionary" for the location to define it
Click OK

Since we only have the one Resource Dictionary, it will have created the entry in the ChromeGlass.xaml.

Next, with the "[User Control]" still selected, open the "Object" menu and select the "Edit Style | Create Empty..." menus. Call the style "UserControlChromeStyle", make sure it is created in our ChromeGlass resource dictionary, and click OK. We are now editing the style resource, not the control. On the properties tab click the Advanced Property Options button for the foreground and select the "Local Resource" sub menu, and choose our "WhiteForeground" resource.

Why have we set this on the UserControl? So that we don't need to explicitly set the foreground color for our child controls (such as labels and buttons); Silverlight will search up to see if any of the parent controls have their foregrounds explicitly set before going back to the default value for the control. So since we have set the style of the UserControl to have it's foreground white, all child controls that we place inside it will use WhiteForeground unless we set them otherwise.

Now select the "LayoutRoot" grid and set it's background to black. We could have created a style like we did for the UserControl, but background is not one of the values that is propagated to child controls - and we won't want it passed down anyway.

The Gradients

Our chrome and glass styles are going to rely heavily on a couple of gradient brush resources we are going to define. First lets create the glass panel that can contain our controls. Create a new Border element and make it about 300px wide and about 120px high. Before we create a style for it, we should clear any changes that Blend has already made to the Border's properties. Click the Advanced Property Options box to the right of the Background property and select "Reset". Do this also for the BorderBrush, BorderThickness, and CorderRadius properties.

Now create a new empty style for it like we did for the UserControl - call it "BorderGlassStyle" and be sure to create it in our resource dictionary.

Select the "BorderBrush" property and select the Gradient Brush option below it. The gradient bar will have two markers - one at each end. Select the left marker and change it's color to White (both markers should now be white). Add another 7 markers by clicking on the gradient bar between the existing markers and set the following values for each marker (1 is leftmost, 9 is rightmost. The "Alpha" refers to the "A" part of the color):

position: 0%. Alpha: 60%
position: 8.5%. Alpha: 0%
position: 37.6. Alpha: 20%
position 41.8%. Alpha: 60%
position 47.7%. Alpha: 20%
position 60.5%. Alpha: 0%
position 76.5%. Alpha: 20%
position 80.7%. Alpha: 50%
position 100%. Alpha: 5%

If you click the down-pointing arrow below the gradient bar you will see some other values we can set for this gradient. Set the the start and end points as follows:

Start Point: 0.013, 0.036
End Point: 1, 1.005

And set the Border Thickness to 2 for each edge and a Corner Radius of 8. This will make our border look like it is reflecting shafts of light.

We are going to reuse this glassy border brush again, so click the Advanced Property Options button for the BorderBrush property and convert it to a new resource called "GlassBorder".

Since we are editing the style resource, not the Border control itself, lets pop back out to the border to see what it looks like. You can do that by clicking on the "[Border]" part of the Style path at the top of the editing window:

Now we are back in our MainPage file with the Border control selected. Click the little Pac-Man (ok - it's an artist's pallet) shape to go back to editing the style. Now let's create a glassy border for the background.

Select the Background property of the style and again select the Linear Gradient option. We want a total of 5 markers on this gradient. This time we will set the hex values for each of the markers as follows:

#26FFFFFF position: 0%
#194C4C4C position: 40.4%
#19FFFFFF position: 61.4%
#4DFFFFFF position: 71.5%
#18FFFFFF position: 100%

Also set the start and end points to the following:

Start point: 0.388, -0.015
End point: 0.769, 0.922

You can jump back out of the style now and see what the finished style looks like:

You can download a project containing the above resources here.

In the next post we will create the chrome gradients we are going to need for our controls and create our first control style for the Button control.

Merged Dictionaries of Style Resources and Blend

noreply@blogger.com (Phil Middlemiss) — Tue, 23 Mar 2010 01:26:00 +0000

A while ago I needed to have multiple resource dictionaries available to my Silverlight application. One would be the base library with a complete set of style resources for the application, and the others would be resource dictionaries for alternative styles. The application would choose which alternative style to use when it loaded, and would merge the alternative style into the base style resources. For example we may have an application that we only want to install once on the server, but it needs to have different corporate branding depending on which customer is using it

After reading up on how best to use the MergedDictionary, and reading about resource usage problems others were having, I decided I needed a solution that would meet the following goals:

Allow me to keep various styles in separate resource files
Work with Prism modules
Require the minimum of system resources
Play nice with Blend (well, as much as possible)

There were trade-offs among the last two goals, but the following technique has been useful in my day to day development and I have continued to use it successfully.

I'll start with the basics though:

Reusable Styles

This first section describes an approach to styling that allows for separation of design and functionality, is efficient in terms of resource requirement, and is compatible with working with Blend.

Styling is carried out in a Silverlight application by defining a style and applying it to a control. For example, a TextBox control could be declared like this:

   1: <UserControl    2:     x:Class="SilverlightTestbed.UserControl1"xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"   3:     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"Width="400" Height="300">   4:     <Grid x:Name="LayoutRoot" Background="White">   5:         <TextBox Width="300" BorderBrush="Blue" FontSize="12" Background="Black" Foreground="White"/>   6:     </Grid>   7: </UserControl>

However, if the UserControl contains several TextBox controls that must all look the same it becomes tedious to update each one individually to make its appearance the same; and if the design requirements change then updating each control is even more tedious. So the attributes can be extracted out into a style like this:

   1: <UserControl x:Class="SilverlightTestbed.UserControl1"xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"   2:     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"Width="400" Height="300">   3:     <UserControl.Resources>   4:         <Style x:Key="TextBoxStyle" TargetType="TextBox">   5:           <Setter Property="Width" Value="300"/>   6:           <Setter Property="BorderBrush" Value="Blue"/>   7:           <Setter Property="FontSize" Value="12"/>   8:           <Setter Property="Background" Value="Black"/>   9:           <Setter Property="Foreground" Value="White"/>  10:         </Style>  11:     </UserControl.Resources>  12:     <Grid x:Name="LayoutRoot" Background="White">  13:         <TextBox Style="{StaticResource TextBoxStyle}"/>  14:     </Grid>  15: </UserControl>

Note the following important points:

The style has a unique Key
The style specifies its TargetType
The TextBox.Style property uses the value of the style’s Key

This allows us to set the style on all TextBox controls in the UserControl to the “TextBoxStyle” style and update them all by changing the style in a single place. However, what if we want to apply this style to many TextBox controls throughout the application? If we re-declare the style in every UserControl then once again, if the design requirements change, we must tediously go through all declarations and update it once. We can do this by declaring the style in the App.xaml file.

   1: <Applicationxmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"x:Class="SilverlightTestbed.App">   2:     <Application.Resources>   3:         <!-- Resources scoped at the Application level should be defined here. -->   4:         <Style x:Key="TextBoxStyle" TargetType="TextBox">   5:             <Setter Property="Width" Value="300"/>   6:             <Setter Property="BorderBrush" Value="Blue"/>   7:             <Setter Property="FontSize" Value="12"/>   8:             <Setter Property="Background" Value="Black"/>   9:             <Setter Property="Foreground" Value="White"/>  10:         </Style>  11:     </Application.Resources>  12: </Application>

Merged Dictionaries

Now we can use it in all UserControls in our project. However, if we need to present the same application with different style themes – for example different corporate branding of the same application – then we have a problem. We need to be able to swap the styles for different customers, but we don’t want to have to edit App.xaml every time and compile a specific version for that customer. The solution is create a separate style assembly that we import in App.xaml. In the style assembly we just have the XAML file(s) for a customer’s branding; the style may be broken up into a file for color definitions, layout, and templates for example, or it may all be in one XAML file. The Build Action for the XAML file(s) will be set to “Resource”.

To use the style in our main app, and our UserControls, we add a reference to our styles project and use the MergedDictionary to make it available as a resource, which looks like this:

   1: <Application xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"    x:Class="SampleNameSpace.App">   2:     <Application.Resources>   3:         <ResourceDictionary>   4:             <ResourceDictionary.MergedDictionaries>   5:                 <ResourceDictionary Source="/SharedNameSpace.StyleResources;component/BaseStyles.xaml"/>   6:             </ResourceDictionary.MergedDictionaries>   7:         </ResourceDictionary>   8:     </Application.Resources>   9: </Application>

In the example above, App.xaml loads in the BaseStyles.xaml and merges its content into the main shell’s resource library. This means that any control that the shell instantiates can apply one of the colors/templates/styles defined in BaseStyles.xaml. We could also have multiple style projects (with the same compiled assembly name) that we could swap in and out for different customer skins.

If we have other Prism modules that contain UserControls then we need to add a reference to the styles assembly in those modules also – but we should set the “Copy Local” property for that assembly reference to false since the Shell will already contain that styles assembly.

Resource Hog vs Design Time Support

Our UserControls don’t need to define any styles at all if they are all defined in the styles assembly and merged into App.xaml. We can explicitly import the styles assembly into each user control using exactly the same syntax as shown above for App.xaml, however each time we do that, we are creating another ResourceDictionary with the same content defined. Which means if we have 100 styles defined in BaseStyles.xaml, and we have 50 UserControls each importing BaseStyles.xaml into a ResourceDictionary, that means our application, at run time, has 50 ResourceDictionaries instantiated with a combined total of 5,000 style static resources.

That’s unacceptable so we don’t want to import the resource dictionary in each UserControl, however we still need some way of including it for design time in Blend. At run time the App.xaml ResourceDictionary will be available to all the UserControls that are loaded into the application from various modules, but at design time the UserControls themselves don’t contain any reference to the styles so all controls appear in their default state. Worse than that – some UserControls won’t even display properly in Blend if they use child UserControls that need styles from the styles library.

There is no easy solution to this problem – if we add the explicit MergedDictionary entry (as above) for each of our UserControls then we have design time support, but then we face excessive resource usage. If we don’t have the MergedDictionary declaration in each UserControl then we are keeping our resource usage low, but lose design time support.

One way around this is to have the ResourceDictionary declaration in each user control, but commented out. The declaration can be uncommented while the UserControl is being worked on in Blend, and then uncommented when the design work is complete.

Finally, we get to the bit about merging selected styles when the application loads.

ThemeMerger

The ThemeMerger class described below provides functionality that allows the merged styles to be dynamically handled at start-up. The example in the introduction was that

we may have an application that we only want to install once on the server, but it needs to have different corporate branding depending on which customer is using it. If we have a different virtual directory on the server for each customer then they can have a different URL, or we could create a separate ASPX/HTML page for each customer. With either of these techniques we have the ability to determine at run time which customer we need to style the application for, so we need some way to respond to that knowledge and merge the correct styles. Let’s take the example where we have a separate page for each customer. The page can pass a parameter into the Silverlight application identifying the customer (relevant part emphasized):

   1: <body>   2:     <form id="form1" runat="server" style="height:100%">   3:         <div id="silverlightControlHost">   4:             <object data="data:application/x-silverlight-2," type="application/x-silverlight-2" width="100%" height="100%">   5:                 <param name="source" value="ClientBin/SampleNamespace.SampleApp.xap"/>   6:                 <param name="onError" value="onSilverlightError" />   7:                 <param name="background" value="white" />   8:                 <param name="minRuntimeVersion" value="3.0.40624.0" />   9:                 <param name="windowless" value="false" />  10:                 <param name="autoUpgrade" value="true" />  11:                 <param name="initParams" value="customer=Company_A" />  12:                 <a href="http://go.microsoft.com/fwlink/?LinkID=149156&v=3.0.40624.0" style="text-decoration:none">  13:                     <img src="http://go.microsoft.com/fwlink/?LinkId=108181" alt="Get Microsoft Silverlight" style="border-style:none"/>  14:                 </a>  15:             </object>  16:             <iframe id="_sl_historyFrame" style="visibility:hidden;height:0px;width:0px;border:0px"></iframe>  17:         </div>  18:     </form>  19: </body>

We want to use this knowledge at the earliest possible moment in the App.xaml since we want our resource dictionaries merged correctly before any XAML has been instantiated into controls. So in the App.xaml we can place the following code in the constructor:

   1: public App()   2: {   3:     // We need to work out what style to use.   4:     if (Application.Current.Host.InitParams.ContainsKey("customer"))   5:     {   6:         // merge with correct style here.   7:     }   8:     this.Startup += this.Application_Startup;   9:     this.Exit += this.Application_Exit;  10:     this.UnhandledException += this.Application_UnhandledException; InitializeComponent();  11: }

So now we need some mechanism of merging the correct style; which is what the ThemeMerger provides for us. ThemeMerger gives us this mechanism with two steps. The first step is to use an attached dependency property named “SourceLocation” that is designed to be attached to a ResourceDictionary like this:

   1: <ResourceDictionary   2:     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"   3:     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"   4:     xmlns:local="clr-namespace:SampleNamespace;assembly=SampleAssembly">   5:     <ResourceDictionary.MergedDictionaries>   6:         <ResourceDictionary Source="/SampleNamespace.StyleResources;component/BaseStyles.xaml"/>   7:         <ResourceDictionary local:ThemeMerger.SourceLocation="SampleNamespace.StyleResources" />   8:     </ResourceDictionary.MergedDictionaries>   9: </ResourceDictionary>

The second step for using the ThemeMerger is to tell it which XAML file to load from the specified namespace. We do this back in the App.xaml.cs constructor, using the value of the parameter we passed in from the html page, setting it to the ThemeMerger.ThemeName static property:

   1: public App()   2: {   3:     // We need to work out what style to use.   4:     if (Application.Current.Host.InitParams.ContainsKey("customer"))   5:     {   6:         // merge with correct style here.   7:         ThemeMerger.ThemeName = Application.Current.Host.InitParams["customer"];   8:     }   9:     this.Startup += this.Application_Startup;  10:     this.Exit += this.Application_Exit;  11:     this.UnhandledException += this.Application_UnhandledException;  12:     InitializeComponent();  13: }

By the time the constructor gets down to the call to “InitializeComponent()”, the application has the correctly merged styles in place. The ThemeMerger has set the Source property on our second ResourceDictionary declaration by combining the namespace with the theme name.

There are two important points worth highlighting here:

The value of the “customer” parameter in the initParams is the same as the name of the xaml style filename.
Do not include the “.xaml” extension in the initParams, the ThemeMerger will add that.

The last step in the example above is to change the App.xaml file to refer to the StyleResources MergedStyle.xaml file:

   1: <Application xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"   2:     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"   3:     x:Class="SampleNamespace.App">   4:     <Application.Resources>   5:         <ResourceDictionary>   6:             <ResourceDictionary.MergedDictionaries>   7:                 <!--   8:                     App.xaml links to StyleResources.MergedStyles, which carries out the appropriate   9:                     style overrides prescribed by the StyleResources.ThemeMerger.ThemeName which  10:                     is set in the App.xaml.cs constructor.  11:                     When using Expression Blend to edit styles, comment the MergedStyles resource dictionary  12:                     and uncomment the appropriate style file that you want to work on (or both)  13:                 -->  14:                 <ResourceDictionary Source="/SampleNamespace.StyleResources;component/MergedStyles.xaml"/>  15:                 <!--  16:                     <ResourceDictionary Source="/SampleNamespace.StyleResources;component/BaseStyles.xaml"/>  17:                     <ResourceDictionary Source="/SampleNamespace.StyleResources;component/Company_A_Styles.xaml"/>  18:                 -->  19:             </ResourceDictionary.MergedDictionaries>  20:         </ResourceDictionary>  21:     </Application.Resources>  22: </Application>

We can leave in the commented out specific declarations for each style file and uncomment them when we need to use Blend to design the UserControls in the ShellView module, and place the following, similar declaration in each UserControl:

   1: <UserControl >   2:     <UserControl.Resources>   3:         <ResourceDictionary>   4:             <!--   5:                 This ResourceDictionary.MergedDictionaries tag is not required for the view to render correctly - the   6:                 App.xaml file links to the external style libraries and allows overriding styles for different views.   7:                 However, to edit this view in Expression Blend, you can uncomment the appropriate resource dictionary   8:                 that you want to work on (or both if overriding parts). See StyleResources.MergedStyles.xaml for more details.   9:                   10:                 <ResourceDictionary.MergedDictionaries>  11:                     <ResourceDictionary Source="/SampleNamespace.StyleResources;component/BaseStyles.xaml"/>  12:                     <ResourceDictionary Source="/SampleNamespace.StyleResources;component/Company_A_Styles.xaml"/>  13:                 </ResourceDictionary.MergedDictionaries>  14:             -->  15:         </ ResourceDictionary>  16:     </ UserControl.Resources>  17:     ...  18: </ UserControl>

The only difference in the declaration for the UserControl is that we don’t link to the MergedStyles.xaml file since that would duplicate the style resources.

So finally, here is the code for the ThemeMerger class:

   1: namespace SampleNamespace   2: {     3:     using System;     4:     using System.Windows;    5:        6:     /// <summary>     7:     /// Allows a theme to be set at run time. To use this class do the following:     8:     /// 1) Set the static ThemeName property as early in the application as possible     9:     ///   (before the app.xaml.cs calls InitializeComponent()). The Theme name is the    10:     ///    name of the xaml file that overrides the base styles (the first file mentioned in 3)    11:     /// 2) In App.xaml, define a merged dictionary pointing to a single xaml file    12:     /// 3) In the xaml file link to two merged dictionaries: the base xaml file that    13:     ///    defines the styles for the default appearance of the app; and a merged dictionary    14:     ///    that does not have it's Source property set, but has the attached ThemeMerger.SourceLocation    15:     ///    property set to the namespace of the assembly with the resource file to merge.    16:     /// </summary>    17:       18:     public static class ThemeMerger    19:     {        20:         /// <summary>        21:         /// Dependency Property for the Active attached property        22:         /// </summary>        23:         public static readonly DependencyProperty SourceLocationProperty =  24:             DependencyProperty.RegisterAttached(  25:             "SourceLocation",  26:             typeof(string),  27:             typeof(ThemeMerger),  28:             new PropertyMetadata(string.Empty, OnSourceLocationChanged));  29:           30:         private static string themeName = string.Empty;  31:           32:         /// <summary>        33:         /// Gets or sets the theme name to use. The ThemeName should be just the name of the        34:         /// xaml file, without the .xaml extension.        35:         /// </summary>  36:         public static string ThemeName        37:         {           38:             get { return themeName; }  39:             set { themeName = value; }  40:         }       41:           42:         /// <summary>        43:         /// Accessor method for SourceLocation Attached Property        44:         /// </summary>        45:         /// <param name="resourceDictionary">The DependencyObject the property is attached to</param>  46:         /// <returns>The namespace of the assembly the xaml file is in</returns>  47:         public static string GetSourceLocation(DependencyObject resourceDictionary)  48:         {  49:             return (string)resourceDictionary.GetValue(SourceLocationProperty);  50:         }       51:           52:         /// <summary>        53:         /// Accessor method for Active Attached Property        54:         /// </summary>        55:         /// <param name="resourceDictionary">The DependencyObject the property is attached to</param>  56:         /// <param name="value">The namespace of the assembly the xaml file is in</param>  57:         public static void SetSourceLocation(DependencyObject resourceDictionary, object value)  58:         {  59:             resourceDictionary.SetValue(SourceLocationProperty, value);  60:         }  61:           62:         private static void OnSourceLocationChanged(DependencyObject resourceDictionary, DependencyPropertyChangedEventArgs e)  63:         {  64:             if (string.IsNullOrEmpty(ThemeName))  65:             {  66:                 // no override theme selected  67:                 return;  68:             }  69:    70:             if (string.IsNullOrEmpty((string)e.NewValue))  71:             {  72:                 // theme overriding not active  73:                 return;  74:             }  75:    76:             // set the source of the resource dictionary to the specified theme  77:             ResourceDictionary dictionary = resourceDictionary as ResourceDictionary;  78:             if (null == dictionary)  79:             {  80:                 return;  81:             }  82:             Uri uri = new Uri("/" + e.NewValue + ";component/" + ThemeName + ".xaml", UriKind.RelativeOrAbsolute);  83:             dictionary.Source = uri;  84:             return;  85:         }  86:     }  87: }

Please leave a comment if you find it useful.

A Scalable Orb Panel-Button-Thingy

noreply@blogger.com (Phil Middlemiss) — Sun, 14 Mar 2010 21:31:00 +0000

I think I may have mentioned before that I'm not much of an artist - thankfully the internet is chock-full of inspirational ideas. When browsing around some Photoshop tutorial sites, I came across an avatar of enzudesign on a forum; the avatar looks like this.

That's a cool looking button. So credit where credit's due - enzudesign is a talented artist. I wanted to try create something similar in Silverlight that would work as a button, following the same kind of process that I used for the Radio Button I did recently. This one has a LOT more content to it. My first attempt at it required 14 ellipses; 11 of those requiring a blur effect. It also meant containing those ellipses in about 18 proportional columns and rows. It looked nice, but performed poorly. I suspect all those blurs were chewing through a lot of CPU. I don't know how much CPU effort it takes to update those proportional values into real values when the whole thing is animating, but I'm guessing it contributed to the poor performance. This is what it looked like with and without the blur effects:

The blur gives the chrome surrounding ring a rounder appearance, and makes the black look more "rubbery". In comparison, the image without the blur looks stark. I guess this is quite subjective, but to my eyes, the blurred button looks nicer. But it's performance is terrible. I turned it into a button template and the transitions from Normal to MouseOver were not smooth at all. I've included a (collapsed) copy of the above design in the download. So it looked great but it had to lose some detail.

The result, after trimming it down, is embedded below, but I wanted to do more with it than just use it as a button. It occurred to me that this design would make a nice border for a panel; cut it into quarters and you have the corners. All it would need is filling in some horizontal and vertical banding to join the corners. "All it would need" actually turned out to be somewhat fiddly, but before I bore you with the details, the effect I was after needed to have two features:

The button itself would scale nicely, keeping proportion where it needed to
The transition from round orb to rounded panel should be as seamless as possible.

Here is what the "finished" product looks like (download link at the bottom of the post):

The button now consists of only 10 ellipses; 4 of those with blur effects. I won't go through the whole process of compositing the button since that was covered here. But I will quickly cover the process I used of turning an ellipse into a rounded panel.

Setting up the Panel Grid and Corners

I wanted a panel where the corners stay the same and, as the panel grows or shrinks, the "filler" between the corners would expand or contract to fill the gap. The first thing to do was to work out how to get just the appropriate part of each corner to show. I played around with a few options such as using a clipping path, an opacity mask, or using the Path | Subtract tool to convert the ellipses into just the quarter that was needed. These approaches all had their own problems: I don't like clipping paths because they are high-maintenance to animate in storyboards; the Opacity Mask has similar problems since it essentially just a brush that covers the whole object; using the Path | Subtract tool gave the right shape, but the blur effects and the gradients were now applied to just that quarter and proved too fiddly to work with. This was compounded by the fact that the button is not symmetrical across all four quarters.

In the end I discovered that if I confined the whole thing into a grid cell, but sized it so that it was twice as wide and twice as high as the cell, then the Grid automatically clipped out everything except the bit that fitted in the cell. So the here is what the containing grid looks like with the four corners in place:

The first and last columns, and the first and last rows, are each set to a fixed width/height (in this case 50 pixels). The middle columns and rows have their width/height set to "1*" to take up all the gap between the fixed rows and columns. Each corner has an entire copy of the "button" shapes sized to 100x100 pixels, and has it's horizontal/vertical alignment set to the appropriate values for each corner.

Although this provides the corners that I need, I'm not entirely happy with this approach because I can't easily animate the column width and height of the corner cells if I want the radius of the corners to change. In the embedded Silverlight app above, it is the button itself that is changing radius - not the panel grid. I would like to come back and address this at a later date to work out how to achieve this more easily. I have in mind that creating a custom control with template parts for the corners and horizontal fills would work - I'll have to experiment when I get the time.

The Fillers

The next stage was to create the fills between the corners and in the middle. For the top and bottom fills, this was achieved by copying the whole button structure, changing the ellipses into rectangles, and removing the columns from the containing grid to make the shapes span the whole grid. I had to change into the XAML view to change the ellipse tags to rectangle tags.

The resulting grid is sized the same as the corner shapes (100 pixels high) and restricted to the middle top grid cell to clip out the bottom half.

The same result is copied and pasted for the bottom fill and placed in the middle bottom cell.

The vertical fills are done essentially the same except there were a couple of areas that were a bit trickier because the button is asymmetrical vertically. I was able to remove a few of the shapes for the vertical fill because it's mostly just black between the chrome ring and the blue orb center. The trickiest part was the center blue part of the orb. The bit that goes from the the left side of the blue center to the right side of the blue center. For the other rectangles I just tweaked the existing gradients, but for the center rectangle I created the gradient from scratch using the color picker tool to get a selection of colors across the width of it.

The last part of the grid was straight forward, it is just a rectangle with a solid color fill. It stretches horizontally and vertically to fill the middle space.

The only other thing to point out is that I had to set the margins of the horizontal and vertical fill edges that met the corners to -3 so that there was no obvious seam. If you look hard you can still make out where the parts meet, but I don't think you would notice them unless you were specifically looking for them.

The Animation

The animation is somewhat of a cheat. It looks like the button shrinks, and then expands into a panel containing the buttons. There is actually two groups of controls here: the button is shrinking down in size, but then it's opacity animates to 0 to reveal the panel behind it (in exactly the same location). It is then the panel that grows to reveal the fillers, and then displays the buttons inside it. The whole process is reversed when the panel is closed.

I really like the end result, but I would like to come back and revisit this later to make the whole thing easier to replicate with a different design.

Download, including source, from here.