Designer WPF

Several months back, I was doing some work for a company that was using WPF for a stylus based application. One of the things that they found they needed was a scrollbar that could be used by left handed people who would have to cover the entire screen with their left hand in order to scroll a traditional scroll viewer.

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.

This is a post that has taken months to complete, but addresses something that I don’t think I’ve seen sufficiently covered for anyone who is new to WPF. Resultantly, we’re going to go through it slowly and I’m officially begging for additional questions at the end.

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)

One of the questions I get most often from designers and almost never from developers is:

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?

Continue reading ‘WPF Drop-Shadows on The Cheap’ »

This is actually a continuation of my post on getting the ComboBox items to accept text wrapping, so I’ll be working from that point forward. If you’re coming fresh into this, you won’t be missing anything… but that is my explaination for the pictures containing wrapping text.

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.

Continue reading ‘How Do I Style The ComboBox Items?’ »

 The ComboBox is not the most complex of the WPF applications, but it can be a little tricky, so lets do a general overview post of it before we go into the specifics of how we’re going to make it work.

First of all, if you’re going to test your comboBox design, you should have it hooked up to an ItemsSource. Don’t have one? I have a tutorial in which I walk through attaching an RSS feed to your control. It was originally written for the ListView, but it will work fine for a ComboBox.

To start out… this is your standard ComboBox:

When working on a comboBox, you have a couple of options for the Items inside the ComboBox. If the options never change and are not data-driven, you can just toss come ComboBoxItems into it. Otherwise, you can connect it to some kind of ItemsSource (see the link above).

All of my examples are done with a data-driven ComboBoxes, but you should get the desired results if you run through the tutorials with ComboBoxItems.

First, a little bit about the structure of the comboBox.

Continue reading ‘The WPF Designers Guide to Styling The ComboBox’ »

Karl Shifflett points to a wonderful life saver of a feature that I didn’t know existed until now.

With Visual Studio 2008, the project is always trying to load the design view with the XAML view. I get very frustrated by this… if I wanted to see the design view, I would open Blend.

Apparently, if you’re in VS2008, you can go to “Tools -> Options…” in the resulting window, open up the “Text” option and scroll down to “XAML -> Miscellaneous” Check the box that says “Always open docuemnts in full XAML view”

 Yay.

I’ve been spending the past several days fighting with the ComboBox in an attempt to make it so something very simple: Wrap text inside the combo box. I’ve finally figured it out, so I thought I’d share.

OK, first of all, make sure that your ComboBox is hooked up to something, even if that something is some random RSS feed. I have a post that can help you with that over here. Bind your comboBox to the “Items” part of the New York Times RSS feed.

You need to do this because, if you do not, you will have to set the same data template to every single ComboBoxItem that you add to the ComboBox. And that’s just no fun.

Starting out, your ComboBox should look something like this:

 Right click on your ComboBox and select “Edit Other Templates -> Edit Generated Items (ItemTemplate)-> Create Empty…” Give your new data template a name and Blend will take you into the Data Template design.

Continue reading ‘How Do I Wrap Text In The ComboBox?’ »

OK, it’s really late and I want to get this done, so we’re going to go through the easy way, which will require some XAML, but I’ll try to keep it as Blend-y as possible.

So you have a column header and you want the text inside to wrap when the header space gets too short for the content. Your header probably looks something like this:

First, go to wherever your resources are being held and type the following in:

<Style x:Key=”CustomHeaderStyle“ TargetType=”{x:Type GridViewColumnHeader}“>
</Style>

Continue reading ‘How Do I Wrap Text in a ListView Header?’ »

(I’m getting to the point in a roundabout way… you can skip directly to the point below if you want.)

When I started working on my WPF-Wii tutorials, my first Wii project was the initial version of the WPF-Wii Visualizer.

However, I quickly got tired of writing the code for handling events and transferring the data from the Wiimote library to my application. So (like any noble geek would do) I wrote even MORE code to solve the problem, not only for myself, but for generations to come.

I’ve spend the last week writing a Wii-To-WPF library that shovels the Wiimote properties into properties that use the INotifyPropertyChanged WPF interface. This will allow anyone to connect to the Wii through the WPF data binding. It’s super cool.

(A point of note, I posted an early version of this library. Ignore it. I’m putting up a much improved version in the next couple days.)

The Point

But I had no idea how moving from a basic data transference and event handling to the INotifyPropertyChanged interface would affect my performance.

Here are some screenshots of Perforator (a WPF performance monitoring application) monitoring my WPF-Wii Visualizer in its code-heavy iteration:

I don’t know what all those numbers mean, but the one I’m interested in is the frame rate. As a designer, smoother motion is good… especially if I’m trying to design a multi-point application. A frame rate of 27 isn’t too bad, but this is the best I got. The frame rate usually hovered around 20, dipping as low as five.

Now… this is what I got when I was binding the data through the XAML (absolutely no code whatsoever):

And this was the worst I got. My frame rate was always in the mid 60s and would spike up to 80. Take note that I’m not changing the interface at all. In fact, I’m running the binding version at a handicap (it’s tracking four infrared points instead of the original two).

Exact same XAML … except that the XAML properties are data bound from within the XAML and not assigned via the C# code.

So, lets take an account of the WPF INotifyPropertyChanged interface:

• Allows DataBinding
• Permits code-light or code-free interface design
• Drastic improvements to performance

Use it!

Enough said.

I recently spent a couple hours trying desperately to bind a TextBlock to the Canvas.Left and Canvas.Top properties for a project I’m working on. My binding looked like this:

 {Binding ElementName=MyElement, Path=Canvas.Left, Mode=Default}

Couldn’t do it. I tried bloody everything to get this thing to work, but it wouldn’t do it.

Then I found this post on binding to attached properties, which is apparently what you call a property that is written as

<TextBlock Canvas.Left=”100”
      Canvas.Top=”100”
      Grid.Column=”1”
      Grid.Row=”1”
      Grid.ColumnSpan=”1”
      Grid.RowSpan=”1“ />

Forgive the redundancy… I’m trying to write this post so that anyone who is having this problem can find the solution.

So the correct binding (the one that works for me, anyway) is:

{Binding (Canvas.Left), ElementName=MyElement}

It works.

Why? I have no idea.

Just passing it along.