Richard Waddell

Seeker Sidebar 4 – Styles, Control Templates, and Visual States

Mon, 25 Jan 2010 03:21:07 GMT

Live Example:

http://www.adefwebserver.com/Richard/ooNaEyeDevelopmentv2/ooNaEyeDevelopmentTestPage.html

I’ve been promising to get to Visual States, and this time I’m actually going to do it. In the process I cover creating a templated control from scratch, and technically I achieve my goal of not having to type in the visual states. From there I show how much control a designer has over the many versions of the UI of a templated control, entirely in Blend design view - including how to mess up the xaml if you edit the wrong thing – same choice, different menus. If you don’t already know how to create templated controls, and you want a detailed description with pictures of every step and misstep, read on:

Previously I mentioned that it seems to not be possible to add visual states through the Blend designer when you edit a template. In other words you can’t record new visual states, you have to type in the VisualStateManager xaml that defines the VisualStateGroups, etc. That now makes sense to me, as I discuss at the end of this blog, but when the programmer creates the initial templated control it would be nice for her or him to be able to add the visual states by recording them in Blend and anyway, I already wrote the code.

The first part of this blog demonstrates how I went about it:

1. Add the visual components that will make up the templated control to MainPage and add Visual States and Transitions in Blend design view.

2. Create a Silverlight Templated control.

3. Insert the UI from 1 into 2 with a single cut and paste from MainPage.xaml to Generic.xaml, thereby defining the default UI for your new templated control.

But first I want to discuss the mechanics of a templated control, at least as it relates to what I’m about to demonstrate, because I think it makes everything else easier to understand.

Styles and ControlTemplates

Because the emphasis is always on editing templates, the Style / ControlTemplate relationship can be confusing initially. When you first create a templated control, it needs a default ControlTemplate. Now there may be a way to specify a default ControlTemplate, but the way Visual Studio does it is to create a default Style and include a ControlTemplate within the Style, making it the default ControlTemplate. To create new ControlTemplates you edit a copy of the original and save the new version, but in the process a new Style Resource is created which is wrapped around the ControlTemplate Resource. So when you want to create a new version of the Eye control’s UI called KlingonEye, you create a Style named KlingonEye which encapsulates a ControlTemplate containing the xaml that creates the visual representation of KlingonEye, all in Blend design view of course.

So when you use Visual Studio to add a Silverlight Templated Control to the project. It adds a new unnamed Style resource, linked to the new class through its TargetType, to Generic.xaml, which is a Resource Dictionary. The new Style contains a ControlTemplate skeleton to be populated with the xaml that defines the appearance of the control – no different than the xaml on MainPage or in a UserControl – this xaml is just being encapsulated in a way that copies can be easily modified and packaged in new Styles by designers working in Blend design mode.

The new Style is recognized as the default Style because it’s in Generic.xaml.

In addition to the Style Resource entry in Generic.xaml the new class is created with the name you specify and initialization code is added to the constructor to link its default Style to the Style Resource just added to generic.xaml.

For instance in my example I create a templated control named Eyeball. After I create the control through Visual Studio:

We get this entry in Generic.xaml

    <Style TargetType="local:Eyeball">
        <Setter Property="Template">
            <Setter.Value>
                <ControlTemplate TargetType="local:Eyeball">
                    <Border Background="{TemplateBinding Background}"
                            BorderBrush="{TemplateBinding BorderBrush}"
                            BorderThickness="{TemplateBinding BorderThickness}">
                    Border>
                ControlTemplate>
            Setter.Value>
        Setter>
    Style>

And this in Eyeball.cs

namespace ooNaEyeDevelopment
{
    public class Eyeball : Control
    {
        // The constructor. The first line that sets the default type was inserted when Visual Studio
        // was used to create a Silverlight Templated Control named "Eyeball"
        public Eyeball()
        {
            this.DefaultStyleKey = typeof(Eyeball);
        }
}

Here’s how these two find each other:

1. The Eyeball constructor, when it sets this.DefaultStyleKey to typeof(Eyeball) is saying I want my default style to be the default style for the Eyeball class.

2. In Generic.xaml, when the Style says the TargetType is “local:Eyeball”, it’s saying I am a style that can be applied to the the Eyeball class.

3. Because it’s in the Generic.xaml and because it is unnamed, the style is the default style for “local:Eyeball”. Try putting in another unnamed style with the same TargetType and it either won’t compile or won’t run.

The ControlTemplate within the Style also has its TargetType set to “local:Eyeball”. Turns out that’s not required, at least in this case.

So, that’s the general mechanics of a templated control. To recap, you have a single cs file that defines the runtime behavior of the templated control, although you could probably inherit and apply base class Styles to the subclass. You have a default Style resource which defines the UI of the control through an included ControlTemplate. You can have as many alternate Styles to provide alternate UIs as you care to clone from the original or you can create them from scratch, although you don’t want to go nuts – the UI needs to stay consistent with the code-behind. To apply a different style, include a Style= attribute in the xaml.

Creating the Initial UI

My initial goal is to create a templated control, including visual states, without having to manually type in the VisualStateManager code. In my last blog I pointed out that I wasn’t able to add visual states to a templated control through the Blend designer. I could see and modify the existing states and transitions, but the icon for adding new states was disabled.

So what I’m going to do is:

1. Draw a couple of ellipses that represent an eye on MainPage, use GroupInto to put them in a Canvas.

2. In the Blend designer, create a visual state named ‘Dilated’ which will expand the size of the pupil.

3. In Visual Studio, create a Silverlight Templated Control named Eyeball. This creates Generic.xaml and some other required code.

4. Cut and paste the xaml from MainPage.xaml into the Eyeball ControlTempate in Generic.xaml

Here’s the eye…

… and MainPage.xaml

<UserControl
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 
    mc:Ignorable="d" xmlns:local="clr-namespace:ooNaEyeDevelopment" xmlns:ooNaControls="clr-namespace:ooNaControls" xmlns:System="clr-namespace:System;assembly=mscorlib" x:Class="ooNaEyeDevelopment.MainPage"
    d:DesignWidth="640" d:DesignHeight="480">
  <Canvas x:Name="LayoutRoot" Background="#FFF4EEEE" HorizontalAlignment="Left" Width="160">
    <Ellipse Fill="White" Stroke="Black" Height="72" Width="96" Canvas.Left="0" Canvas.Top="0"/>
    <Ellipse x:Name="ellipse" Fill="Black" Stroke="Black" Height="32" Width="16" Canvas.Left="40" Canvas.Top="20"/>
  Canvas>
UserControl>

Before we can add States we need State groups, so click on the ‘States’ tab, then on the ‘Add state group’ icon.

Give the state group a name, like ‘Common’ and click on the ‘Add state’ icon

Change the name to ‘Dilated’, click on the properties tab and change the ellipse properties as shown below.

Click on ‘Base’ when you’re done, then click on ‘Add State’ again. Name this state ‘Normal’, then click on ‘Base’ to turn off recording. Normal is the visual state of the object before any states are applied. We need it so there will be a state to go to when we want to remove the dilation.

Now we add transitions so the pupil will not expand to full dilation instantaneously. On the ‘Normal’ state, click the ‘Add transition’ icon and select ‘Normal => Dilated’

Enter .75. Don’t try to type in the ‘s’. Blend will ignore you if you type in the ‘s’. Here’s what it should look like after you type in .75.

Now add another transition for ‘Dilated => Normal’ and set it to .5. You should end up with what you see below.

Now if you click on the target state of either transition, ‘Normal’, or ‘Dilated’, a timeline will open up in Objects and Timeline. Click on the ‘play’ arrow that I have circled below and you can see the transition.

Wiring Up The Initial UI

Now we’re going to wire up a mouse button down event handler to trigger the state. To create the event handler:

1. Select the control that is the target of the event; give it a meaningful name. In this case we’re selecting the ellipse that represents the eye, so I’m naming it ‘Eye’.

2. Select the Properties tab.

3. Select the Events icon.

4. Double-click on the textbox next to the event you want to handle to take the default name for the method.

In the event handler call the VisualStateManager.GoToState method to go to the ‘Dilated’ state. Notice that the object passed to the GoToState method is ‘this’, meaning the UserControl named ‘MainPage’. I also want to point out that the second parameter to GoToState is the name of the state, which in this case is '”Dilated”. But, because the state name is a property of MainPage, we can pass in this.Dilated.Name. This gives us the advantage of Intellisense, meaning we can tell whether this is indeed a property on the object we think it is, but the real advantage is that if we spell the state name incorrectly the code won’t compile. Compare that to passing in “Dilate” and waiting until runtime to discover our state change isn’t working, and then having to track the problem down to the typo. I found out about using the state name instead of a raw string thanks to András Velvárt - no-more-magic-strings-with-visualstatemanager-gotostate.aspx, where he also shows you how to wire up an event handler when the animation is complete, access the storyboard, and other things you can do with the state name.

I also wired up a Eye_MouseLeave event to return Eye to the Normal state. One last thing to note, I also call GoToState in the MainPage constructor to go to the ‘Normal’ state. If I didn’t, then the first transition to Dilated would be instantaneous, because the .75 second transition is defined between Normal and Dilated, so we need to start in the Normal state for that transition to take effect.

namespace ooNaEyeDevelopment
{
    public partial class MainPage : UserControl
    {
        public MainPage()
        {
          InitializeComponent();
          VisualStateManager.GoToState(this, this.Normal.Name, true);
        }
        private void Eye_MouseEnter(object sender, System.Windows.Input.MouseEventArgs e)
        {
          VisualStateManager.GoToState(this, this.Dilated.Name, true);
        }
        private void Eye_MouseLeave(object sender, System.Windows.Input.MouseEventArgs e)
        {
          VisualStateManager.GoToState(this, this.Normal.Name, true);
        }

Let’s go ahead and encapsulate the eye in preparation for turning it into a templated control. Select the two ellipses. Right click on them, select GroupInto / Canvas.

Creating the Templated Control and Populating the ControlTemplate

This is where we create a templated control named Eyeball, described at the top of the blog under the discussion of Styles and ControlTemplates.

Now we’re going to copy the xaml from main page into the control template, with one small change. Here’s the xaml from MainPage, notice that the VisualStateManager code is outside the Canvas that encapsulates the two ellipses.


    
      ...
    
    
  Eye" Fill="White" Stroke="Black" Height="72" Width="96" Canvas.Left="0" Canvas.Top="0" MouseEnter="Eye_MouseEnter" MouseLeave="Eye_MouseLeave"/>
        ellipse" Fill="Black" Stroke="Black" Height="32" Width="16" Canvas.Left="40" Canvas.Top="20"/>

In the ControlTemplate, there is no outer Canvas to wrap around the VisualStateManager code, so we put it inside the Canvas that we used to group our Eyeball controls previously. It probably would have been simpler to forget the grouping and just include LayoutRoot as the copy from MainPage to Generic.xaml, but it’s not a big deal one way or another. The important thing is VisualStateManager code must be wrapped in a FrameworkElement.

 
local:Eyeball">
    
        
           ...
        
        Eye" Fill="White" Stroke="Black" Height="72" Width="96" Canvas.Left="0" Canvas.Top="0"/>
        ellipse" Fill="Black" Stroke="Black" Height="32" Width="16" Canvas.Left="40" Canvas.Top="20"/>

Now if we edit the [Eyeball default] style (1) template (2), we can see that the visual states and transitions are visible in the states window (3).

Wiring The Templated Control Event Handlers to Invoke the States – Psych!!!!

However, the code to invoke these states is back in MainPage.xaml.cs. We need to wire up new event handlers in the Eyeball class, so let’s do it the same way we did on MainPage.

But what’s this? We select the ‘Eye’ ellipse (1), the Properties tab (2), and the Events icon (3), but there are no events. Just this discouraging message (4).

The problem is that the visual elements and the code no longer share the same class, so there is no way to wire the events at design time, by which I mean binding the events in xaml, as in this example from MainPage.xaml. The MouseEnter and MouseLeave attributes were inserted when we selected the “Eye” under Objects and Timelines, selected Properties/Events, and then double-clicked on the textboxes for those events.

<Ellipse x:Name="Eye" Fill="White" Stroke="Black" 
     ...
     MouseEnter="Eye_MouseEnter" MouseLeave="Eye_MouseLeave"
/>

And the two event handlers were inserted in MainPage.xaml.cs:

private void Eye_MouseEnter(object sender, System.Windows.Input.MouseEventArgs e)
{
}
private void Eye_MouseLeave(object sender, System.Windows.Input.MouseEventArgs e)
{
}

But now the c# code and the xaml are intentionally disconnected; they could have made it possible for Blend to wire-up the events at design time, but probably not a good idea. Adding event handlers to xaml in a template just seems wrong; probably because it would introduce a dependency between the template and the code. There’s no guarantee that a class that inherits from Eyeball will implement the event handlers, which would break any templates that contained event binding attributes.

Wiring The Templated Control Event Handlers to Invoke the States The Easy Way – No Really, I’m Not Kidding this Time

So the events must be wired up at runtime. First I want to show you the very simplest way to do that, without reference to Parts and States.

The Control class supports Mouse Events and any events not handled by the component element defined in the ControlTemplate will bubble up to the Eyeball class, so we can just add Event Handlers to the Eyeball Object events. We know the visual state names, so we can go to those states in the event handlers. The drawbacks are

(1) We have to hard-code the visual state names

(2) We detect events over the whole control surface, not the individual element where the event occurred.

namespace ooNaEyeDevelopment
{
    public class Eyeball : Control
    {
        // We no longer have design-time visibility of the VisualStates, so we just have to use the raw strings. 
        // It's always a good idea to use constants, but the code will still compile if we spell one wrong.
    const string NORMAL_STATE_NAME = "Normal";
        const string DILATED_STATE_NAME = "Dilated";
        public Eyeball()
        {
            this.DefaultStyleKey = typeof(Eyeball);
            // In general I like to do almost everything in the the 'loaded' event. It's not always necessary, but if
            // you get in the habit then you won't forget and put code in the constructor that shouldn't be run until the
            // object is loaded.
            this.Loaded += new RoutedEventHandler(Eyeball_Loaded);
        }
        void Eyeball_Loaded(object sender, RoutedEventArgs e)
        {
            // Instead of handling events on the "Eye" ellipse we're handling them on the entire control. We can do
            // this because the Control call supports Mouse event handling in expectation that a UI will be attached
            // through a control template. The events then bubble up from the elements in the Control template, so any 
            // MouseEvents on EyeContainer, Eye, or Pupil will end up being handled by the Eyeball class.
            this.MouseEnter += new MouseEventHandler(Eyeball_MouseEnter);
            this.MouseLeave += new MouseEventHandler(Eyeball_MouseLeave);
            // We try to go to the Normal state, but this won't work because the template has not been loaded yet
            VisualStateManager.GoToState(this, NORMAL_STATE_NAME, true);
        }
        void Eyeball_MouseLeave(object sender, MouseEventArgs e)
        {
            // We're passing a string directly instead of a VisualState Name property, because we don't have a VisualState reference
            VisualStateManager.GoToState(this, NORMAL_STATE_NAME, true);
        }
        void Eyeball_MouseEnter(object sender, MouseEventArgs e)
        {
            VisualStateManager.GoToState(this, DILATED_STATE_NAME, true);
        }
    }
}

Another shortcoming of this code is that the call to go to the Normal state in Eyeball_Loaded will have no effect. The Control class still has to wire up the ControlTemplate, and since the VisualStateManager xaml is in the ControlTemplate, the Normal State is not defined yet. Fortunately we can determine when it is available because the OnApplyTemplate method is called by Control when it wires up the code to the xaml in the ControlTemplate. We always call base.OnApplyTemplate anytime we override this method, but the point here is the Normal state is now defined. Note that the third parameter is false. This tells GoToState whether to use transitions or not. It doesn’t really matter in this case, but we are initializing at this point, not going from one state to another, so we specify false, which I should have done in the example above.

public override void OnApplyTemplate()
{
    base.OnApplyTemplate();
    VisualStateManager.GoToState(this, NORMAL_STATE_NAME, false);
}

Wiring The Templated Control Event Handlers to Invoke the States The Parts and States Way

So this is as far as we can go without Parts and States, or I should say, as far as we can go while pretending we don’t know the names of the visual elements. First of all, the Parts and States attributes are for Blend’s benefit, so they can be shown in the Parts panel. So for the Eyeball class code that works with the elements it’s neither here nor there whether the Parts and States model is used. Second of all, the names used both in the Parts and States attributes and by C# to access the elements are manually typed in. The upshot is that you can spell the name wrong and the compiler wont catch it. And best practices call for ignoring any missing parts if at all possible and continuing without them, which means you’ll only be able to tell you spelled the name wrong if you notice that some particular visual element is missing, either a part or a transition most likely, so pay attention to spelling and check that first if something doesn’t work. Use constants so you only have one opportunity to misspell each name.

So, assuming we spell the names right, the Eyeball class can get and bind the visual elements at run-time, which it must do for more sophisticated behavior, such as detecting Mouse Events on the “Eyeball” ellipse instead of just anywhere on the entire templated control. References to the individual elements, including the VisualStates, can be retrieved with calls to GetTemplateChild(). passing the name of the element, such as (FrameworkElement)GetTemplateChild(“Eye”), or (VisualState)GetTemplateChild(“Dilated”).

Let’s start by giving our elements names that we will use in the TemplatePart attribute entries in Eyeball.cs and making sure they match the names we use when we call GetTemplateChild().

Then create the TemplatePart attributes in Eyeball.cs. Note the use of constants.

namespace ooNaEyeDevelopment
{
    [TemplatePart(Name = Eyeball.EYE_CONTAINER, Type = typeof(FrameworkElement))]
    [TemplatePart(Name = Eyeball.EYE, Type = typeof(FrameworkElement))]
    [TemplatePart(Name = Eyeball.PUPIL, Type = typeof(FrameworkElement))]
  
    public class Eyeball : Control
    {
    public const string EYE_CONTAINER = "EyeContainer";
    public const string EYE = "Eye";
    public const string PUPIL = "Pupil";
    
        public Eyeball()
        {
            this.DefaultStyleKey = typeof(Eyeball);
        }
    }
}

Build the project; now when you edit the template if you click on Parts and States (1), you’ll see the names appear (2) and that they match the names you gave the elements (3).

Now to wire-up the events. everything I could say is pretty much covered in the comments. We’re back to using VisualState name properties, but we still have to spell the state names correctly or we won’t get the VisualState reference when we call GetTemplateChild, which as I may have mentioned, will not be caught by the compiler :

namespace ooNaEyeDevelopment
{
    // Use constants for the names here, for Blend to see, and for actually accessing the elements
    [TemplatePart(Name = Eyeball.EYE_CONTAINER, Type = typeof(FrameworkElement))]
    [TemplatePart(Name = Eyeball.EYE, Type = typeof(FrameworkElement))]
    [TemplatePart(Name = Eyeball.PUPIL, Type = typeof(FrameworkElement))]
    public class Eyeball : Control
    {
        // The element names
        public const string EYE_CONTAINER = "EyeContainer";
        public const string EYE = "Eye";
        public const string PUPIL = "Pupil";
        // The visual state names
        public const string DILATED_STATE_NAME = "Dilated";
        public const string NORMAL_STATE_NAME = "Normal";
        // To hold references to the visual elements we need to access
        FrameworkElement _EyeContainer = null;
        VisualState _DilatedState = null;
        VisualState _NormalState = null;
        // The constructor. The first line that sets the default type was inserted when Visual Studio
        // was used to create a Silverlight Templated Control named "Eyeball"
        public Eyeball()
        {
            this.DefaultStyleKey = typeof(Eyeball);
            this.Loaded += new RoutedEventHandler(Eyeball_Loaded);
        }
        void Eyeball_Loaded(object sender, RoutedEventArgs e)
        {
            // Normally we'd wire up events here, but in a templated control the parts are not yet assecible,
            // so we do it in OnApplyTemplate();
        }
        void Eyeball_MouseLeave(object sender, MouseEventArgs e)
        {
            // Any missing parts or states should be ignored
            if (_NormalState != null)
                VisualStateManager.GoToState(this, _NormalState.Name, true);
        }
        void Eyeball_MouseEnter(object sender, MouseEventArgs e)
        {
            if (_DilatedState != null)
                VisualStateManager.GoToState(this, _DilatedState.Name, true);
        }
        public override void OnApplyTemplate()
        {
            // Since we override this method, we have to call it on the class we inherited from
            base.OnApplyTemplate();
            // Get references to the parts we need to access
            _EyeContainer = (FrameworkElement)GetTemplateChild(EYE_CONTAINER);
            _DilatedState = (VisualState)GetTemplateChild(DILATED_STATE_NAME);
            _NormalState = (VisualState)GetTemplateChild(NORMAL_STATE_NAME);
            // Initialize the state to Normal
            if (_NormalState != null)
                VisualStateManager.GoToState(this, _NormalState.Name, false);
            // Wire up the mouse events on the "Eyeball" ellipse
            if (_EyeContainer != null)
            {
                _EyeContainer.MouseEnter += new MouseEventHandler(Eyeball_MouseEnter);
                _EyeContainer.MouseLeave += new MouseEventHandler(Eyeball_MouseLeave);
            }
        }
    }
}

This programmatic access to VisualStates opens up all kinds of possibilities. For one thing, you now have access to the storyboard, so you can add an event handler to be called when the animation(s) complete. It’s as simple as this:

public override void OnApplyTemplate()
{
    ...
    _DilatedState = (VisualState)GetTemplateChild(DILATED_STATE_NAME);
    if (_DilatedState != null)
        _DilatedState.Storyboard.Completed += new EventHandler(Storyboard_Completed);
    ...
}
void Storyboard_Completed(object sender, EventArgs e)
{
    MessageBox.Show("Fully Dilated");
}

You can even change or replace the storyboard / animations programmatically, but with great power comes great responsibility. One of the main virtues of Visual States is that they can be manipulated by the designer. I’m not really sure when it would be appropriate to modify them at run-time except possibly by using behaviors so the designer can specify properties to control what the changes are. For instance, the duration of a transition may be set depending on run-time conditions, but the designer should be able to control what values to use. As an example, how long does it take for a Seeker to go from the passive state to the chasing state if his energy level is 50%? Specify that relationship and other conditions in a behavior and the designer can specify, at design time, the duration value to be used at runtime.

Or so it seems to me. I’m still trying to sort out the implications in my own mind.

Instantiating the New Templated Control

So, onwards. We can now add an Eyeball templated control to MainPage. If necessary open it up by selecting it under the Solution (1), clicking on design mode (2), clicking on the Resources tab (3), Displaying the styles in Generic.xaml (4), and clicking on the [Eyeball default] style and dragging it onto the page (6).

Creating Clones of the Default Control Template and Modifying The Visual States

And now we get to the point, changing the Visual States in Blend by creating new ControlTemplates. Actually, we’ll be creating new Styles that wrap around the ControlTemplates.

There are two ways you can go about this, with two different results. In our case, we want to create a new copy of the ControlTemplate wrapped in the Eyeball default style so we can modify it to make alternative versions of the Eyeball UI. In order to apply that new template it’s best to put it in a new Style resource, and as it turns out, sometimes when we select ‘Edit Template / Edit a copy…’, we end up with a new style wrapped around our new copy of the template. But notice I said sometimes, which is important, because the other times we end up just with a copy of the ControlTemplate with no style wrapped around it.

When this happens you may not notice, or at least I don’t, until it’s inconvenient to fix. I’ve ended up with the template in my Default Style pointing to a new ControlTemplate resource, which is a real pain to fix, so it’s best to pay attention to what you’re actually editing. Hopefully this will help you avoid at least this one gotcha:

The Way You’d Probably Pick but Probably Don’t Want

First I’ll show you the approach you’d most logically pick but that you probably don’t want, as you end up with a new ControlTemplate resource but no new Style:

Select Generic.xaml (1), design view (2), Resources tab (3), Generic.xaml resources (4), [Eyeball default] Edit Resource (5), right-click Style (6), select ‘Edit a Copy…’ (7)

And here’s what you’ll see:

As you can see, it clearly states ‘Create ControlTemplate Resource’, but if you’ve ended up with a new Style after a similar chain of selections, you might not notice that the caption is different this time, proceed, and end up with at best a ControlTemplate Resource that you’ll have to manually wrap in a style and at worst an altered [Eyeball default] in generic.xaml.

The Way You Probably Do Want

Now I’ll describe the way to end up with a new style wrapped around a ControlTemplate and try to make clear the difference from what we just tried. Then I’ll demonstrate.

The answer is to select an instantiated Eyeball templated control. After that the steps are pretty much identical. The difference:

(Above) I selected a Style resource that can be applied to an Eyeball and edited a copy of the ControlTemplate inside that Style.

(Below) I’m selecting an Eyeball instance and editing a copy of the ControlTemplate wrapped inside the Style that is applied to the Eyeball. In this case it’s the default style.

Since we need an instantiation, we go to MainPage.xaml (1), select design view (2), right-click the Eyeball object (3) select ‘Edit Template / Edit a Copy…’

And sure enough, the first thing we do is create a new Style Resource:

I went ahead and changed the name to ooNaEyeStyle and created a new ResourceDictionary named Eyeball Dictionary.xaml. The other two options would stick the xaml in App.xaml (available to entire application) or the current page. A Resource Dictionary can be moved from project to project.

So, why the difference in results when we selected edit a copy of the template in both cases? There’s probably a reason, but I just haven’t run across it yet. On the face of it it seems pretty arbitrary. I guess they needed some way to let you create a named ControlTemplate Resource sans Style, and this is how they provided it.

And in the case where you do create a new Style, it’s kind of weird how you go about it. The selection you make is to edit a copy of the template. The result is a new style wrapped around the template. But that’s probably what you really want. Why? Because within a Style, the Template is just another property, so if you put your new ControlTemplate inside a new Style, then you can conveniently include other properties inside the style that will be applied at the same time. So although the emphasis is constantly on ‘edit a copy of the template’, when the template is actually applied, it will be through the style created as you see above. I probably go overboard on this, but it took me a lot of inadvertent trial-and-error (I thought I knew what I was doing but I did not) before I could keep track of where I was and what I was editing fairly consistently.

So after we hit OK we’re presented with the following. We’re editing a style (1) named ooNaEyeStyle (2) in EyeballDictionary.xaml (3), and we see three breadcrumbs (4) with the one named ‘Template’ currently selected:

The breadcrumbs let you move between levels and edit each one, which can be confusing if you’re not used to it, and even if you are:

So, moving on, I select the Eye component (1) in Objects and Timeline. The ‘Template’ Breadcrumb caption changes to ‘Eye’ (2). Parts are visible in the Parts panel (3), and if I select the Properties tab (4) I can see the Eye properties.

So we make a few simple changes and end up with something like this:

You can check out what the Eyeball control looks like with the ooNaEyeStyle applied by clicking on the [Eyeball] breadcrumb (1) or clicking on the Edit Level icon a couple of times (2).

And this is what you should see:

This is because when Blend creates the new style, it also applies that style to the Eyeball object you selected initially, so instead of just an Eyeball object you’re seeing:

32" Canvas.Top="96" Style="{StaticResource ooNaEyeStyle}"/>

Let’s take it out for a spin:

Well the good news is that the changes worked, and so does the event handler hooked up the the Storyboard completed event; the bad news is that the Dilated state is messed up. Fortunately that’s easy to fix:

Select the Dilated state (1), which turns on Dilated state recording (2). Select the Pupil element (3) and the Properties tab (4). Change the Top property to 16 (5) and to make things a little more interesting, throw in a rotation of 180 (6).

To be honest, I took the transitions out because I messed them up when I originally tried to add the changes. I accidentally edited the transitions instead of the state and I couldn’t seem to straighten it out. Since the original transitions were so simple I just deleted them and now I’m going to add them back in. If you don’t mess up like I did, you shouldn’t have to. At any rate, if I select the Dilated transition (1), the timeline opens and I can select the play button (2) to see the transition play. If I click on the Normal transition above I can see it play the other way. So I’m able to confirm that my rotation plays out in both directions.

So if the rotation is set on the Dilated state, and not the transition, and if you’re wondering why the Angle is set to 180 when the Dilated transition is selected, I did too, until I looked at the timeline and realized it reflects the angle at the end of the transition. It’s tricky recording states and transitions. Usually you want to make sure you’re on a state and not a transition when recording is on. You would only record a transition if you wanted some visual change to happen in only one direction. So you have to pay attention to the recording state – I’ve had to delete transitions more than once because it’s easier than trying to back out the edits. Get in the habit of clicking on Base to get out of recording state when you’re done.

Also, you don’t want to be recording the Normal state. If you find you want to change the appearance after a transition to Normal, then get out of recording entirely and click on the object in Objects and Timeline to edit its base appearance. Normal should normally reflect the object before any states were applied, although I’m sure there are exceptions that I haven’t thought of.

I added another couple of Eyeballs with a style I derived from ooNaEyeStyle. I call it SeekerEyeStyle. The lower one is dilated. Notice how I can layer on effects. The stock Eyeball just enlarges the size of the pupil. The ooNaEyeStyle adds in pupil rotation. Then SeekerEyeStyle adds color change to the pupil and the eye and counter rotation and enlargement of the eye itself. So you could have a whole ‘taxonomy’ of styles, such as

1. Default Style (Naked Eyeball)

2. Primate

3. Human

4. Child

Notice that every variation was done through the blend designer. I didn’t even have to edit any xaml files.

Ok, I think that’s enough. If you’re wondering why I didn’t cover the ‘States’ part of ‘Parts & States’, it’s because so far Blend has supported everything I need to do with States, so I’m still trying to figure out what adding TemplateVisualState Attribute entries would add, maybe they’re not long necessary in Blend 3. Here’s an example from a blog by Karen Corby, from a series that I highly recommend, even though it’s for Silverlight 2.

http://scorbs.com/2008/06/23/parts-states-model-with-visualstatemanager-part-3-of-4/

[TemplateVisualState(Name="Sunny", GroupName="WeatherStates")]
[TemplateVisualState(Name="PartlyCloudy", GroupName="WeatherStates")]
[TemplateVisualState(Name="Cloudy", GroupName="WeatherStates")]  
[TemplateVisualState(Name="Rainy", GroupName="WeatherStates")]

Finis

Hopefully this project has shown you how to easily create templated controls with visual states and how to create variations by copying and modifying ControlTemplates in Blend. I understand now why Blend won’t let you create new Visual States when editing a template. The class has no way of knowing about this new state, so how will it be invoked? And maybe that’s why you need Visual Studio to create a Templated Control in one step. You can do it in Blend by creating a class and adding the necessary code to linked it up to the default style in Generic.xaml, which you’d also have to add manually. But the designer should ordinarily not need to add the initial templated control. The original control is created by the programmer at which time the default style and Control Template for the control are created. It’s up to the designer to supply the UI by populating the ControlTemplate in the default state, and to create variations on the UI by cloning new Styles that wrap ControlTemplates with new and different xaml, visual states, and transitions. However the one shortcoming is that the visual states need to make it into the ControlTemplate somehow, and it should be up to the programmer to put them there, because it’s the programmer who defines what states the C# runtime code handles. My example provides a way to do that without typing it in manually.

But that’s a minor point. The important thing is that with templated controls the designer’s control over the UI is infinitely extensible, all through Blend and without touching any xaml directly, but always with that option.

The project contains some UserControls and templated controls where I was experimenting with making the individual elements in the ControlTemplate templated controls in themselves. So the pupil would be a templated control that knows how to dilate itself. That works fine, except it’s unable to keep itself centered. That’s where run-time manipulation of the state transitions could come in. The “post-Dilation” center point would be calculated at run time and a transform would be modified accordingly. Feel free to check them out and do what you want with them.

The exciting concept to me is to have a framework of intelligent templated controls, so that each has the intelligence built in to handle the appropriate tasks. Such as an identi-kit with an infinitely flexible set of facial parts, each with the intelligence to arrange itself in the appropriate visual configuration. Eyebrows that arch. foreheads that furrow, mouths that smile and frown. And faces that can adopt expressions such as surprise or anger by telling each component part to go to the appropriate state. I hope to take advantage of that concept as I convert the ooNaBoreans to templated controls.

Download Code:

http://www.adefwebserver.com/Richard/ooNaEyeDevelopmentv2/ooNaEyeDevelopme_v2.0.zip

Seeker Sidebar 3 – Parts and States

Sun, 17 Jan 2010 03:02:19 GMT

Live Example:

http://www.adefwebserver.com/Richard/SeekerPartsAndStates/SeekerPartsAndStatesTestPage.html

I’d like to acknowledge that posts by Karen Corby made it possible for me to get to this point in understanding Parts and States.

http://scorbs.com/2008/06/11/parts-states-model-with-visualstatemanager-part-1-of/

In this blog I’m going to show you how to create a multi-part templated control with visual states, then how you can manipulate those parts and states in Blend.

If you’ve been following along, you know that the Seeker inherits from a base class named ooNaThing, who provides basic ooNaThing functionality, so ordinarily it would be ooNaThing that would inherit from Control, but for this demo I’m just going to create a custom control named BigSeeker that inherits from Control directly.

The best way to do this for our purposes is through Visual Studio. There may be an equivalent in Blend, but I don’t know what it is. We’re going to create a Silverlight Templated Control. This not only creates our BigSeeker class, but also creates a file named Generic.xaml, which contains the default ControlTemplate implementation for our new class. And as you will see, it adds code to the BigSeeker class constructor to hook up the C# code to the xaml code in Generic.xaml.

So, with the solution open in Visual Studio, right click on the project, in this case SeekerPartsAndStates, in Solution Explorer and select Add / New Item, which will bring you to the following dialog:

After you click Add, you should see something like this. Generic.xaml has been added to the themes folder and the BigSeeker class is defined in the new file BigSeeker.cs.

In the BigSeeker Constructor, the BigSeeker default style is linked to the style in Generic.xaml, through the BigSeeker class. The TargetType of both the Style and the ControlTemplate is “local:BigSeeker”. Typically a ControlTemplate is wrapped in a Style. This allows a Style and all the properties it defines to be applied simultaneously with the ControlTemplate it defines as one of those properties. If you end up with a ControlTemplate that isn’t wrapped in a style, you’ve probably made a mistake in selecting what to edit.

Now we’re going to open the project in Blend and you’ll see how Blend lists this un-named style as the default style of BigSeeker.

Open the project in Blend.

Click on Resources, then click the arrow next to Generic.xaml. You can see that [BigSeeker default] is a resource. In this case, it’s a Style Resource wrapped around a ControlTemplate, as I described above.

So, in the picture above, the cursor is over the icon above the ‘Edit resource’ message. Click there to begin adding a default UI to BigSeeker.

I won’t show you the screen that comes up, there’s not much to see, and anyway, we selected the style, what we really want to edit is the ControlTemplate wrapped inside it. There are at least two ways to get there:

Note the breadcrumb at the top of the screen; this is what we get if we click it:

Or we can go through the Style in the Objects and Timeline menu:

This is one of those points where if you don’t pay attention to what you’re editing it can be too late when you realize later it wasn’t what you thought, so let’s review where we are.

1. We created a new templated control named BigSeeker.

2. We want to define the UI for BigSeeker.

3. We know the UI is defined in Generic.xaml so we click on the Resources tab and then the arrow next to Generic.xaml.

4. We select the icon next to [BigSeeker default] to edit the BigSeeker default style.

5. Now we are about to Edit the [BigSeeker default] current template, meaning the template in effect when the [BigSeeker default] style is applied.

That’s what we want to do, and as Davy Crockett said, “Make sure you’re right and go ahead”. Davy, known to many of you as Daniel Boone, was deeper than people give him credit for. Kill you a grizzly bear when you are only three and you’re typecast for life, or if you’re Fess Parker.

The suspense must be killing you, so go ahead and select Edit Current.

Nothing much to see except that Template now appears under Objects and Timeline, and it apparently contains a Border. Let’s look at the xaml.

    <Style TargetType="local:BigSeeker">
        <Setter Property="Template">
            <Setter.Value>
                <ControlTemplate TargetType="local:BigSeeker">
                    <Border Background="{TemplateBinding Background}"
                            BorderBrush="{TemplateBinding BorderBrush}"
                            BorderThickness="{TemplateBinding BorderThickness}">
                    Border>
                ControlTemplate>
            Setter.Value>
        Setter>
    Style>

I don’t think this example is going to get into TemplateBinding, but as far as I understand it, in this case, if the control that is bound to the Template has a Background, BorderBrush, or BorderThickness property, that property will carry through from the control to the template. For instance if the TargetType was RadioButton and the background property of the RadioButton is set, then the Background of my custom representation of a RadioButton, as defined in the ControlTemplate, will have its background property set to the same value.

For more go here: http://msdn.microsoft.com/en-us/library/ee341447(Expression.30).aspx, and I recommend the Zune sample project that comes with Blend. You can find it under

C:\Program Files\Microsoft Expression\Blend 3\Samples\en\Zune3D

But we want to add our own UI, so let’s start by adding a panel, my preference being a Canvas.

Drag it right onto the Border object in Object and Timeline.

Add an ellipse to the Canvas and adjust its properties as shown above, adjust the canvas width and height to the same dimensions.

Notice I’ve zoomed in, I didn’t make the ellipse larger.

Add a couple of eyes on top of the body outline; ellipses do not contain other ellipses, all three are on the surface of the canvas. The eye ellipses are just positioned over the body. The Zindex of zero for all three defaults to our benefit because we added the eyes after the body.

Actually as it turns out I did increase the size after I made the screen shots above. I set the Height to 160 and the width to 100. The eyes remain the same.

Change the names of the seeker’s visual elements. These are the names that will identify the elements as UI Parts in the Parts and States Model.

In BigSeeker.cs, add the TemplatePart lines you see below. Put them outside the class definition.

 namespace SeekerPartsAndStates
{
    [TemplatePart(Name = "SeekerContainer", Type = typeof(FrameworkElement))]
    [TemplatePart(Name = "SeekerOutline", Type = typeof(FrameworkElement))]
    [TemplatePart(Name = "LeftEye", Type = typeof(FrameworkElement))]
    [TemplatePart(Name = "RightEye", Type = typeof(FrameworkElement))]
  
    public class BigSeeker : Control
    {
        public BigSeeker()
        {
            this.DefaultStyleKey = typeof(BigSeeker);
        }
    }
}

After you do that, build the project. Then in the Parts panel you should see the following. It works because the Name in each TemplatePart matches the name of the corresponding visual element. Notice that each TemplatePart is defined as a FrameworkElement. I hear you asking, since the TemplatePart attributes don’t have any effect on the C# code, what difference does it make?

I think, but I haven’t tried testing it out, so I could be wrong, that you need to define this type at the highest level where it supports interaction with your code. Everything I do is supported by FrameworkElement, so that’s the type I define, for both Canvas and Ellipse. This gives designers maximum flexibility in re-defining the interface, but keep in mind if you change to a more specific type in subsequent versions it will break existing code that relies on the contract you establish in the parts list, so it’s a tradeoff. Or so it seems to me at this point.

We should be able to create an instance of our BigSeeker now. Bring up MainPage on the design surface. Click on the Resources tab at the top right and click the arrow to the left of Generic.xaml. You should see [BigSeeker default].

Click on the name, not the icon, and drag to the design surface, you should end up with this:

Now I think we’re at the point where we can edit the template and create an alternate visual representation of BigSeeker.

So right-click on the seeker, Edit Template / Edit a Copy

Give the new style a Name. Notice it’s a style. That’s good, the style wraps the ControlTemplate. If it’s not a style you’ve gone wrong somewhere. I’ve done it and ended up with an un-wrapped ControlTemplate and other bloopers, but I can rarely re-trace my steps.

As soon as you create the new style it’s available under Resources.

If I drag the style onto the design surface…

… I now have a default BigSeeker and a BigSeeker with the BigSeekerMutant1 style applied. Let’s look at the xaml:

<UserControl
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 
    mc:Ignorable="d" xmlns:local="clr-namespace:SeekerPartsAndStates" x:Class="SeekerPartsAndStates.MainPage"
    d:DesignWidth="400" d:DesignHeight="480">
  <Canvas x:Name="LayoutRoot" Background="White" Margin="50,0,-104,0">
    <local:BigSeeker Canvas.Left="90" Canvas.Top="144" Style="{StaticResource BigSeekerMutant1}"/>
    <local:BigSeeker Style="{StaticResource BigSeekerMutant1}" Canvas.Left="286" Canvas.Top="168"/>
 Canvas>
UserControl>

What the what? They both have style BigSeekerMutant1 applied. But we selected edit a copy of the template. Why is this affecting the original BigSeeker? Turns out Blend applies the new style to whatever object you select to get the copy from. I think there’s a way to remove the style ‘visually’, but I’m just going to edit it out in the xaml. (Later I remembered you can just drag [BigSeeker default] from the Resources menu onto the Seeker to change him back to the default style. I’ve blogged about it. Sigh.)

So, we have a new version names BigSeekerMutant1, or more precisely I should say we have a new style named BigSeekerMutant1 that applies a particular control template. So what can we do with it? Let’s find out.

Start by clicking on the icon to the right of BigSeekerMutant1

Edit the Current Template.

Click on Parts, and you’ll see the screen above, where you now have access to the parts. You can see what they are, you can click on them to show which part each corresponds to onscreen and whether or not they are currently assigned. You can edit the element properties as you normally would. You can add and remove elements from Objects and Timeline as you normally would, which means you can replace any of the Parts.

Let’s say we want to replace the SeekerOutline with a Rectangle. Delete the current SeekerOutline. Add a Rectangle to SeekerContainer, then right-click on it and choose Make Into Part of BigSeeker / SeekerOutline:

Set the properties of the new SeekerOutline, including setting the ZIndex to –1 to make the eyes visible:

Or you can cut to the chase and just change the ellipses to Rectangles in xaml, as I did here for the eyes:

            <Canvas x:Name="SeekerContainer" Height="160" Width="100">
              <Rectangle x:Name="LeftEye" Fill="White" Stroke="Black" Height="16" Width="10" Canvas.Left="37" Canvas.Top="16"/>
              <Rectangle x:Name="RightEye" Fill="White" Stroke="Black" Height="16" Width="10" Canvas.Left="56" Canvas.Top="16"/>
              <Rectangle x:Name="SeekerOutline" Fill="#FFF62727" Stroke="Black" Height="160" Width="100" Canvas.ZIndex="-1"/>
            Canvas>

And presto-changeo!!!

And back on Main Page:

So this is pretty huge when you think of it. All I did was map the names of the individual elements to TemplatePart attributes so Blend is able to see them. That’s it, four lines of code. Also notice I can change ellipses to rectangles, I think that’s because I defined the TemplateParts as FrameworkElements instead of Ellipses.

Shockingly, it seems you can’t visually create visual states on ControlTemplates. You can see the states, but the ‘create’ icon is grayed out. The only way I know how to do it is to manually add the xaml as Karen Corby blogs about. I’m going to experiment with different ways to add the visual states before my next blog, such as creating them on a control that has the style applied, then cut and paste the results to the ControlTemplate in Generic.xaml or wherever. As a matter of fact, in the first version of BigSeeker, I created the ellipses right on MainPage, chose GroupInto to put them inside a Canvas, ultimately to be ‘SeekerContainer’. Then I created the Silverlight Templated Control through Visual Studio, which creates Generic.Xaml and the rest. Then I just cut and pasted the Canvas (SeekerContainer) and its contents into the ControlTemplate in Generic.xaml.

I bring this up because for the blog I thought I would show you how to create the UI directly on the default style, but I think it was actually easier going the cut and paste route.

Anyway, as I say, next time will be about VisualStates in the context of ControlTemplates.

Download Code:

http://www.adefwebserver.com/Richard/SeekerPartsAndStates/SeekerPartsAndStates.zip

The Seeker: Sidebar 2 – Blendable Seeker via ControlTemplate

Wed, 13 Jan 2010 03:45:35 GMT

Live Example:

http://www.adefwebserver.com/Richard/TemplatedSeeker/TemplatedSeekerTestPage.html

Probably the most significant benefit of using a ControlTemplate to contain your object’s UI is that the appearance can then be managed by designers without ever touching a line of code. Maybe I feel that way because I’m anxious to get past this visual stuff and back to what the ooNaCreatures can do, not how they look, which kind of proves my point. Anyway, to prove my claim that the Well-Templated Seeker can be changed visually without touching any code, I’ll demonstrate:

Here we are in MainPage.xaml with a seeker named defaultSeeker in the design window.

We right-click on defaultSeeker and choose to edit a copy of its template.

You’ll see the following dialog. Give the new resource a name and select where to save it. I like using a resource dictionary because it feels less messy and in this case it makes sense because I can easily move the resources between projects.

Select VisualMe, which is the name of the Ellipse control, in the Objects and Timeline list and the Properties tab on the far right.

Change the color to a Prey shade of green and set the height to 40.

Because we were working on defaultSeeker in MainPage, if we take a look now we find that he’s been decorated with a SeekerInPreysClothing style.

<Canvas x:Name="ooBerCanvas" Height="600" Width="800" Background="Aqua" HorizontalAlignment="Left" VerticalAlignment="Top">
    <ooNa:Seeker x:Name="defaultSeeker" Canvas.Left="48" Canvas.Top="152" 
           Style="{StaticResource SeekerInPreysClothing}" />
Canvas>

Now I could just edit the xaml to remove the style, this is ‘defaultSeeker’ after all, and create a new ‘camouflaged seeker’ to apply it to but I want to keep this as visual as possible, so now I’m going to blow your mind.

On the right side of the screen, under the Resources tab, click the arrow on Generic.xaml to display the [Seeker default] style resource. Left click right on the name, not the icon, hold down the button, drag it over defaultSeeker and drop it.

Select ‘Style’ on the menu that appears:

Boom goes the dynamite!!! Thank yewww!!!

I’m not going to do the screen shots because it’s too repetitious, but to create another Seeker and apply the SeekerInPreysClothing style (it’ll be there in the download):

1. Either on the design page or right on Objects And Timeline, copy and paste defaultSeeker onto ooBerCanvas to create a copy with the default name of defaultSeeker_Copy. You’ll probably have to drag the copy off of the original so you can see both.

2. Now under the Resources tab on the right, click the arrow on SeekerResourceDictionary.xaml, and SeekerInPreysCothing will appear.

3. Drag it onto defaultSeeker_Copy just like you dragged [Seeker default] from Generic.xaml to transform defaultSeeker back to his normal self.

I just remembered there’s an easier way, skip steps 1 and 2 and do the drop onto some empty part of the design surface in step 3. Choose ‘Seeker’ on the menu that appears.

There are a bunch of ways you can essentially cut and paste the code to accomplish this. I chose to keep it visual to prove the point that the designer doesn’t have to touch a line of code.

Before I get to the code, I want to point out that this is only the most primitive usage of ControlTemplate. There’s also VisualStates for one, and if you implement parts and states, you can compose your object of many parts, all of which can be changed by the designer, or so I”m told. I hope to find out very soon.

So here’s the code:

First of all, the seeker is not just another pretty ooNaFace. He comes from hard-working base classes that support the Position property.

namespace TemplatedSeeker.ooNaClasses
{
    public abstract class ooNaThing : Control
    {
        // Dependency properties declaration
        public static readonly DependencyProperty PositionProperty =
            DependencyProperty.Register("Position",
                                           typeof(Point),
                                           typeof(ooNaThing),
                                           new PropertyMetadata(OnPositionChanged));
        public ooNaThing()
        {
            Position = new Point(Convert.ToDouble(this.GetValue(Canvas.LeftProperty)),
                                    Convert.ToDouble(this.GetValue(Canvas.TopProperty)));
        }
        public Point Position
        {
            get { return (Point)this.GetValue(PositionProperty); }
            set { this.SetValue(PositionProperty, value); }
        }
        private static void OnPositionChanged(object sender, DependencyPropertyChangedEventArgs e)
        {
            ooNaThing thing = sender as ooNaThing;
            if (thing == null)
                return;
            thing.SetValue(Canvas.LeftProperty, ((Point)e.NewValue).X);
            thing.SetValue(Canvas.TopProperty, ((Point)e.NewValue).Y);
        }
    }
}

Allow me to point out that ooNaThing inherits from Control, which puts us on a footing with Button and all those other uptown controls. This is the hook into the same mechanism you’d use to skin those controls.

So anyhoo, we work our way down (or up) to Seeker which has an actual UI – as a matter of fact, ooNaThing and ooNaBeing should be abstract classes, and I’ll change that just not right now. Anyway, when we get to that point we should create the class through the following selection in Visual Studio. There’s probably an equivalent in Blend, but I don’t know what it is. The reason you should do this is it creates generic.xaml for you and the style resource that wraps around your ControlTemplate, including a ControlTemplate skeleton for you to fill in.

And it generates the code in the Seeker constructor that sets this.DefaultStyleKey. This causes the default style for seeker to be the “ooNa:Seeker” type in generic.xaml. Notice that you have to change the inheritance from Control to your base class, in this case ooNaBeing.


namespace TemplatedSeeker.ooNaClasses
{
    public class Seeker : ooNaBeing
    {
        public Seeker()
        {
            this.DefaultStyleKey = typeof(Seeker);
        }
    }
}

And here’s generic.xaml. It turns out the seeker actually is just another pretty ooNaFace. Except for living off his ancestors, all he’s got going on is in generic.xaml.

You can see that the ControlTemplate is wrapped in a Style, and the TargetType for both is “ooNa:Seeker”. As far as I can tell, you can only put one Style/ControlTemplate per class in generic.xaml. By definition it is the default style for that class. Note that’s what it’s designated as in blend, ‘Seeker default’ – I didn’t give it that name. I just set up the Style/ControlTemplate you see below.

<ResourceDictionary
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:ooNa="clr-namespace:TemplatedSeeker.ooNaClasses">
    <Style TargetType="ooNa:Seeker">
        <Setter Property="Template">
            <Setter.Value>
                <ControlTemplate TargetType="ooNa:Seeker">
                    <Grid>
                        <Ellipse Fill="Red" 
                                 x:Name="VisualMe" 
                                 Stroke="Black" 
                                 Height="60" 
                                 Width="40"
                                 HorizontalAlignment="Left" 
                                 VerticalAlignment="Top" 
            />                 
                    Grid>
                ControlTemplate>
            Setter.Value>
        Setter>
    Style>
ResourceDictionary>

You still have to add the UI to generic.xaml – you can do it through Blend, I think I recall but I’m not going to get into that here. Poke around in the menu on the right hand side when you have generic.xaml selected and go for it.

Working with UserControl and the associated xaml file, then generic.xaml with classes that inherit from Control, then with new style resources to modify the appearance of those classes you’ll see that ControlTemplate, with just a little tweaking by the programmer, leverages UserControl so the UI can be managed by the designer; it’s UserControl with a UI that can be swapped-out at will. That’s pretty huge.

I threw in a MouseLeftButtonDown event handler to move both seekers to the click point just to prove that the Position property in ooNaThing is working.

Next time I’ll get into visual states and hopefully the whole “parts and states” gestalt.

Download code:

http://www.adefwebserver.com/Richard/TemplatedSeeker/TemplatedSeeker.zip

The Seeker: ooNaverse sidebar 1 – Replacing interfaces with Base Classes that inherit from UserControl

Mon, 11 Jan 2010 04:45:46 GMT

Live Example:

http://www.adefwebserver.com/Richard/ooNacontrols/ooNaControls.TestTestPage.html

ooNaverse sidebars are separate projects that focus on narrow issues within the ooNaverse. In this case, the demo just shows that a Position property can be implemented in an abstract base class (ooNaThing) with no UI that inherits from UserControl and in turn be inherited by a subclass (Seeker) that does define a UI (xaml file). Clicking on the page will cause the ooNaSeeker object to move to the click point by updating the Position property, which incidentally is a Dependency property and so will support animation of the ‘higher’ order class that inherits from it (Seeker). I provide the source mainly so you can have a working example where you can just lift the code if you want.

My goal right now is to allow designer access to the Seeker’s visual implementation, so I’m trying to convert the Seeker class to a templated control. I want to focus on just that aspect, so I’m doing it in a separate project from the Seeker. I’m hoping that blogging about it will help clarify the process, because I’ve been thrashing. I can make it happen, but I really want to understand, so I hope blogging about it will help. As you’ll see, I decided to break it into two parts by just describing how to inherit from UserControl and supply base class functionality at the same time.

For those who don’t know, the ooNaverse, ruled over by ooBer, is the Seeker’s plane of existence, possibly in a land called ooNa. The Seeker like all else in the ooNaverse, is an ooNaThing. I think, and I’m sure you’re all hoping, that’s enough ooNaThology to set the foundation for what I want to discuss.

If you’ve been following along you may know that I’ve been using interfaces to support the ooNaThing taxonomy. iSeeker inherits from IooNaBeing which inherits from IooNaThing. And of course there’s IooBer. MainPage implements IooBer, giving ooBer access to the main UI, and allowing ‘this’ to be passed to every Seeker as a reference to ooBer / IooBer.

For the Seeker, the problem with this approach is that the Seeker class has to implement every interface from IooNaThing through iSeeker. That would be ok, but the intent is that lots of different inhabitants of the ooNaverse inherit from IooNaThing and so forth, so every single one of them would have to implement all those interfaces. In this case, far better to inherit from classes that provide the functionality, instead of interfaces, which just define it.

I got into this issue because I want to make a point about when you don’t need a templated control but you still want to inherit from classes that provide functionality instead of implementing interfaces, which I’d say is any time you don’t need to let anyone monkey around with the visual representation – if you don’t need it, not using a templated control is a lot less work and easier to work with in Blend, so I think it’s useful approach to know. It’s how I would have implemented the Seeker originally if I’d known how.

The answer is to create a base class that inherits from UserControl. For instance, I want everything that inherits from ooNaThing at any level to support a Position property. In this test project, I call it unaThingLocal, and here’s the code.

namespace ooNaControls.Test
{
    public abstract class uNaThingLocal : UserControl
    {
        // Dependency properties declaration
        public static readonly DependencyProperty PositionProperty =
            DependencyProperty.Register("Position",
                                           typeof(Point),
                                           typeof(uNaThingLocal),
                                           new PropertyMetadata(OnPositionChanged));

        public uNaThingLocal()
        {
        }

        public Point Position         {
            get { return (Point)this.GetValue(PositionProperty); }
            set { this.SetValue(PositionProperty, value); }
        }

        private static void OnPositionChanged(object sender, DependencyPropertyChangedEventArgs e)
        {
            uNaThingLocal thing = sender as uNaThingLocal;
            if (thing == null)
                return;
            thing.SetValue(Canvas.LeftProperty, ((Point)e.NewValue).X);
            thing.SetValue(Canvas.TopProperty, ((Point)e.NewValue).Y);
        }

}
}

uNaThingLocal is all implementation with no UI. It lives in uNaThingLocal.cs and there is no XAML file. Notice that it is abstract, because without a UI, there is no point in creating a strictly uNaThingLocal object. I could have an unaBeingLocal class, also abstract, that would support the rudimentary methods I have defined for uNaThings that are alive, such as die(this), but in this case I just make uNaSeekerLocal inherit from uNaThingLocal. And, for this test case, uNaSeekerLocal is all UI except for the unaThingLocal.Position property it inherits, which is the whole point of this demonstration. Here’s the XAML in uNaSeekerLocal.xaml. Notice that the opening tag starts with

<local:uNaThingLocal x:Class="ooNaControls.Test.uNaSeekerLocal"
    xmlns:local="clr-namespace:ooNaControls.Test"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
    Width="40" Height="60">
    <Grid x:Name="LayoutRoot">
        <Ellipse Fill="#FF85AF7A" 
                 x:Name="VisualMe" 
                 Stroke="Black" 
                 Height="60" 
                 HorizontalAlignment="Left" 
                 VerticalAlignment="Top" 
                 Width="40" RenderTransformOrigin="0.5,0.5">
          <Ellipse.RenderTransform>
            <TransformGroup>
              <ScaleTransform/>
              <SkewTransform/>
              <RotateTransform Angle="40"/>
              <TranslateTransform/>
            TransformGroup>
          Ellipse.RenderTransform>
        Ellipse>
    Grid>
local:uNaThingLocal>

And of course unaSeekerLocal inherits from uNaThingLocal:

namespace ooNaControls.Test
{
    public partial class uNaSeekerLocal : uNaThingLocal
    {
        public uNaSeekerLocal()
        {
            InitializeComponent();
        }
    }
}

Here’s the instantiation of uNaSeekerLocal in MainPage.xaml

    <Canvas x:Name="ooBerCanvas" Height="500" Width="800" Background="Aqua" HorizontalAlignment="Left" VerticalAlignment="Top">
      <local:uNaSeekerLocal x:Name="seeker" Canvas.Left="100" Canvas.Top="200" />
    Canvas>

And here’s the proof in MainPage.xaml.cs that the Position property on uNaThingLocal is accessible through uNaSeekerLocal.

void LayoutRoot_MouseLeftButtonDown(object sender, MouseButtonEventArgs e)
{
seeker.Position = e.GetPosition(null);
}

So there you have it. Just inherit from UserControl in an abstract base class with no XAML. Provide whatever functionality makes sense in your base classes. When you’re at the level where you want to provide a UI, make the XAML opening tag refer to your base class instead of UserControl.

Download code:

http://www.adefwebserver.com/Richard/ooNacontrols/ooNaControls.Test.zip

The Seeker Version 4: Dependency Properties and Animation

Sun, 03 Jan 2010 20:31:47 GMT

Live example:

http://www.adefwebserver.com/Richard/TheSeekerSiteV4/Default.html

I made a lot of changes to The Seeker, but probably the most important technically is the addition of Dependency Properties and more specifically Dependency Properties to support Animation.

The Simulation

First I’ll describe the changes to what goes on in ooNaWorld, where everything and everybody is an ooNaThing, or will be when I’m done. At any rate, Seekers chase and eat prey. Seekers start out as blue, change to red when chasing, turquoise in close pursuit, and black when they pause to eat. When a Seeker has eaten a specified number of prey it reproduces. Prey start out as pale green, turn purple when being pursued, and dark green after they have escaped pursuit.

ooBer Control Panel

All things ooNa are under the control of ooBer, master of the ooNaverse. You can communicate with ooBer through the ooBer Control Panel, which I’ll describe from left to right:

Left Mouse Button: Radio buttons determine whether left mouse click creates Prey or Seeker

Seekers/Prey: The panel just below Left Mouse Button shows number of current Seekers and Prey.

Seeker Reproduction: Determines whether Seekers reproduce and number of prey required to reproduce.

Eat Time: Number of seconds that Seeker will pause to eat.

Switch Prey: If clicked, Seeker will turn from current prey to chase one that is closer, otherwise it will chase current prey until caught.

Collision: Determine whether to do true hit-testing or declare a hit at a specified proximity. Proximity runs faster when there are a lot of players on the field.

Seekers: When Max is exceeded all Seekers are killed except the new-borne. Speed Min/Max sliders set speed range of newly created seekers.

Prey: If Max is exceeded, Auto-Create Prey does not fire. Auto-Create Prey determines whether to periodically create new prey, how often, and how many.

Clear Seekers/Prey Buttons: Clear all Seekers or Clear All Prey.

Dependency Properties and Animation:

Dependency properties and Animation go hand-in-hand because to animate a custom object, you create Dependency Properties that will be set repeatedly during the animation, such as Position and Heading. Then you create an animation, give it access to those properties, specify the duration and off you go. The animation will literally step your object through the sequence by adjusting the dependency properties you specified.

But let’s back up and talk about Animations of non-custom objects. For instance:

        public static void MoveTo(FrameworkElement mover, Point destination, Duration duration, System.EventHandler callBack)
        {
            DoubleAnimation xAnimate = new DoubleAnimation();
            xAnimate.Duration = duration;
            xAnimate.To = destination.X;

            DoubleAnimation yAnimate = new DoubleAnimation();
            yAnimate.Duration = duration;
            yAnimate.To = destination.Y;

            Storyboard sbMove = new Storyboard();
            sbMove.Duration = duration;
            sbMove.Children.Add(xAnimate);
            sbMove.Children.Add(yAnimate);

            Storyboard.SetTarget(sbMove, mover);
            Storyboard.SetTargetProperty(xAnimate, new PropertyPath("(Canvas.Left)"));
            Storyboard.SetTarget(yAnimate, mover);
            Storyboard.SetTargetProperty(yAnimate, new PropertyPath("(Canvas.Top)"));
            // When the animation is done, call this handler to re acquire the target and
            // start the next animation
            sbMove.Completed+=callBack;
            sbMove.Begin();
        }

The animation can use the existing FrameworkElement properties Canvas.Left and Canvas.Top to step the FrameworkElement object across the screen. Note that it’s actually two DoubleAnimations, one for each property, Canvas.Left and Canvas.Top, which are doubles, hence the name DoubleAnimation. For each step in the animation new values for Canvas.Left and Canvas.Top are calculated and used by the animation to set those properties.

This was the animation Seeker used up until this version. But I wanted to add rotation so at the same time I changed the position animation to use a PointAnimation, which repeatedly sets a Point dependency property to step the object through the animation.

Here’s the code for the PointAnimation to do the same move. All I have to do is set the duration, the end point, the target object (seeker) and the dependency property the Animation will set to move seeker step by step across the screen

PointAnimation _seekerPositionAnimation = new PointAnimation();
_seekerPositionAnimation.Duration = seeker.ooNaStoryboard.Duration;
_seekerPositionAnimation.To = WayPoint;
Storyboard.SetTarget(_seekerPositionAnimation, seeker);
Storyboard.SetTargetProperty(_seekerPositionAnimation, new PropertyPath("Position"));

Here’s the Seeker class Position Property

// The property must use SetValue and GetValue.

       public Point Position
        {
            set { this.SetValue(PositionProperty, value); }
            get { return (Point)this.GetValue(PositionProperty); }
       }

// Here’s where we register the dependency property, note it’s outside any method. We pass the name of the property “Position”, the type, Point, the typeof the owning object, Seeker, and a pointer to an event handler to be called when the property changes.

        public static readonly DependencyProperty PositionProperty =
            DependencyProperty.Register("Position",
                                            typeof(Point),
                                            typeof(Seeker),
                                            new PropertyMetadata(PositionChanged));

// Here’s where we do whatever it is we need to do when the property changes. We have to do it through an event handler because the Dependency Property mechanism won’t allow it to be called from the Property setter itself. As you can see, this gives me a hook so I can perform code at every step of the animation.

        private static void PositionChanged(object sender, DependencyPropertyChangedEventArgs e)
        {
            Seeker seeker = sender as Seeker;
            if (seeker == null)
                return;
            seeker.SetValue(Canvas.LeftProperty, ((Point)e.NewValue).X);
            seeker.SetValue(Canvas.TopProperty, ((Point)e.NewValue).Y);
            if (seeker.MoveLogic != null)
            {
                Prey prey = seeker.AcquiredTarget;
                Double xDistance = (seeker.Position.X + seeker.ActualWidth / 2) - (prey.Position.X + prey.ActualWidth / 2);
                Double yDistance = (seeker.Position.Y - (prey.Position.Y + prey.ActualHeight / 2));

                // Sum the square of the two opposite sides
                Double oppSides_Squared = (xDistance * xDistance) + (yDistance * yDistance);
                // The straight line distance is the square root of the result
                Double distance = Math.Pow(oppSides_Squared, 0.5);
                seeker.GoToState(distance < 50 ? seeker.CloseToPrey.Name : seeker.PursuingPrey.Name, false);
                if (seeker.MoveLogic.InterceptProximity > 0 && seeker.AcquiredTarget != null)
                {
                    if (seeker.MoveLogic != null && distance < seeker.MoveLogic.InterceptProximity)
                    {
                        seeker.MoveLogic.InterceptTarget(seeker);
                    }
                }
                else if (Common.TargetCollision(sender as Seeker) && seeker.MoveLogic != null)
                {
                    seeker.MoveLogic.InterceptTarget(seeker);
                }
            }
        }

At the same time, I run the animation to do the rotation:

DoubleAnimation _seekerHeadingAnimation = new DoubleAnimation();
_seekerHeadingAnimation.Duration = seeker.ooNaStoryboard.Duration;
_seekerHeadingAnimation.To = bClockwise ? newHeading : newHeading - 360;
Storyboard.SetTarget(_seekerHeadingAnimation, seeker);
Storyboard.SetTargetProperty(_seekerHeadingAnimation, new PropertyPath("Heading"));

Seeker has a dependency property named “Heading”. The animation above will step the Heading property through all the values between whatever it’s set to right now up through the value I specified in _seekerHeadingAnimation.To. That Heading property will set the Seeker Rotate Transformation to each of those values, stepping the rotation through gradual steps at the same time as the position is being adjusted in gradual steps.

Visual State

In the PositionChanged Method above, I call seeker.MoveLogic.InterceptTarget(seeker) if I detect a collision between seeker and prey. Let me show you that method and briefly discuss VisualState at the same time. First of all, notice that I save the seeker position and angle before I stop the Storyboard, then use the saved values to reset them. That’s because when you call Stop on storyboard it resets the animation. There may be a way to avoid this and I just haven’t found it yet.

Next is some syntax that may not seem familiar. EatingPrey is a Seeker VisualState. I can use the name of the VisualState to access the Storyboard, which lets me set the duration and set an event handler to be called when the storyboard completes. Maybe you’re saying “What storyboard?”. A Storyboard, as far as I know is always included in a VisualState . Running the storyboard, including the animations that are also generated when the VisualState is created, is how the transition is made from one VisualState to another. The beauty is that just through the name of the VisualState I’m able to access the associated StoryBoard and even add an event handler.

The code called by seeker.MoveLogic.InterceptTarget(seeker) is from the ooNaMove class, which implements IooNaMove:

public void InterceptTarget(Seeker seeker)
{
     if (seeker.Eating)
         return;
     seeker.Eating = true;
     seeker.AcquiredTarget.Die();
     Point startPosition = seeker.Position;
     Double startAngle = seeker.Heading;
     seeker.ooNaStoryboard.Stop();
     seeker.Position = startPosition;
     seeker.Heading = startAngle;
     seeker.EatingPrey.Storyboard.Completed += new EventHandler(seeker.EatingPrey_Completed);
     seeker.EatingPrey.Storyboard.Duration = new Duration(TimeSpan.FromSeconds(seeker.SecondsToEat));
     seeker.GoToState(seeker.EatingPrey.Name, false);
}

Here’s the “Eating Prey” VisualState defined in Seeker.xaml

EatingPrey">
  
    00:00:00" Duration="00:00:05.0010000" Storyboard.TargetName="VisualMe" Storyboard.TargetProperty="(Shape.Fill).(SolidColorBrush.Color)">
  00:00:00" Value="#FF000016"/>

And to finish off the cycle, here’s the event handler that’s called when the EatingPrey Storyboard completes. Note the first thing I do is un-subscribe from the event, again using the name of the VisualState to get to the storyboard. After I digest my meal, I go to my normal state and get rid of my recent kill in order to prepare for the next one.

public void EatingPrey_Completed(object sender, EventArgs e)
   {
       this.EatingPrey.Storyboard.Completed -= EatingPrey_Completed;
       Eaten++;
       if (Eaten >= PreyQuota)
       {
           if (PreyQuota > 0)
           {
               Point createPoint = Position;
               if (createPoint.X < 300)
                   createPoint.X += 50;
               else
                   createPoint.X -= 50;
               if (createPoint.Y < 300)
                   createPoint.Y += 50;
               else
                   createPoint.Y -= 50;
               if (OOBER != null)
                   OOBER.CreateSeeker(createPoint);
           }
           Eaten = 0;
       }
       GoToState(Normal.Name, false);
       Eating = false;
       AcquiredTarget = null;
   }

Download code:

http://www.adefwebserver.com/Richard/Seekerv4.0.zip

This Seeker Behaves

Sun, 27 Dec 2009 06:37:41 GMT

Live example: http://www.adefwebserver.com/Richard/TheSeekerBehaviorv1Site/

Ok, Silverlight is starting to freak me out a little bit. I thought it would take a couple of days to figure out how to translate my Seeker behaviors into Silverlight behaviors. After going down several paths that had too many details about things I wasn’t interested in right now, I found Falling Snow in Silverlight on Kirupa.com and the scales were lifted from my eyes in about 15 minutes. I was afraid behavior would be restricted to some short-term action-reaction thingie but not at all. After reading Kirupa’s description of a behavior’s parasitic behavior and seeing the FallingSnowBehavior literally take over a Canvas control I became hopeful I could write a Hunt behavior that could take over my Seeker control, or at least its reaction to a SightingEvent.

I modified Seeker Version 1 to try this out. First I modified the Seeker so the reaction to a SightingEvent is a call to the React method on an iSighting interface...

More...

The Seeker – Version 3: The Rise of ooBer

Fri, 25 Dec 2009 20:02:22 GMT

See it live: http://www.adefwebserver.com/Richard/TheSeekerSitev3/

After ooNaLife, I intended to just post my latest version of The Seeker so I could move on to focusing on Silverlight issues. But I had to indulge myself by using interfaces to supply the Seekers with “brains”. But that’s cool, I think it got me more in a good place to look at the MVVM model (judging from the little I know now).

Let me explain the on screen changes to what I now call ooNa and then I’ll get on to the code. Seekers are now red ellipses. When a Seeker ‘catches’ a Prey, the Prey disappears from the screen...

More...

ooNaLife – Game of Life Implementation

Wed, 23 Dec 2009 04:11:51 GMT

See the live example here: http://www.adefwebserver.com/Richard/ooNaLifeSite/

After Seeker 2, I wanted to add a control panel, but I wasn’t clear how to tack one on. So far I’ve just slapped everything up onto the main UI, LayoutRoot, so I decided to write a new app and divide everything up from the start...

More...

The Seeker – Version 2.0

Sat, 19 Dec 2009 05:41:24 GMT

Version 2.0 keeps some continuous action going by introducing Prey for the seekers to follow around. The Prey has a true graphic representation, a green circle created by choosing an Ellipse from the Asset panel, then drawing it with the shift key held down so it will be constrained to circular dimensions. The Seeker now watches its target after initially becoming aware of it through an event – which is generated when a new prey is created through a left mouse click...

More...

The Seeker – Version 1.0

Fri, 18 Dec 2009 03:20:00 GMT

When I’m trying to learn any new language, framework, or the like, I often find myself frustrated because blogs and tutorials obscure the simple concepts I’m trying to understand with too much detail. My goal is to start very simply so that the programming concepts are laid-out in small, easy-to-understand chunks of code. Then with each version to expand the use of those concepts and add in some very simple examples of a few new ones.

I never get to do it on the job, but my favorite kind of programming is to create intelligent objects that interact onscreen. My first Silverlight project in that line is The Seeker. The seeker reacts to an onscreen event by moving towards it. In this case the event is the drop part of a drag and drop operation.

The important concepts are:

-    Publishing and consuming events
-    Programmatically adding and positioning controls on screen
-    Drag and drop
-    Animation / Storyboard
-    Internal Logic
-    Calculating distance onscreen

The images below show the starting positions, the seekers...

More...

Richard Waddell

Seeker Sidebar 4 – Styles, Control Templates, and Visual States

Styles and ControlTemplates

Creating the Initial UI

Wiring Up The Initial UI

Creating the Templated Control and Populating the ControlTemplate

Wiring The Templated Control Event Handlers to Invoke the States – Psych!!!!

Wiring The Templated Control Event Handlers to Invoke the States The Easy Way – No Really, I’m Not Kidding this Time

So the events must be wired up at runtime. First I want to show you the very simplest way to do that, without reference to Parts and States.

Wiring The Templated Control Event Handlers to Invoke the States The Parts and States Way

Instantiating the New Templated Control

Creating Clones of the Default Control Template and Modifying The Visual States

The Way You’d Probably Pick but Probably Don’t Want

The Way You Probably Do Want

Finis

Seeker Sidebar 3 – Parts and States

The Seeker: Sidebar 2 – Blendable Seeker via ControlTemplate

The Seeker: ooNaverse sidebar 1 – Replacing interfaces with Base Classes that inherit from UserControl

The Seeker Version 4: Dependency Properties and Animation

The Simulation

ooBer Control Panel

Dependency Properties and Animation:

Visual State

This Seeker Behaves

The Seeker – Version 3: The Rise of ooBer

ooNaLife – Game of Life Implementation

The Seeker – Version 2.0

The Seeker – Version 1.0

- Publishing and consuming events - Programmatically adding and positioning controls on screen - Drag and drop - Animation / Storyboard - Internal Logic - Calculating distance onscreen

- Publishing and consuming events
- Programmatically adding and positioning controls on screen
- Drag and drop
- Animation / Storyboard
- Internal Logic
- Calculating distance onscreen