LUKE PUPLETT

Windows Phone 7 Series extends the panning and scrolling UI metaphors seen in Windows Media Center and apparently in the Zune. This is no surprise as they are consumer entertainment products, or at least two are and the phone has been remarketed.

Anyway, to experiment with this style of interface, which lends itself so well to touch, I realised that I need a kind of table that can slide left and right, scroll up and down, be extended dynamically and do all this from a control-agnostic view model. Welcome to my ridiculously simple custom control.

Reductionism

When thinking about designing a user interface one must adopt a reductionist mentality. Each consituent part of a UI needs breaking down into units of functionality and within each one, there are usually more units of functionality until a reusable control is arrived at. And then there's that control's constituents which are usually a small number of stock WPF controls.

This idea comes quite easily to an object oriented programmer because its pretty much the same thought process as for designing classes of logic.

To be useable from a ViewModel that is not aware of the control, perhaps because the assembly that the view model is in doesn't reference the library of custom controls, it must support data binding using CLR base types.

A table is a bunch of bunches of stuff and at the time of writing, there's only one bunch of stuff class that supports databinding and that's the ObservableCollection<T>.

The Phone 7 interface scrolls sideways between 'pages' of contextual content either by gesture or with a click of a 'column' header - itself in its own slider.

Each page scrolls as a normal page, with autohide scrollbars like the iPhone. The simplest logical representation of this logic - remember controls are just logic - is a horizontal StackPanel of ListBox controls.

That harmoniously translates into CLR land as an ObservableCollection of ObservableCollection objects. Nice.

To allow of column headings, I'm going to wedge a KeyValuePair in there, where K is a string and V is the ObservableCollection<object>

Code

Here's the full code the control. I'll explain some of the few remarkable points after. However there is a bug bug in this quick attempt: DataBinding doesn't call the setter and so doesn't set the CollectionChanged handler, which is why it works in my non-bound example.

The solution is to add/remove the handlers for this event in the OnTableSourceChanged handler, but I'm sure most of you can work this out. Is that lazy? Sorry but editting formatted code in the published article is a nightmare.

Starting at the top, it has no parts. This is because it derives from StackPanel and so it is just itself. It's just a panel.

Moving down the code, there are three DependencyProperty members. The first is the DataTable property which is typed as ObservableCollection<KeyValuePair<string, ObservableCollection<object>>>, the second is ListBoxStyle which accepts a Style object which allows such things as removing the default black border around each element and then there's ItemDataTemplate which is a DataTemplate to apply to each of the listboxes.

It's likely that each ListBox will need its own different DataTemplate but it would be quite trivial to add a property that takes a DataTemplateSelector which can use your own logic to work out which DataTemplate to apply to which items.

The next interesting thing is the ReinitializeTableSource method. This kicks out all the old ListBox instances in the panel (itself) and then adds new ones. It copies over the ItemDataTemplate and ListBoxStyle to each new ListBox and also hooks up the data binding to each collection that represents column data.

It also sets an event handler for the lostfocus event which simply removes the selection, otherwise each independant listbox will have its own selection highlight. There might be situations when this is useful, but not today.

Further down there's the handler for the main outer collection CollectionChanged event which can only really occur when columns are added or removed and triggers the whole thing to be reconfigured.

OnTableSourceChanged handles changes to the TableSource dependency property which could itself be bound, this also trigger a complete reconfig.

The rest is left over from the parts and states model and can support the VisualStateManager paradigm.

Basic Model

The most simple use of the control looks like this.

The two buttons manipulate a window level private collection of collections which is communicated via the magic of data binding to the table on screen.

The XAML for the window is here:

<Window x:Class="WpfSimpleTableControl.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local="clr-namespace:WpfSimpleTableControl"
Title="MainWindow" Height="350" Width="525">
<Grid>
<StackPanel>
<local:SimpleTable x:Name="SimpleTable" Margin="20" Orientation="Horizontal" Height="200">
<local:SimpleTable.ListBoxStyle>
<Style TargetType="{x:Type ListBox}">
<Setter Property="BorderThickness" Value="0" />
<Setter Property="Width" Value="150" />
</Style>
</local:SimpleTable.ListBoxStyle>
</local:SimpleTable>
<Button Width="150" Click="Button_Click" Margin="2">Add to column 2</Button>
<Button Width="150" Click="Button_Click" Margin="2">Add new column</Button>
</StackPanel>
</Grid>
</Window>

And the codebehind, which does not use MVVM for this simple demo, goes like this.

And with MVVM would really just be a binding in the XAML to a ObservableCollection<KeyValuePair<string, ObservableCollection<object>>> typed property on the ViewModel class.

Because this was designed with MVVM in mind, the clicking of items is not considered in the panel. Usually, the DataTemplate for the item binds a Command to a property on the item's ViewModel and so actions go direct.

I will return when I have made it look nice, added a DataTemplate and probably after discovering some minor nuance which completely trounces the whole thing's feasiblity and makes me look a tit.

Hopefully not though, maybe sometimes WPF can be simple. Maybe.