But sometimes, you (and by “you”, I mean me) need help figuring out how to create a PART for a control because, let’s be honest, you don’t do it all the time and no one has a blog post on just this little part of control building.

If you’re wondering what a PART is, here’s a short explanation: A PART is a naming convention that allows a control (code) to make a contract with the control template (XAML) in Silverlight. The control says to the template, “I’m going to be doing something programmatic with this part, so it better be there”. The template responds, “Here’s that part you wanted.”

I not actually talking down to anyone, this is really how my brain works.

There are basically five steps in creating a PART. I think you can actually do it in less, but I’m trying to follow what I think is proper coding practice. In this tutorial, we’re going create parts out of a Button and also a Storyboard (partly because there are different ways to assign a PART if it is in located in the control resources like a Storyboard is).

Step 1: Define the control template parts you’ll need

Outside of the control class we need to add the TemplatePart attributes. Inside the class, we need to define the names of the UI objects we’re going to turn into parts as well as create some corresponding objects in the control so we can access those PARTs.

[TemplatePart(Name = MyControl.StoryboardString, Type = typeof(Storyboard))]
[TemplatePart(Name = MyControl.RootElementString, Type = typeof(FrameworkElement))]
[TemplatePart(Name = MyControl.ButtonString, Type = typeof(Button))]

public class MyControl : Control
{
    private const string StoryboardString = "PART_MyStoryboard";
    private const string RootElementString = "PART_RootElement"; 
    private const string ButtonString = "PART_MyButton";

    private Storyboard _targetStoryboard;
    private FrameworkElement _rootElement;
    private Button _targetButton;

What we’re going to do here is remarkably stupid because I don’t have the creativity right now to do something cool. When we press the button, we’ll play the storyboard. We need the RootElement because… you’ll see in a moment.

Step 2: Make sure you have a XAML template properly named to correspond with the part

We have three parts we’re getting here, so this is a stripped down template that just has the three PARTs named appropriately. If the names are not the same as the strings above, it will not work.

<StyleTargetType="local:MyControl">
    <SetterProperty="Template">
        <Setter.Value>
            <ControlTemplate TargetType="local:MyControl">
                <Grid x:Name="PART_RootElement">
                    <Grid.Resources>
                        <Storyboard x:Name="PART_MyStoryboard">
                           <!– Whatever animations you want here –>
                       </Storyboard>
                    </Grid.Resources>
                    <Button x:Name="PART_MyButton" />                       
                </Grid>
            </ControlTemplate>
        </Setter.Value>
    </Setter>
</Style>

Step 3: Assign the XAML PART to the code PART in the OnApplyTemplate method

Now we just have to write a custom OnApplyTemplate method that will grab the XAML elements and assign them to objejcts within the control code. There are two key methods you’ll use. The first is GetTemplateChild, which will pull out any UI element in the XAML that is named and not in the resources.

If you want to get something in the resources, you need to refer to the UI element that holds those resources. This is why we needed the root element as a PART. So, enough of my blabbing… here’s the code:

public override void OnApplyTemplate()
{
    base.OnApplyTemplate();

    _rootElement = GetTemplateChild(MyControl.RootElementString) as FrameworkElement;
    //Make sure we actually got the template applied.
    if (_rootElement != null)
    {
        _targetStoryboard = _rootElement.Resources[MyControl.StoryboardString] as Storyboard;
        _targetButton = GetTemplateChild(MyControl.ButtonString) as Button;

        _targetButton.Click +=new RoutedEventHandler(_targetButton_Click);       

    }
}

Now we have all the PARTs assigned so we can do something like adding an event handler to the Button so that, when it is clicked, it runs the storyboard.

void  _targetButton_Click(objectsender, RoutedEventArgs e)
{
     _targetStoryboard.Begin();
}

And that’s how you add a PART… both in the regular XAML template and in the resources of the template.

As a case study, let’s look at an SVG file of the US counties. (You can find a link to the SVG here. Here is the file converted to XAML if you just want to download that and not mess with any of this other stuff. Special thanks to Nathan Yau of Flowing Data and @SimonRegenbogen for helping me find this.)

The SVG is about 1.6 MB, but when I convert it to XAML, it sees a size reduction of about 20-25%.

You’ll notice that the Adobe Illustrator-to-XAML export is about 100 KB smaller than the Expression Blend Illustrator Import. What’s the difference?

1. AI-to-XAML preserves path layers and grouping – In the native import version, all the paths are imported into a single Canvas. This makes it really hard to isolate paths and work with them individually. The AI export version groups into separate Canvases so that each state is it’s own canvas. Very handy.
2. AI-to-XAML preserves some metadata – all the paths in the AI-to-XAML version have a comment preceding the path that contains some (not all) of the naming metadata from the SVG file.
3. AI-to-XAML spaces code out better – Here is a sample of the data from the AI-to-XAML version:


And here is the same path in the native import.



You’ll notice three things: the first is the metadata (already noted). The second is that the export plug-in has spaced the paths to make them easier to read. The third is something you’ll notice if you’ve spent a lot of time working with XAML paths… the point data is spaced out in a way that makes it much more readable.  Overall a much better XAML experience.

4. AI-to-XAML maintains less path data fidelity – The AI-to-XAML converts to 3 decimal places, while the native import converts to 4 decimal places. But this isn’t necessarily a bad thing. Here is a corner of Sacramento County zoomed in 6400%.



Now let’s change the path data by a hundredth of a unit, from X=35.366 to X=35.376



The difference is almost imperceptible… even at this level of magnification. Changing it by a thousandth of a unit is going to make almost no difference that users will be able to see.

Conclusion: I’m going to continue using Mike Swanson’s Adobe Illustrator to XAML Export plug-in because it is awesome. If you don’t have or can’t afford Adobe Illustrator, the default import isn’t bad, but it is missing a good deal of potentially valuable functionality.

In some cases using a table (Grid) for a layout is not ideal, and if your moving over from Flex like I did, you may want to have something you’re familiar with. This post walks though how to simulate anchored layout in Sliverlight, using a single cell and applying alignment and margin properties to its elements.

The following example, built in Silverlight, illustrates the types of anchored positioning:

Example screen normal size

Example screen stretched

Here is the XAML for the layout of the screen above.

XAML for screen

One Cell, Many Possibilities

As you can see from the screenshots above, as the page is stretched, the elements stretch and retain their positions also. Normally this type of layout in Silverlight would require a Grid with 3 columns and 3 rows, and you would have to add the definitions for them as well as set the column and row properties for each element inside the Grid. To simplify how the page is layed out, only a single cell is needed, and instead the HorizonalAlignment, VerticalAlignment, and Margins are adjusted. A nice side effect of this type of layout, is the XAML used is significantly reduced. I’ll go through each element in turn and explain how it’s layout is simulated from Flex. On the left side of each explanation is the constraints as would be defined in Flex.

Header

Flex layout constraints for Header

The header of the page stays at the top and stretches left and right. In Flex a top, left, and right position for the Header would have been set. In Silverlight, the header of the page is anchored to the top using a VerticalAlignment of Top, and then stretches both left and right by using a HorizontalAlignment of Stretch. A fixed Height is set, and a left Margin of 100 is applied. <Border Background=”Red” Height=”50″ VerticalAlignment=”Top” HorizontalAlignment=”Stretch” Margin=”100,0,0,0″> <TextBlock Text=”Header” Style=”{StaticResource Number}” /> </Border>

Navigation

Flex layout constraints for Navigation

The navigation pane on the page stays vertically centered on the left. In Flex, the verticalCenter and left positions would be set for the Navigation. In Silverlight, VerticalAlignment is set to Stretch, and HorizontalAlignment is set to Left, with a fixed Height applied to the element. <Border Background=”Green” Width=”80″ Height=”200″ VerticalAlignment=”Stretch” HorizontalAlignment=”Left”> <TextBlock Text=”Navigation” Style=”{StaticResource Number}” /> </Border>

Body

Body layout constraints in Flex

The body of the page stretches in all directions while still leaving room for the other elements. In Flex, top, left, right, and bottom positions would be set. In Silverlight, a VerticalAlignment and HorizontalAlignment of Stretch is set, as well as Margins on all sides. <Border Background=”Orange” VerticalAlignment=”Stretch” HorizontalAlignment=”Stretch” Margin=”100,80,80,80″> <TextBlock Text=”Body” Style=”{StaticResource Number}” /> </Border>

Buttons

Flex layout constraints for Buttons

The buttons on the page are centered horizontally on the bottom. In Flex, the positions of bottom and right would be set. In Silverlight, VerticalAlignment is set to Bottom, and HorizonalAlignment is set to Center with a fixed Width and Height on the element. <Border Background=”Blue” Width=”200″ Height=”60″ VerticalAlignment=”Bottom” HorizontalAlignment=”Stretch”> <TextBlock Text=”Buttons” Style=”{StaticResource Number}” /> </Border>

Page

Flex layout constraints for Page

The page number is in the bottom right of the page. In Flex, a position on the bottom and right would be set. In Silverlight, VerticalAlignment is set to Bottom, and HorizontalAlignment is set to Right, with a fixed Width and Height applied to the element. <Border Background=”Purple” Width=”80″ Height=”60″ VerticalAlignment=”Bottom” HorizontalAlignment=”Right”> <TextBlock Text=”Page” Style=”{StaticResource Number}” /> </Border>

Summary

The use of the Grid layout can be simplified and simulate Flex anchored layout by only using a single cell, and applying alignments with margins. Standard absolution positioning can also be achieved within a single cell grid by applying a VerticalAlignment of Top, a HorizontalAlignment of Left, and then using left and top margins for x and y respectively. The translation from Flex anchored layout to Silverlight can be summarized by the table below:

 Just because we’re working in Microsoft technologies doesn’t mean we can’t throw a bone to our Mac friends. After all, they are the people we love, our cousins and our neighbors, and that irritating guy who is dating our daughter and can’t seem to shut up about how awesome his Mac is even though he’ll be long out of his program in musical costume design before he ever pays off his laptop …

Issues? I don’t have issues. Why do you ask?

Anyway, since Silverlight is a semi-ubiquitous technology, it would be nice if we could cater to all platforms and not make anyone feel left out. And nothing makes people feel more left out than when they expect their application to work one way and it doesn’t.

So, here’s a picture of what we’re going for.

As far as I’m concerned (and therefore as far as this tutorial is concerned) the important stuff is to make sure that the incremental buttons (the arrow buttons in the bottom right) are in the right place. We can deal with the color later.

OK, so let create our ScrollViewer (I’ll be using Blend exclusively for this). I tossed a button in it and made it small so we can see both of the ScrollBars.

Right click on the ScrollViewer in the “Objects and Timeline” section and go down to “Edit Control Parts (Template) -> Edit a Copy…”

You should have something that looks like this:

Let’s do the VerticalScrollBar first. Right click on it and go to “Edit Control Parts (Template) -> Edit a Copy…” Name it something memorable and you should get something like this:

This is actually easier than it looks. The unnamed rectangles and the path lay down the basic visual backbone for the ScrollBar and the rest of it runs like this:

VerticalSmallDecrease – The up button
VerticalLargeDecrease – The space between the up button and the VerticalThumb

VerticalThumb – The interface element that allows the dragging interaction of the scrollbar
VerticalLargeIncrease – The space between the down button and the VerticalThumb

VerticalSmallIncrease – The down button

The horizontal root in this template is strikingly similar.

So, let’s start by moving the VerticalSmallDecrease button down to the bottom above the VerticalSmallIncrease button. The magic here will happen in the VerticalRoot grid. (I highly recommend the Design/XAML split view for this one.) In the design view, our grid looks like this:

Ugly. However, in the XAML, it looks like this:

<Grid.RowDefinitions>
      <RowDefinition Height=”Auto”/>
      <RowDefinition Height=”Auto”/>
      <RowDefinition Height=”Auto”/>
      <RowDefinition Height=”*”/>
      <RowDefinition Height=”Auto”/>
</Grid.RowDefinitions>
<Grid.ColumnDefinitions>
      <ColumnDefinition/>
      <ColumnDefinition/>
</Grid.ColumnDefinitions>

Much easier. For the purposes of maintaining a coherent structure, drag the VerticalSmallDecrease in Objects and Timeline pane until it is between the VerticalSmallIncrease and the VerticalLargeIncrease. Next, change the third RowDefinition to “*”. You can do this in the XAML or by clicking on the “Auto” icon until it becomes a “*” icon. Change the fourth RowDefinition from “*” to “Auto”. When you do this, it won’t immediately act like an “Auto”. This is because Blend gives it an automatic “MinHeight” of whatever the current Height is. You can change that in the XAML (easiest move) or you can highlight that row by clicking just below the “Auto” icon until the row highlights in a semitransparent gray like so.

You may need to zoom in to do this. Once highlighted, the properties of the Row will show up in the Properties tab on the right. Change the MinHeight to 0.

Now we’ll need to change the Grid.Row properties of almost everything. Click on the items in the Objects and Timeline and change the Row property in the Layout section of the Properties tab like so:

VerticalLargeDecrease -> Row = 0
VerticalThumb -> Row = 1
VerticalLargeIncrease -> Row = 2
VerticalSmallDecrease -> Row = 3
VerticalSmallIncrease -> Row = 4

You’re done. With the Vertical part of the ScrollBar at least. You can do the same thing with the Horizontal part of it. Just move around the buttons, change the ColumnDefinitions and update the Column assignments. My best recommendation is to go back to the ScrollViewer template and assign your new ScrollBar template to the HorizontalScrollBar and then go back to editing the template from there.

Later on…

After a bunch of color tweaking, I have a scroll viewer in silverlight that looks like this:

I’m feeling OK with it. I’ve embedded what I have at this point below.

One of the things we had to do was swap out ControlTemplates so that we could display a caret to indicate ascending or descending lists. We ended up deciding on ControlTemplates over DataTemplates because the DataTemplates would only work for ListViews that had no custom DataTemplates for the headers. We’re doing all sorts of crazy stuff with our headers and we need to preserve our DataTemplates, so this wasn’t an option.

In any case, I was having no luck finding the resource when I named it this way:

<ControlTemplate x:Key="MyCustomControlTemplate" TargetType="{x:Type GridViewColumnHeader}">

I was using the following code to try and find the resource.

ControlTemplate myNewTemplate = (ControlTemplate)Resources["MyCustomTemplate"];

However, we were able to solve the problem by naming the resource this way

<ControlTemplate x:Key="{ComponentResourceKey TypeInTargetAssembly={x:Type local:MyCustomListView}, ResourceId=MyCustomControlTemplate}"
         TargetType="{x:Type GridViewColumnHeader}">

And then using this code to access it.

ComponentResourceKey myCustomTemplateKey = new ComponentResourceKey(typeof(SortableListView), "MyCustomTemplate");
ControlTemplate myNewTemplate = (ControlTemplate)this.TryFindResource(myCustomTemplateKey);

Just thought I’d pass it along.

Normally, I’ve been creating listviews that look like this:

<ListView x:Name=”MyListView”
               ItemContainerStyle=”{DynamicResource MyListViewItemContainerStyle}”>
    <ListView.View>
         <GridView ColumnHeaderContainerStyle=”{DynamicResource MyListViewHeaderStyle}”
                         ColumnHeaderTemplate=”{DynamicResource MyGridColumnHeaderTemplate}”> 

I did this because I didn’t know exactly how to assign these styles and templates to the ListView Style. In the style, ColumnHeaderContainerStyle and ColumnHeaderTemplate are not properties of the ListView, they are properties of the GridView… which you can’t create a style for.

Instead, you can encapsulate all the information above in the following style.

<Style x:Key=”CustomListViewStyle” TargetType=”{x:Type ListView}”>
      <Setter Property=”GridView.ColumnHeaderContainerStyle” Value=”{DynamicResource MyListViewHeaderStyle}” />
      <Setter Property=”GridView.ColumnHeaderTemplate” Value=”{DynamicResource MyGridColumnHeaderTemplate}” />
      <Setter Property=”ItemContainerStyle” Value=”{DynamicResource MyListViewItemContainerStyle}” />
</Style>

Problem solved.

The solution ended up being so easy in WPF that I thought I’d post it here.

I’m in a two-birds-one-stone mood, so we’ll do this for both the listview, which will also cover a more traditional scrollviewer. Let’s start with our ever friendly listview.

At the very sight of this thing, with a stylus in hand, your average lefty is thinking to him or herself “I wonder if I can do my work upside down?” Let’s show them that we love and accept them just as they are.

The first thing we’re going to do is create a new template for this sucker, so right click on your listview and go to “Edit Control Parts (Template) -> Edit a Copy…”

Now we’re looking at the standard listview template. Mine looks like this:

Let’s dig right into the ScrollViewer. If you’re doing this from the listview (like I am) then creating a template for the listview has already created a template for the scrollviewer. If you’re starting from a basic scrollviewer, you can pretty much start right here.

For the purposes of making this thing easy to work with in Blend, go ahead and set the HorizontalScrollBarVisibility and VerticalScrollBarVisibility to Visible.

And then “Edit Control Parts (Template) -> Edit a Copy…” (or “Edit Control Parts (Template) -> Edit Template” if it is available).

We are now looking at the guts of the ScrollViewer Control.

ListView ScrollViewer will look like this:

The normal ScrollViewer will look like this:

For our purposes, they’re functionally the same. It is actually a fairly simple control… basically just a Grid panel with the columns and rows set up like so:

<Grid.ColumnDefinitions>
      <ColumnDefinition Width=”*“/>
      <ColumnDefinition Width=”Auto“/>
</Grid.ColumnDefinitions>

<Grid.RowDefinitions>
      <RowDefinition Height=”*“/>
      <RowDefinition Height=”Auto“/>
</Grid.RowDefinitions>

The scrollBars are set up so that their visibility is tied to (duh) the visibility that is set on the control. But what this does is it means that when they are collapsed… they Grid reclaims the space that they were taking up.

Now… here’s the hilarious part… in order to make this ScrollViewer left handed, all you have to do is swap the Grid.Columns:

<Grid.ColumnDefinitions>
      <ColumnDefinition Width=”Auto“/>
      <ColumnDefinition Width=”*“/>
</Grid.ColumnDefinitions>

You’ve now switched the columns so that the left handed column is auto. Here’s a list of the Grid.Column realignments you’ll need to make:

Change Column to “1″:

• PART_HorizontalScrollBar
• All DockPanels (ListView only)
• PART_ScrollContentPresenter (ScrollViewer only)
• Corner (ScrollViewer only)

Change Column to “0″:

• PART_VerticalScrollBar

Basically, swap everything from in the two columns.

Done.

If you want to make this a more robust control, I recommend creating a ScrollViewer with an additional dependency property (IsSouthPaw or something). Make it so that your Grid has three columns:

<Grid.ColumnDefinitions>
      <ColumnDefinition Width=”Auto“/>
      <ColumnDefinition Width=”*“/>
      <ColumnDefinition Width=”Auto“/>
</Grid.ColumnDefinitions>

And then you can just create a trigger that swaps the column placement of your PART_VerticalScrollBar. Such a trigger will look something like this. And by “something”, I mean “exactly”.

<Trigger Property=”IsSouthPaw” Value=”True“>
      <Setter Property=”Grid.Column” TargetName=”PART_VerticalScrollBar“  Value=”0” />
</Trigger>

Go forth and make Ned Flanders proud.

By the way, I listen to pop punk whenever I write my tutorials and I just thought I should let Senses Fail know that they can probably get away with about 80% less “dying cat” screaming and still put out good music. You know… because they’re probably WPF programmers on the side and they’ll probably read this to solve all their left-handed scrollbar needs.

Part of the problem with styles and templates in WPF stems from the fact that Blend allows a wonderfully simply way of creating a copy of a template:

It then gives you something that looks like this:

<Style x:Key=”My_Template” TargetType=”{x:Type Button}“>
      <Setter Property=”Template“>
            <Setter.Value>
                  <ControlTemplate TargetType=”{x:Type Button}“>
                        <!– blah blah blah –>

So, from a usability point of view… I told it to create a Template and it created a style. I judged from this that styles and templates were roughly the same thing.

And I was confused.

So, first, I’ll try to explain styles and templates by explaining how they work and then I’ll draw an analogy that I hope is helpful.

Let’s say you have a button.

You can change all sorts of properties of that button… visibility, background, width, height, margins, border thickness, alignment, font, whatever.

If you have a dozen buttons and you want them all to have the same properties, you can create a button style that specifies those properties and assigns them across the board. You can edit a style in Blend by selecting your control, clicking in the menu: “Objects -> Edit Style -> Edit a Copy…“.

Style editing in the objects tab will look like this.

As you can see, there are no objects in the visual tree to play with… only properties to assign in the properties tab.

When you assign a property in Blend, your styles will save that assignment as setters and values. Let’s say we wanted all of our buttons to have green 18 point font  bold text. We could create a style that looked like this:

<Style x:Key=”GreenBorderButton” TargetType=”{x:Type Button}“>
      <Setter Property=”Foreground” Value=”#FF00FF00” />
      <Setter Property=”FontSize” Value=”18“ />
      <Setter Property=”FontWeight” Value=”Bold” />
</Style>

The styles can only define properties that belong to the control type that they are styling (which is defined in the “TargetType“). Also, styles can only give information for properties the control already has and only in the way that the control is already set up. For example, because there is no property for changing the corner radius of a button, you can’t change the corner radius of a button using a button style.

However, what if we want to change something about the button that we can’t change with the given properties? For example, let’s say we wanted to see all the text show up twice.

In order to do this, we need to make what I’m going to call “structural changes” to our control. Structural changes are changes in the actual guts of the control, changes to the base elements that make up the control. For this we need a control template.

Boiled down to their essence, templates are little chunks of XAML that are inserted whenever you use your control. When you right click on something and go to  “Edit Control Parts (Template) -> Edit a Copy…“, Blend takes the default XAML that makes up your control and places it in the resources so that you can change it at your whim.

You can get to the Control Template using the right-click method described at the top of this post. Your basic button template will look something like this:

<Style x:Key=”MyButtonStyle” TargetType=”{x:Type Button}“>
      <Setter Property=”Template” Value=”{DynamicResource MyButtonTemplate}” />
</Style>

<ControlTemplate x:Key=”MyButtonTemplate” TargetType=”{x:Type Button}” >
      <Microsoft_Windows_Themes:ButtonChrome x:Name=”Chrome” >
            <ContentPresenter />
      </Microsoft_Windows_Themes:ButtonChrome>
</ControlTemplate>

We can go in and add an additional ContentPresenter in here, like so:

<ControlTemplate x:Key=”MyButtonTemplate” TargetType=”{x:Type Button}” >
      <Microsoft_Windows_Themes:ButtonChrome x:Name=”Chrome” >
            <Grid>
                  <Grid.RowDefinitions>
                        <RowDefinition Height=”.5*” />
                        <RowDefinition Height=”.5*” />
                  <Grid.RowDefinitions>
                  <ContentPresenter Grid.Row=”0” />
                  <ContentPresenter Grid.Row=”1” />
            </Grid>
      </Microsoft_Windows_Themes:ButtonChrome>
</ControlTemplate>

And now our button shows all the content twice, one right on top of another.

The best way I’ve found to think about it is to think of your control as a car.

The dealer give the buyer a list of things that they can change about the car… interior color, leather or fabric seats, 4 or 6 cylinder engine… these are properties of the car… defined in the car “style”. (Basically, you can think of everything that you’re allowed to tweak at this website as the style of the car.)

<Style x:Name=”MySpecialCar” TargetType=”{x:Type Camry}” >
      <Setter Property=”ExteriorColor” Value=”Blue” />
      <Setter Property=”TransmissionType” Value=”5SpeedManual” />
</Style>

�
But let’s say that the buyer doesn’t want a normal seat… she wants a big comfy chair in place of the regular drivers seat. This is something outside of the scope of the list of things she was allowed to choose from, so they have to draw up new blueprints for making this new car. They have to create a new car “template”.

If our normal Camry blueprint looks like this:

<ControlTemplate x:Key=”MySpecialCarBlueprint” TargetType=”{x:Type Camry}“>
      <CamryFrame x:Name=”CamryFrame” >
            <Seat Type=”Drivers ” />
            <Seat Type=”FrontPassenger” />
            <Seat Type=”BackBench” />
      </CamryFrame>
</ControlTemplate>

We can go in and replace :

<Seat Type=”Drivers ” />

With

<Seat Type=”ComfyChair” />

You may also notice that, with this model we could get rid of all the other seats except the drivers seat or we could add 12 new rows of seats. We can change anything about the car because we’re down into the original car blueprint.

This is the basic difference between styles and templates.

• A style is a list of properties that can be assigned in bulk to a control.
• A template goes a big step further and actually defines the underlying structure of the control.

You may be asking: “So how do these two work together? And what is this Data Template think I keep hearing about?”

Given that this post is getting dangerously long already, I’m going to address those issues in a couple more posts on styles and templates.

I’ll end on this note: if you are working in WPF and you’re having trouble with styles and templates, please read all of these posts (as I get to them) and ask questions in the comments section. I’m pretty good about getting to the comments questions and if the question is big enough, I’ll write a whole post on it. There are few things more vital to a WPF developer/designer than to have a firm grasp on styles and templates. It is in this understanding that the power of WPF really comes out.

• Who’s The Boss? Property Priority in Styles and Templates (coming soon)
• Create Conditional Styles and Templates (With the Magic of Triggers) (coming soon)
• So How Do Data Templates Fit Into All This? (coming soon)

How can I get drop shadows into my application without killing my performance?

 It is, of course, easy as punch and pie to get drop shadows into your application. You can just use the Bitmaps Effects panel in the Appearance section:

For the love of God, please do not use the Bitmap Effects in the Appearance section!

If any developers found out that I told you to use BitmapEffects, they would hunt me down and cut off my fingers. This is because, while the Bitmap Effects in WPF are all sorts of cool, they make your computer break down into uncontrollable sobbing. Bitmap Effects hog system resources by requiring software rendering for render-heavy effects. There is no better way to slow down a perfectly good application than to give every other element a drop shadow.

But, what if you really really want to?

That is why there is this handy little thing called a “SystemDropShadowChrome”. The way to use it is to put the following namespace into your Window tag:

xmlns:dropShadow=”clr-namespace:Microsoft.Windows.Themes;assembly=PresentationFramework.Aero”
�
And then take the thing you want to have a drop shadow and wrap it in a SystemDropShadowChrome like so:

<dropShadow:SystemDropShadowChrome>
      <Grid x:Name=”MyElement” />
</dropShadow:SystemDropShadowChrome>

So what are we losing when we do this?

Normal bitmap dropshadows give you the following options:

And they conform to the item to which they are attached. It could be bannana-shaped… you would get a banana-shaped drop shadow.

But with SystemDropShadowChrome, you get a rectangle and the ability to choose the color of your drop-shadow and the corner-radius. That’s it. But that gives you a decent amount of room to work with. Consider what Robby Ingebretsen did in his example on SystemDropShadowChrome (magnified 2X):

We’ve got darker drop shadows, lighter drop shadows, colored drop shadows and a drop shadow with an irregular corner radius. This is flexible enough for pretty much any standard application control. Used in templates, you could even use this to give drop shadow to just one part of the control. In fact, my attention was first drawn to the use of the drop shadow in the Popup part of the ComboBox control.

You can change the drop shadow color using a standard color picker in the “Miscellaneous” section of the SystemDropShadowChrome properties in Blend:

This is also where you can find the “CornerRadius” property. In the XAML, they will look like this:

<dropShadow:SystemDropShadowChrome CornerRadius=”3,13,3,13” Color=”#71000000“>
      <Grid x:Name=”MyElement” />
</dropShadow:SystemDropShadowChrome>

With some creative styling, we can actually change the direction of the drop shadow. It’s easy enough to do if you’re just hacking away, but if you plan on using it seriously in an application, it requires some forethought and organization, so I’ll go into that in detail in a full post on changing the SystemDropShadowChrome direction. (coming soon)

When last we left our heroes, we has a couple problems. The first was that our items were either black text on a white background and ran together in a very un-designer-y way.

The second was that the selected item background makes your eyes bleed such a horrid blue color you’ll feel like Paul Atreides staring at a stone burner.

Was that a little too geek? My apologies.

Anyway, let’s do something to make this control a little more usable (as well as easier on our eyes).

Highlight your ComboBox and go up to the toolbar, selecting Object -> Edit Other Styles -> Edit ItemContainerStyle -> Edit a Copy…

We’re now in the ItemContainerStyle editing mode. I really just need some demarcation between the items, so I’m going to give the items a BorderBush with a gradient that has a nice blue at the top and fades down to transparency at the bottom. It looks something like this:

We will, of course, want our users to see this border, so let’s give the style a BorderThickness of 1 all around and a Margin of 4 to offer a little space. Our items now look like this:

Better… but we don’t see the trigger for that hideous shade of blue in the style, so we need to go somewhere else to change it. Right click on the Style and go to Edit ControlParts (Template) -> Edit Template

We can see that the template here is exceedingly dull… just a border surrounding a ContentPresenter. We like dull. Dull means it’s not complex. First, let’s do some polishing up… give that border a CornerRadius of 5. Keep in mind that this is Vista-based development… no sharp corners allowed.

Now, let’s kill that blue. Click on the “IsHighlighted = True” trigger at the top…

..and we can see the highlighted state. I changed the Background to a nice soft blue gradient (you can change it to a deep purple with a green bubble for all I care… it’s WPF, go nuts!) This would be great except that I can’t see the Foreground now, so let’s change that to make the text readable.

 I couldn’t figure out how to do this in the design mode, so find the IsHighlighted Trigger in the XAML and insert the bold text below:

<Trigger Property=”IsHighlighted” Value=”true“>
      <Setter Property=”Foreground” Value=”#FF001720“/>
      <Setter Property=”Background” TargetName=”Bd“>
      …

Now our ComboBox items look like this:

Much better.