The Neglected Panel: UniformGrid

In WPF there are Panels that get used often: the Canvas, DockPanel, Grid, StackPanel, and even the WrapPanel. These Panels feel a lot of love. The UniformGrid, not so much. While most Panels are displayed proudly in System.Windows.Controls, the UniformGrid has been pushed into the Primitives namespace along side the TabPanel and the ToolBarPanel, both of which are too specialized to be given any real attention.

The UniformGrid is a great Panel to keep in mind. Once you do you’ll use it more often than you think. It does what the name implies, it lays out its children in a grid with uniform cells. You can specify neither the Rows or Columns, in which case it creates a square grid (3 x 3, 4 x 4, etc). You can specify either Rows or Columns, in which case it forces that number of cells in the given direction. For example, specifying 2 columns and providing six children would result in a 2w x 3h grid, providing one child would result in a 2w x 1h grid. Finally, you can specify both Rows and Columns, creating a grid of a fixed size. If you specify both Rows and Columns and provide more children than there are cells then the extra children will not be displayed. Finally, by placing the UniformGrid in a ScrollViewer and binding the size of the UniformGrid to a multiple of the actual size of it’s parent, you can achieve some great results.

Here are some of my common uses for the UniformGrid:

• Laying out icons in a uniform way (think of the iPhone home screen)
• Photo or video galleries where every item should be the same size
• Specifying Rows=”1″ and providing only two children for side by side comparisons
• Even spacing of children with a fixed size
• Using it as a uniform StackPanel by specifying either Rows=”1″ or Columns=”1″
• A quick way to layout controls, such as in a sandbox application

If you have any more good uses for this neglected little fella leave a comment.

Parts & States Model with VisualStateManager

I was going to write my own entry on the Parts & States Model for defining contracts between a control’s logic and visuals but you can’t get much better than this article by Karen Corby. Check it out.

Splash Screens in WPF 3.5 SP1

WPF 3.5 SP1 will allow a custom image to be used as a spash screen. The display of this splash screen is implemented in native code and therefore will display fairly quickly while WPF spins up. When your application loads the splash screen will fade out.

Data Objects, Interfaces, and WPF

Here are some nifty interfaces to think about when creating data objects that will be used in a WPF application. I’ve intentionally kept these descriptions very brief.

System.ComponentModel.INotifyPropertyChanged

This is probably one of the most common interfaces to implement in your data objects. Implementing this interface allows you to notify WPF that a property has changed when the data object is data bound.

System.ComponentModel.IDataErrorInfo

In .NET 3.5 WPF looks for this interface when data binding. This interface allows you to mark properties on your object as being in an erroneous state. On your Binding object set ValidatesOnDataErrors to true to enable this behavior.

System.ComponentModel.IEditableObject

In .NET 3.5 SP1 WPF included the IEditableCollectionView. When using the IEditableCollectionView, IEditableObject allows you to handle the transactional editing of your individial data objects using BeginEdit(), EndEdit(), and CancelEdit().

System.ComponentModel.ISupportInitialize

If you need your data object to perform an action after WPF has set each property from Xaml, this is the interface you need to implement. WPF will call EndInit() when all the properties have been set.

Which ones did I miss? Which interfaces do you think are important to keep in mind when creating data objects?

WPF, Images, and DPI Independence

When many people first bind a bitmap image (say a PNG, or JPG) to an Image control in WPF, an overly astute developer might scratch his or her head and think “Why is my image 33% too big?”

It all boils down to DPI. Say you have a 720px x 720px image at 72dpi (many images have a DPI of 72). Physically, this image would be 10in x 10in. WPF will maintain this size, and since WPF defaults to 96dpi, at 10in x 10in the image is shown on the screen as 960px x 960px, 33% bigger than it’s original size.

Noodle on that for awhile and you’ll realize that although it’s a stumbling point, it is indeed the correct behavior. Images should display according to their intended DPI. Images with a DPI below 96 will be scaled up, and those with a DPI above 96 will be scaled down (assuming you have not changed your machine’s native DPI).

The problem is that the WPF team has provided no easy means by which to say “I want to ignore the DPI of the image, give it to me in its original pixel size.” This behavior is often the desired one when building a simple image editor for example.

Wouldn’t it be great if you could set a property called ScalingBehavior to DpiAdjusted or OriginalPixelSize? Well, you can’t, not yet anyway. There is a solution however:

<Image Source=”{Binding …}” Stretch=”Uniform” Width=”{Binding Source.PixelWidth,RelativeSource={RelativeSource Self}}” Height=”{Binding Source.PixelHeight,RelativeSource={RelativeSource Self}}” />

 

Here we’ve set Stretch to Uniform and bound the Width and Height to the PixelWidth and PixelHeight of the Source, effectively ignoring DPI. The image however will not be pixel perfect, even when using SnapToDevicePixels (which simply snaps the borders, not pixels within the image). However, WPF in 3.5 SP1 will support a NearestNeighbor BitmapScalingMode, which should correct this.