Designer WPF

This is an extension of my previous post, WPF Wiimote Library (Now With Project Files!), which has links to the WPF Wiimote Binding Library project files as well as some information vital to getting you started in connecting your application to the Wiimote.

And now for the IR properties:

The Wiimote can track up to 4 infrared (IR) LEDs at a time. If I were a programmer, I would have created an IR LED enum with the following properties as part of each IR LED. But since I’m not, these properties can be accessed with the following convention: IR[#][propertyName]. Each IR LED has the following properties:

IR[#]RawPosition

Type: Point

Summary: The IR camera has a X,Y resolution of 1024, 768. This property will give you the raw X,Y position that the Wiimote is tracking this LED at.

Binding Usage Example:

<Grid Canvas.Left=”{Binding Source={StaticResource WiiData}, Path=”IR1RawPosition.X, Mode=OneWay}”
Canvas.Top=”{Binding Source={StaticResource WiiData}, Path=”IR1RawPosition.Y, Mode=OneWay}” />

Additional Info: This will work best if your Canvas is the exact dimensions of the Wiimote camera (1024, 768). These properties are automatically converted to take into account the IsMultiPoint setting (described in the Miscellaneous Properties (coming soon)).

IR[#]Position

Type: Point

Summary: This is the X,Y ratio of the position of your IR LED. The best way to use this is in a multi-binding with the width and height of your target Canvas. Fortunately for you, I’ve added a converter that will help with this. Simply add the following code in your resources:

<Wii:VariableCanvasPointConverter x:Key=”VariableCanvasConverter” />

And follow the binding example below.

Binding Usage Example:

<Grid>
   <Canvas.Left>
      <MultiBinding Converter=”{StaticResource VariableCanvasConverter}“>
         <Binding Source=”{StaticResource WiiData}” Path=”IR1Position.X” Mode=”OneWay” />
         <Binding ElementName=”MyCanvas” Path=”ActualWidth” Mode=”Default” />
      </MultiBinding>
   </Canvas.Left>
   <Canvas.Top>
      <MultiBinding Converter=”{StaticResource VariableCanvasConverter}“>
         <Binding Source=”{StaticResource WiiData}” Path=”IR1Position.Y” Mode=”OneWay” />
         <Binding ElementName=”MyCanvas” Path=”ActualHeight” Mode=”Default” />
      </MultiBinding>
   </Canvas.Top>
</Grid>

Additional Info: These properties are automatically converted to take into account the IsMultiPoint setting (described in the Miscellaneous Properties (coming soon)).

IR[#]Found

Type: boolean

Summary: This is a property that is “true” if the Wiimote can see the target LED and “false” if it cannot.

Binding Usage Example:

<Grid IsEnabled=”{Binding Source={StaticResource WiiData}, Path=IR2Found, Mode=OneWay}” />

Additional Info:  This property is also available for the midpoint between the first and second infrared light (MidPointFound) and for the target point (TargetFound) which displays a calculated position of where the Wiimote is being pointed.

IR[#]Size

Type: double

Summary: The Wiimote naturally picks up the size of the LED it is tracking. To get larger sizes  (which translates into better reliability) use a small cluster of LEDs (three should do the trick) rather than a single one.

Binding Usage Example:

<Grid Width=”{Binding Source={StaticResource WiiData}, Path=IR1Size, Mode=OneWay}” />

IsIR[#]Visible

Type: bool

Summary: This item is meant for two way binding. If you want a way to programmatically choose whether or not to show the item that is bound to your IR interface, use this property. It is most useful when used in conjunction with the BoolToVisibility Converter, which can be used by placing this XAML in your resources:

<BooleanToVisibilityConverter x:Key=”boolToVis” />

Binding Usage Example:

<Grid Visibility=”{Binding Source={StaticResource WiiData}, Path=IsIR3Visible, Mode=OneWay, Converter={StaticResource boolToVis}“/>

<CheckBox IsChecked=”{Binding Source={StaticResource WiiData}, Path=IsIR3Visible, Mode=TwoWay}“/>

Additional Info:  This is a great property to attach to a checkbox (as seen above) to allow user control over which items are to be shown.

In addition to the infrared lights, the WPF Wii library is set up to display two calculated points as well:

• A midpoint between IR1 and IR2
• A target point (based on the midpoint) which indicates where the Wiimote is being pointed.

These two calculated points still have the position properties listed above (TargetRawPosition, MidPoint RawPosition, TargetPosition, MidPointPosition) as well as the visibility booleans (IsTargetVisible and IsMidPointVisible) and the “found” boolean properties (MidPointFound and IsTargetPossible).

Of course, you can also play around with the items in Intellisense is also a great way to discover all the available properties.

(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.