Designer WPF

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.

So I recently found and installed the WPF Performance Suite, which I’ve found to be nice and easy to use.

Microsoft documentation on using the WPF Performance Suite.

As a designer, I’ve found the Perforator a particularly useful tool in the suite.

Perforator is a performance profiling tool for analyzing rendering behavior. The Perforator main window displays a set of options that allow you to analyze very specific rendering behavior in parts of your application.

Key for me in this suite is the “Frame rate” counter in this application. As you probably know, the human eye is pretty comfortable with 30-60 frames per second (for computer applications). Because WPF allows the simple creation of animations to aid usability and design, smooth frame rates have become important to me.

 If they’re important to you, I highly reccomend the above suite.

Get it. Use it. Love it.