I eagerly agreed to create two videos each week reviewing the Silverlight Toolkit controls. My goal was to provide dead-simple examples both in my blog and in the videos so that anyone can come along and see how to use these controls with no muss., no fuss. I’m quoted in Wikipeda as having said “Write like you won’t be in the room when what you’ve written is read, because you won’t” I’m not sure I said it, and I’m not sure it is original, but I certainly agree with it.
I certainly believe that example code is not the place to show off cool coding technique, nor is it the place for lots of indirection or irrelevant extra bits that get in the way of understanding the point being explained. This was hammered home to me nearly twenty years ago when I was using an ISAM database library to build a database engine in C for PBS. The product was great, but the documentation was written with very complex examples illustrating what turned out to be very simple API calls (I suspect they just lifted the examples right out of the program). Once stripped down it was all very easy to use but at first glance it was a nightmare of indirection.
Siren Song of A Unified Presentation
It came as something as a shock to me, therefore, when I succumbed to the temptation to put all my Toolkit examples into a single multi-page application.
After all, I certainly could create each video totally on its own, and have independently get the data it needs to populate the control. But there is something so compelling about getting the data once, and then using that data as the source for all the controls that it was just irresistible.
It turns out that by providing a starter program, the user who wants to concentrate only on the toolkit control really doesn’t need to know how the data retrieval or the page switching works. Just create a new page for the example, wire it into the provided starter kit and ignore the details. As you view more videos, more buttons light up, and you can view them in any order you like.
NB: This entire exercise in explaining my decision is, I’m told, somewhat counter-cultural. The proper Microsoft approach is to make a decision, preferably the right one, and then FIPO! It is, I suspect, a personal imperative, that I write about why I’ve chosen a particular approach, and show how one could argue for a different decision. (Is this intellectual honesty or simply indecisive perseveration?)
I will have to start tagging these as Ramblings so those of you who write in to say “stick to Silverlight and keep all the rest silent” won’t have to create a macro, and those of you who like the peek inside my brain can read on.
The Architecture of the Containing Application
My other excuse, rationalization, justification, explanation for using this approach was that it builds on the architecture explained in my latest tutorial and it is always nice to see an architectural approach put to work.
So, while getting rid of all this and making each example stand on its own would be simpler, this turned out to be so elegant that I can’t quite bring myself to kill it.
[ Larry Weiss, who was at one time something of a mentor and who built the most successful ATM machines in the world, said, in a most memorable phrase, “the secret of success in UI design is a readiness to kill your own children.” – by which he meant (thank goodness) a readiness to kill those designs you created and most cherish. ]
How It Works
When you download the source with any of the toolkit videos you will receive two zip files:
- ToolkitExplorationStarter
- fooCompleted
where foo is the name of the control being explored.
The latter is the complete source code for the example as shown in the video, the former is the the complete structure into which each page will be placed. (Of course each of these will be available in either VB or C#)
The starter program consists of the following files
- App.xaml and App.xaml.cs
- Page.xaml and Page.xaml.cs
- PageSwitcher.xaml and PageSwitcher.xaml.cs
- LoadWords.xaml and LoadWords.xxaml.cs
- ISwitchable.cs
- Switcher.cs
as well as the usual references folder, Properties folder and a project for Toolkit Exploration.Web. You’ll want to open the references to ensure that the reference to Microsoft.Windows.Controls.dll is pointing to the right file on our machine – or change it to do so.
The changes in App.xaml.cs and the use and details of all of the files other than LoadWords and LoadWords.xaml.cs are explained in detail in the tutorial, and so I won’t recapitulate that here except to say that it allows you to switch from one page to another and to pass in data. The page that is called implements ISwitchable, and the data is passed via the required UtilizeState method,
1: public void UtilizeState( object state )
2: {
3: if ( state != null )
4: {
5: sortedWords = state as List<string>;
6: myAutoComplete.ItemsSource = sortedWords;
7: }
8: }
Adding a Control to the Structure
Each time we want to examine a new control, we’ll just create a new page an plug it into the structure with three steps:
1. Make the new page (e.g., AutoCompleteBox.xaml and AutoCompleteBox.xaml.cs) and be sure the class implements ISwitchable,
public partial class AutoCompleteBoxPage : UserControl, ISwitchable
2. Implement the (required) UtilizeState as shown above (the snippet above actually is from AuutoCompleteBox
3. Enable the button in Page.xaml.cs and set its event handler
Page.Page():
AutoComplete.Click += new System.Windows.RoutedEventHandler( AutoComplete_Click );
Page.AutoComplete_Click:
1: void AutoComplete_Click( object sender, System.Windows.RoutedEventArgs e )
2: {
3: Switcher.Switch( new AutoCompleteBoxPage(), words );
4: }
Page.UtilizeState:
public void UtilizeState( object state )
{
AutoComplete.IsEnabled = true;
That’s it; the new test page is added. When you click on the AutoCompleteBox button the new page is shown to demonstrate the control, utilizing the same data (the list of words) that the other controls use,
The code for the AutoCompleteBox sample page is simplified by the design as the data is passed in,
1: public void UtilizeState( object state )
2: {
3: myAutoComplete.ItemsSource = state as List<string>;
4: }
and thus becomes a non-issue – you still see how it is assigned but don’t have to worry for each control about how to obtain the data.
I look forward to seeing how this all works out.
-j
