Before we get into panning within the PivotViewer, let’s take a look at this new approach.  In the first post of this series, I discussed two approaches for getting access to the internals of the PivotViewer: visual tree hacking and using reflection.  While reflection was a cleaner approach, it requires elevated permissions to access information about a class marked as internal.  The problem with the visual tree approach is there needs to be part of the UI which indirectly exposes access to what you are trying to do.  In the case of zooming, the zoom slider allowed us to build a zoom API by modifying its current value.  However, the PivotViewer does not expose a UI control that will allow us to accomplish the same thing for panning.

Using the second approach, reflection, will require us to set the elevated trust permission on our application in order to use the API.  While this is possible, it can certainly be a hurdle for some public implementations.  So how do we overcome this situation?  Well it turns out that binding to a property of an internal class does not fire off a security warning.  That’s right boys and girls.  As long as the class you are binding to supports INotifyPropertyChanged, we can bind to it and build an API around it.  Of course, the best way to explain this is to show it in action.

To get things started, we are going to begin with the project from Hacking PivotViewer : Zoom.  You can download that project here: HackingPivotViewer_Zoom.zip

Just as we did with our zoom API, we are going to build our API with dependency properties and defining bindings by overriding the OnApplyTemplate method.  For this project we need to create 3 dependency properties in our CustomPivotViewer class.  The first will be the ZoomPanState.  We will bind this property to the ZoomPanState object in the CollectionViewerViewModel.  This is actually the object that controls the pan and the zoom.  We will access the CollectionViewerViewModel through the visual tree as we did in the previous post.

The next two properties are the PanOffset and the TargetPanOffset.  The PanOffset property binds to the Offset of the ZoomPanState.  This is a Point object that defines the current pan offset.  The TargetPanOffset binds to the TargetOffset property.  Since PivotViewer uses zoom animations for everything, modifying the Offset property isn’t what you want to change.  If you modify the TargetOffset, then the PivotViewer will create a smooth transition from its current Offset to the new TargetOffset.  It is also important to note that we will create a two way binding for the PanTargetOffset.  If you don’t, you will spend a while banging your head into your keyboard trying to figure out why values aren’t updating (or maybe that was just me).

public static readonly DependencyProperty ZoomPanStateProperty
    = DependencyProperty.Register("ZoomPanState",
                                typeof(object),
                                typeof(CustomPivotViewer), null);

public object ZoomPanState
{
    get { return GetValue(ZoomPanStateProperty); }
    set { SetValue(ZoomPanStateProperty, value); }
}

public static readonly DependencyProperty PanOffsetProperty
    = DependencyProperty.Register("PanOffset",
                                typeof(Point),
                                typeof(CustomPivotViewer), null);

public Point PanOffset
{
    get { return (Point)GetValue(PanOffsetProperty); }
    set { SetValue(PanOffsetProperty, value); }
}

public static readonly DependencyProperty TargetPanOffsetProperty
    = DependencyProperty.Register("TargetPanOffset",
                                typeof(Point),
                                typeof(CustomPivotViewer), null);

public Point TargetPanOffset
{
    get { return (Point)GetValue(TargetPanOffsetProperty); }
    set { SetValue(TargetPanOffsetProperty, value); }
}

The next thing we need to do is to populate these values.  As I mentioned above, this will be done via binding.  By using Reflector, I was able to determine the structure of the CollectionViewViewModel class.  The property we are interested in is the ZoomPanState.  We will create a binding to our ZoomPanState dependency property.  The two offest properties are mapped to properties of the ZoomPanState.  It’s important to remember that this is an internal class, and therefore we shouldn’t be able to access the members.  However, by using a little binding and understanding the structure of the class in question, we are able to expose access to the class and it’s properties.

public override void OnApplyTemplate()
{
    base.OnApplyTemplate();

    Grid templateChild = (Grid)base.GetTemplateChild("PART_Container");

    var coll = templateChild.Children[2] as Control;
    var viewModel = coll.Resources["ViewModel"];

    var bind = new Binding("ZoomPanState");
    bind.Source = viewModel;
    SetBinding(ZoomPanStateProperty, bind);

    bind = new Binding("Offset");
    bind.Mode = BindingMode.TwoWay;
    bind.Source = ZoomPanState;
    SetBinding(PanOffsetProperty, bind);

    bind = new Binding("TargetOffset");
    bind.Mode = BindingMode.TwoWay;
    bind.Source = ZoomPanState;
    SetBinding(TargetPanOffsetProperty, bind);

}

With that in mind, we will create a Pan method on our CustomPivotViewer that has two parameters: x and y.  These parameters are going to work as you would expect.  The x parameter will handle horizontal offsets and the y will handle the vertical.  The method simply sets the PanTargetOffset to a new Point based on the current PanTargetOffset adjusted with the new values.

public void Pan(double x, double y)
{
    TargetPanOffset = new Point(PanOffset.X + x, PanOffset.Y + y);
}

There are a couple of things to notice about the pan values.  The values are based off of the total area of the collection based at its current zoom level.  So the more you zoom in, the larger your canvas is.  The second thing is that PivotViewer will do some bounds checking for you and not let you zoom pass the edge of the collection.  Therefore, it’s not something you need to worry about writing code for.  As of this writing, I haven’t located the current size of the collection.  This would come in handy when you want to scale the amount you pan based on the current size. But alas, we can’t have everything that we want.

Now let’s create a UI to test the new API.  We will replace the header we added in the last post with a new one to examine the pan API.  It consists of the current x and y offsets and four buttons (left, top, right, bottom).

<Grid x:Name="LayoutRoot" Background="White">
<Grid.RowDefinitions>
    <RowDefinition Height="Auto"/>
    <RowDefinition Height="*"/>
</Grid.RowDefinitions>
<StackPanel Orientation="Horizontal" Height="50">
    <StackPanel.Resources>
        <Style TargetType="TextBlock">
            <Setter Property="VerticalAlignment" Value="Center"/>
        </Style>
    </StackPanel.Resources>
    <TextBlock Text="Offset X : "/>
    <TextBlock Text="{Binding PanOffset.X,
                    ElementName=pViewer,
                    StringFormat='0.0'}"/>
    <TextBlock Text="   Offset Y : "/>
    <TextBlock Text="{Binding PanOffset.Y,
                    ElementName=pViewer,
                    StringFormat='0.0'}"
                Margin="0,0,20,0"/>
    <Button Content="Left" Width="40" Height="25"
        x:Name="btnLeft" Click="btnLeft_Click"/>
    <Button Content="Up" Width="40" Height="25"
        x:Name="btnUp" Click="btnUp_Click"/>
    <Button Content="Right" Width="40" Height="25"
        x:Name="btnRight" Click="btnRight_Click"/>
    <Button Content="Down" Width="40" Height="25"
        x:Name="btnDown" Click="btnDown_Click"/>
</StackPanel>
<conv:CustomPivotViewer x:Name="pViewer" Grid.Row="1">
    <pivot:PivotViewer.PivotProperties>
        <pivot:PivotViewerNumericProperty
Id="Value"
Options="None"
Binding="{Binding Value}"/>
        <pivot:PivotViewerStringProperty
Id="Data1"
Options="CanFilter,CanSearchText" 

Binding="{Binding Data1}"/>
        <pivot:PivotViewerStringProperty
Id="Color"
Options="CanFilter,CanSearchText"
Binding="{Binding Color}"/>
        <pivot:PivotViewerDateTimeProperty
Id="Stamp"
Options="CanFilter"
Binding="{Binding Stamp}"/>
    </pivot:PivotViewer.PivotProperties>
</conv:CustomPivotViewer>

The click event handlers make use of our new Pan method to set the offset in the correct directions.

private void btnDown_Click(object sender, RoutedEventArgs e)
{
    pViewer.Pan(0,100);
}

private void btnRight_Click(object sender, RoutedEventArgs e)
{
    pViewer.Pan(100,0);
}

private void btnUp_Click(object sender, RoutedEventArgs e)
{
    pViewer.Pan(0,-100);
}

private void btnLeft_Click(object sender, RoutedEventArgs e)
{
    pViewer.Pan(-100,0);
}

Running the project your application should look like this.

When you are zoomed out panning will not work, so don’t get discouraged.  This is because the size of the collection canvas is equal to that of the available space.  So trying to pan will hit the bounds checking that PivotViewer does.  Once you zoom in, you should be able to pan around using the four buttons we added.  You will also notice that PivotViewer makes nice smooth transitions when you pan.  This is a result of using the TargetOffset and allowing PivotViewer to handle the actual transitions.

Well there you have it.  We can now zoom and pan the PivotViewer.  You can download the code for this project here: HackingPivotViewer_Pan.zip

This series will continue as more customizations are created for the new PivotViewer.  Make sure to check back for future updates.

So that means it’s time to start taking matters in our own hands and start poking around under the hood.  This is the first post in a new series, Hacking PivotViewer.  This series will be a little different from some of the others, as it won’t be sequential.  As I have time to tackle different road blocks, I will post the results to this series.  Guess that means it’s time to get started.

Methods of Hacking

If you use Reflector on our good friend PivotViewer, you can quickly start to see what makes it tick.  Unfortunately, most of the good stuff is labeled as “internal”, which means that we don’t have access to it.  Correction, we are not supposed to have access to it.

When you run into this sort of situation, there are two different approaches you can take.  The first is to use reflection.  With reflection, you can gain access to an objects properties and methods (including private properties).  This includes accessing internal objects as well.  However, in Silverlight you have to run the application in ‘elevated trust’ mode in order to access internal classes.  Otherwise you will receive a security violation error.

The second approach is to hack the visual tree.  By gaining access to various parts of the visual tree, you can create hook points that will allow you to extend the PivotViewer.  This was done quite a bit for the original PivotViewer.  In fact, you can take a look at my CodePlex project that is centered around just that : PivotViewer Lessons.

If given the choice, I would rather use reflection.  You could create a public API that directly accessed the inner workings of PivotViewer.  Unfortunately, the security requirements make that a non-starter for many projects.  With that in mind, whenever possible, I will use the visual tree method.  Fortunately, zooming is one area we can do this in.

Exposing a Zoom API

When tackling a problem like this, there are always several approaches that you can take.  In fact, my first approach was scrapped in favor of the approach in this post.  PivotViewer has some internal view models that we could use reflection to get access to and modify.  However, the zoom slider control presents us an interesting entry point into the same view models.

By modifying the slider value we can change the zoom level and that is really all we need.  The API for this project will consist of 3 values : minimum, maximum, and value.  We will expose the min/max values simply to be a bit more informed. 

The first thing we need to do is to get a PivotViewer project up and running.  To speed things along, we will start with the project in my PivotViewer Basics: Client-Side Collections post.  You can download that project here: PVB01_ClientSideCreations.zip.

Now that we have a working sample project, we can get to work.  In order to encapsulate the code, we are going to create a new class the inherits the PivotViewer.  The first thing we are going to do is to add 3 dependency properties.  The reason we are using dependency properties is to open up binding possibilities.  If you would prefer, you could create simple properties in place of these.

public class CustomPivotViewer : PivotViewer
{
    public static readonly DependencyProperty ZoomMinProperty
        = DependencyProperty.Register("ZoomMinimum",
                                        typeof(double),
                                        typeof(CustomPivotViewer),
                                        null);

    public double ZoomMinimum
    {
        get { return (double)GetValue(ZoomMinProperty); }
        set { SetValue(ZoomMinProperty, value); }
    }

    public static readonly DependencyProperty ZoomMaxProperty
        = DependencyProperty.Register("ZoomMaximum",
                                        typeof(double),
                                        typeof(CustomPivotViewer),
                                        null);

    public double ZoomMaximum
    {
        get { return (double)GetValue(ZoomMaxProperty); }
        set { SetValue(ZoomMaxProperty, value); }
    }

    public static readonly DependencyProperty ZoomValueProperty
        = DependencyProperty.Register("ZoomValue",
                                        typeof(double),
                                        typeof(CustomPivotViewer),
                                        null);

    public double ZoomValue
    {
        get { return (double)GetValue(ZoomValueProperty); }
        set { SetValue(ZoomValueProperty, value); }
    }
}

When a control’s UI gets generated in Silverlight, a method OnApplyTemplate is called.  You can override this method and this creates a great place to tie into elements of the visual tree.  The reason is, prior to this point, the visual tree elements do not exist. 

Let’s add an override of the OnApplyTemplate method.  Once the base control has created the visual tree, we can now find the zoom slider.  This is accomplished by using the GetTemplateChild method.  The method will return the Slider control that is used for zooming.  We will bind the Minimum, Maximum, and Value properites of the slider control to our 3 new dependency properties.

public override void OnApplyTemplate()
{
    base.OnApplyTemplate();

    Slider templateChild1
         = (Slider)base.GetTemplateChild("PART_ZoomSlider");
    var binding = new Binding("Minimum");
    binding.Source = templateChild1;
    SetBinding(ZoomMinProperty, binding);
    binding = new Binding("Maximum");
    binding.Source = templateChild1;
    SetBinding(ZoomMaxProperty, binding);
    binding = new Binding("Value");
    binding.Source = templateChild1;
    binding.Mode = BindingMode.TwoWay;
    SetBinding(ZoomValueProperty, binding);

}

The last thing we are going to add is a method to allow us to increment the zoom value.  You can accomplish this my changing the ZoomValue directly, but this way we can handle increments as well.  The method does a little bounds checking and then adds the increment value to Value of the zoom slider.  Positive values will zoom in and negative values will zoom out.

public void Zoom(int val)
{
    var newVal = ZoomValue + val;
    ZoomValue = Math.Min(ZoomMaximum,
        Math.Max(ZoomMinimum, newVal));
}

Armed with our new custom PivotViewer, let’s modify MainPage.xaml to use the it instead of the original version.

<conv:CustomPivotViewer x:Name="pViewer" Grid.Row="1">
    <pivot:PivotViewer.PivotProperties>
        <pivot:PivotViewerNumericProperty
    Id="Value"
    Options="None"
    Binding="{Binding Value}"/>
        <pivot:PivotViewerStringProperty
    Id="Data1"
    Options="CanFilter,CanSearchText" 

    Binding="{Binding Data1}"/>
        <pivot:PivotViewerStringProperty
    Id="Color"
    Options="CanFilter,CanSearchText"
    Binding="{Binding Color}"/>
        <pivot:PivotViewerDateTimeProperty
    Id="Stamp"
    Options="CanFilter"
    Binding="{Binding Stamp}"/>
    </pivot:PivotViewer.PivotProperties>
</conv:CustomPivotViewer>

And that is really all there is to is.  Of course, you probably want to make sure this actually works, right?  Well let’s do just that.  Below is a modification of the MainPage that adds a stack panel above the CustomPivotViewer.  It will display the min, max, and value of the current zoom.  It also contains two buttons, “In” and “Out”.  Care to guess what these are going to do?

<Grid x:Name="LayoutRoot" Background="White">
    <Grid.RowDefinitions>
        <RowDefinition Height="Auto"/>
        <RowDefinition Height="*"/>
    </Grid.RowDefinitions>
    <StackPanel Orientation="Horizontal" Height="50">
        <StackPanel.Resources>
          <Style TargetType="TextBlock">
             <Setter Property="VerticalAlignment" Value="Center"/>
          </Style>
        </StackPanel.Resources>
        <TextBlock Text="Zoom Minimum : "/>
        <TextBlock Text="{Binding ZoomMinimum,
                            ElementName=pViewer,
                            StringFormat='0.0'}"/>
        <TextBlock Text="   Maximum : "/>
        <TextBlock Text="{Binding ZoomMaximum,
                            ElementName=pViewer,
                            StringFormat='0.0'}"/>
        <TextBlock Text="   Value : "/>
        <TextBlock Text="{Binding ZoomValue,
                            ElementName=pViewer,
                            StringFormat='0.0'}" Width="30"/>
        <Button Content="In" Width="30" Height="25"
                x:Name="btnIn" Click="btnIn_Click"/>
        <Button Content="Out" Width="30" Height="25"
                x:Name="btnOut" Click="btnOut_Click"/>
    </StackPanel>
    <conv:CustomPivotViewer x:Name="pViewer" Grid.Row="1">
        <pivot:PivotViewer.PivotProperties>
            <pivot:PivotViewerNumericProperty
        Id="Value"
        Options="None"
        Binding="{Binding Value}"/>
            <pivot:PivotViewerStringProperty
        Id="Data1"
        Options="CanFilter,CanSearchText" 

        Binding="{Binding Data1}"/>
            <pivot:PivotViewerStringProperty
        Id="Color"
        Options="CanFilter,CanSearchText"
        Binding="{Binding Color}"/>
            <pivot:PivotViewerDateTimeProperty
        Id="Stamp"
        Options="CanFilter"
        Binding="{Binding Stamp}"/>
        </pivot:PivotViewer.PivotProperties>
    </conv:CustomPivotViewer>

</Grid>

The last thing we need to do is to implement the Click handlers for the two buttons.  Both simply call our Zoom method we created to increment the zoom level.

private void btnIn_Click(object sender, RoutedEventArgs e)
{
    pViewer.Zoom(1);
}

private void btnOut_Click(object sender, RoutedEventArgs e)
{
    pViewer.Zoom(-1);
}

Now if we run the project, you should get something that looks like this:

The buttons will allow you to zoom in and out.  PivotViewer handles all of the nice smooth transitions for you and everything.  If you want to zoom out to the default view, you just need to set ZoomValue to 1.0.

You will start to see more of these hacks over the next few months.  I am working on a Silverlight 5 version of PivotViewer Lessons to help centralize all of these changes.

You can download the completed project here : HackingPV_Zoom.zip

Mapping a multi-valued list to PivotViewer is basically the same as a single valued property.  The same property types apply and the actual definition is identical.

For this project, we are going to borrow the sample project from the PivotViewer Basics Series.  You can get the base project from the Client-Side Collections here : PVB01_ClientSideCreation.zip.

Just to get a base-line of where we are starting from, you can run the project and you should see a collection of colored trading cards with some simplistic properties.

If you take a look at our XAML in the MainPage, we have a DateTime property defined as Stamp.  If you look at the DemoItem there is a BuildData() method that generates our data for the collection, which includes a date for our Stamp property.

What if we wanted to track multiple dates for this property?  Since that is what this post is about, it seems a relevant question.  From a XAML and PivotViewer point of view, we don’t have to make any changes.  PivotViewer will accept a single DateTime value or a collection of DateTime values.

With that taken care of, we can now shift our focus to the DemoItem class itself.  The first thing we need to do is change the Shift property to a collection.  For simplicity we will create a List<DateTime>.  However, if you create a collection that implements the INotifyCollectionChanged interface, such as an ObservableCollection, PivotViewer will update the item whenever that collection changes.  Since we are created a static list when the object is created, a List<> will work just fine in this example.

The next step is to modify the BuildData() method to populate our Stamp property with a collection of DateTimes.  Here is the modified portions of our DemoItem class.

    public class DemoItem : INotifyPropertyChanged
    {

        ...

        private List<DateTime> _stamp;
        public List<DateTime> Stamp
        {
            get { return _stamp; }
            set
            {
                _stamp = value;
                NotifyProperty("Stamp");
            }
        }

        public static ObservableCollection<DemoItem> BuildData()
        {

             ...
                itm.Stamp = new List<DateTime>()
                            {DateTime.Now.AddDays(-1 * i),
                             DateTime.Now.AddDays(-1 * 5 - 20)};

             ...
        }

     ...

    }

Now if we run our project and select an item, you will see that the Stamp property in the detail pane has multiple values in it.  Seems simple enough, right? With your application running, change the sort property to Stamp. Oops, seems we get the following error:

“Failed to compare two elements in the array.”

The reason for this error is that PivotViewer is unable to sort the items based on a List<DateTime> data type.  If you think about it, it makes sense.  If you have two lists of DateTime, which one comes first?  It really depends on your usage of it and therefore we will need to write some code.

To accomplish this we are going to create a new class : DateTimeList.  The class will inherit the List<DateTime> as well as implement the IComparable interface.  The IComparable interface adds a single method to our class, CompareTo.  For our case, we are going to sort based on the first DateTime in the list.  Our new class will look like this:

public class DateTimeList : List<DateTime>, IComparable
{

    public int CompareTo(object obj)
    {
        return this[0].CompareTo((obj as DateTimeList)[0]);
    }
}

Now let’s change our DemoItem to use our new class instead of the original List<DateTime>.

    public class DemoItem : INotifyPropertyChanged
    {

        ...

        private DateTimeList _stamp;
        public DateTimeList Stamp
        {
            get { return _stamp; }
            set
            {
                _stamp = value;
                NotifyProperty("Stamp");
            }
        }

        public static ObservableCollection<DemoItem> BuildData()
        {

            ...
                itm.Stamp = new DateTimeList
                  {DateTime.Now.AddDays(-1 * i),
                  DateTime.Now.AddDays(-1 * 5 - 20)};

            ...
        }

    }

Rerunning our application, we can now select Stamp as the sort property and PivotViewer will sort based on our definition.  It is worth noting that if you did not have the “CanFilter” option set on the Stamp PivotProperty, it would not be necessary to create a new collection object. 

The completed project of for this post can be found here: PV_MultiValued.zip

Since then, we have recorded five separate events and they are all still available online.  With each event, a newer version was created and the application continues to grow.  With the last event, I was able to roll out a Silverlight 5 version using the newest PivotViewer.  The latest version is actually an early beta of an upcoming product that I will be announcing soon.  I have received a lot of interest in real-world examples of the PivotViewer, so I thought I would take some time to walk thru MVPChat and show PivotViewer in action.

Analyzing the Data

If you have heard me give a talk about PivotViewer, then you have heard me say that the key to creating a successful PivotViewer is to truly understand the data. (If you haven’t heard me talk on PivotViewer, then why not? ).  That was the case here as well.  The first attempt tracked very little data points.  It was nothing more than the basics: author and date/time of post.  While that was useful to a degree, it wasn’t all that useful.  The next attempt really focused on the data in each Tweet.  We pulled out hash tags, mentions, sources, and looked for a list of key words.  While better, it simply didn’t get us where we needed to be. 

The MVP Chat had a unique feature that really made this turn on it’s head.  The moderator would throw out questions, marked with a #Q1,#Q2, etc.  Then participants could respond using that same hash tag or some variant (which made data mining difficult to say the least).  However, by adding a Question property to the PivotViewer, we could start to drill down into micro conversations with the entire event itself.  This not only made the application fun to use to dig thru the data, but it is now useful from an informational perspective by allowing you to pull inter-related information.

Designing the Trading Cards

Now I have to admit, this is still a work in progress.  However, if you take a look at the original version using PivotViewer v1, which is still live at http://mvpchat.championds.com, you will hopefully agree we have come a long way.

The first thing you will notice is that there is actually two cards being used.  The smallest card is simply the thumbnail of the author.  The larger card has the tweet itself, a date/time stamp, and some author information in it.  An interesting challenge was the background.  In an attempt to use the author’s profile background color to distinguish one card from another, I came across the problem of using appropriate colors of the Tweet box.  The default is a white background, however, if the user’s background color was anywhere close to white, it all blended together.

After doing some research on color brightness and using the formula at http://maestric.com/doc/color_brightness_difference_calculator, I came up with a plan to test the color brightness and change the Tweet window accordingly.  While not 100% of where I want it to be, it has allowed me to dynamically change the color based on the author’s profile color.

Customizing the PivotViewer

Now I couldn’t very well simply leave the PivotViewer alone, could I?  That just doesn’t seem right for some reason.  Any while again, not exactly finished, I’ve been happy with the major item of focus in my customizations.

The first minor change I did was to remove the detail pane.  In this situation, there isn’t much that a detail pane could offer.  That might actually change in future iterations, but for now, it was simply removed.

Then I moved on to my major challenge, the item adorner.  I wanted to create a full card adorner that would allow the user to interact directly with the trading card.  I won’t go into the details of how I accomplished this here, but you can read about it on my PivotViewer Basics: Custom Item Adorners post.  After several unsuccessful attempts and a few choice words, I was able to get the basic concept working. 

If you select an item in the PivotViewer, the first thing you will notice is a “Follow” button shows up that will redirect you to Twitter to allow you to follow that user.  However, if you look more closely, you will notice that all of the mentions, hash tags, and the author’s handle are all links.  Clicking on one of the links will change the filter and allow you to navigate around the PivotViewer.  While I have plans for extending this adorner in the future, I was fairly happy with the results to this point.

The End Results

I would be lying if I told you I didn’t bump into any issues along the way.  In fact, all of the issues I ran across I either have or will write about on the blog.  However, overall I think the new Silverlight 5 PivotViewer stood it’s ground rather well.  The new dynamic features really make a difference in building real world solutions.

As far as 3rd party controls, I only used one.  The transitions between pages in the navigation are handled with Telerik’s Transition control.  I have used Telerik’s controls on several projects and I have been really impressed with how they are written and perform.

Next Steps…

You might remember me mentioning, at the beginning of this post, that this application is an early beta of a new product coming.  And since it is, I was wondering if you could help me out.  I have a few short (6 question) survey that I have posted in order to get some feedback on MVPChat.  I would appreciate all of the feedback that I could get and wonder if you would mind filling it out after you played with MVPChat for a minute?

Below are the links to the application and the survey as well.  I have several more posts queued up on PivotViewer, Silverlight, and Win8.  Until then… Happy Pivoting…

Website : http://mvpchat.net

Survey: http://tonyc.me/xuAXJd

So why would we want to disable a ComboBoxItem in the first place?  If you can disable individual items in a ComboBox, then you can still present the user with all of the available data, without making them all an actionable option.  In our example we are going to create a product list ComboBox.  In this scenario we want the user to see all of the products that we carry, but they should only be able to select the items that we currently have in stock.

To start off our project, we will create a new Silverlight 5 Application.  Plain and simple with no bells and whistles.

The first thing we need to do is to create our data object.  For this demo we will only have two properties, Name and IsAvailable.  Our class will also have a static method that will return our test data.

public class Product
{
    public string Name { get; set; }
    public bool IsAvailable { get; set; }

    public static IEnumerable<Product> GetProducts()
    {
        return new List<Product>()
                    {
                        new Product() { Name="Saw" ,
                            IsAvailable = true},
                        new Product() { Name="Hammer" ,
                            IsAvailable = true},
                        new Product() { Name="Clamp" ,
                            IsAvailable = false},
                        new Product() { Name="Level" ,
                            IsAvailable = true},
                    };
    }
}

Now we can create our testing UI.  It will be a simple Grid containing our CombBox and a few TextBlocks.

<Grid Width="Auto" Height="Auto" HorizontalAlignment="Center"
      VerticalAlignment="Center">
    <Grid.ColumnDefinitions>
        <ColumnDefinition Width="Auto"/>
        <ColumnDefinition Width="Auto"/>
    </Grid.ColumnDefinitions>
    <Grid.RowDefinitions>
        <RowDefinition Height="Auto"/>
        <RowDefinition Height="Auto"/>
    </Grid.RowDefinitions>

    <TextBlock Text="Combo Box : "/>
    <TextBlock Text="Selected Item : " Grid.Row="1"/>

    <ComboBox
            x:Name="cbTest" Grid.Column="1"
            DisplayMemberPath="Name" />

    <TextBlock Grid.Row="1" Grid.Column="1"
        Text="{Binding SelectedItem.Name, ElementName=cbTest}"/>
</Grid>

If you look at our ComboBox, we will be displaying the Product Name property.  The last TextBlock maps its Text property to the Name property of the SelectedItem of our ComboBox.  Fairly straight forward, right?

Just for completion sake, I added some Style resources to the UserControl.Resources in order to make the project a bit more readable.

<Style TargetType="TextBlock">
    <Setter Property="FontSize" Value="22"/>
    <Setter Property="Margin" Value="0,10,20,0"/>
</Style>
<Style TargetType="ComboBox">
    <Setter Property="FontSize" Value="22"/>
    <Setter Property="Height" Value="30"/>
    <Setter Property="Width" Value="150"/>
</Style>

If you run the project, you should see something like this :

The last thing we need to add is come data.  In order to do that, let’s add the following line to our MainPage code behind:

cbTest.ItemsSource = Product.GetProducts();

Running our project again, you should now have data.  Selecting an item should update the Selected Item text.

Now the we have our project set up, how can we disable individual items?  The default Item container for a CombBox is the CombBoxItem.  That means that for every item that you create, regardless if you are using the DisplayMemberPath or a custom ItemTemplate, is set inside a ComboBoxItem.  It just so happens that the ComboBoxItem object has an IsEnabled property that we can use to enable/disable the items.

Prior to Silverlight 5, there were several ways of attacking this problem, however Silverlight 5 offers a much simpler approach.  On day 6 of my 12 Days of Silverlight series I talked about the new Silverlight 5 feature of Binding in Style setters.  So how about we show this new feature in action?

We can use the new binding feature to make using the IsEnabled property a snap.  Let’s add the following Style settings to our User.Resources.

<Style TargetType="ComboBoxItem">
    <Setter Property="IsEnabled" Value="{Binding IsAvailable}"/>
</Style>

Now the IsEnabled property of the ComboBoxItem will be triggered off of our IsAvailable Product property.  Yep, it’s that easy.  Let’s rerun our application and see what we have.  If you expand the ComboBox, you will notice that the Clamp item is greyed out and you cannot select it.  And you thought you wouldn’t use binding in Style setters.  Tisk tisk…

This post was really about two things.  The first was to solve the direct problem of disabling items in your ComboBox.  The second was to give a real life example of using the binding in Style setters.

You can download the code for the project : SL5ComboBoxItemEnabled.zip

Basic Border Adorner

As we have done in the rest of the series, we will start with the code from the first post in this series, Client-Side Collections.  You can download that project here : PVB01_ClientSideCreation.zip.

We are going to start the first example with the basics.  Once you set your own item adorner, you will lose the very basic adorner that comes out of the box, the highlight border.  If you need to refresh your memory, run the project above and you will see that every time you mouse over or select an item it is highlighted with a light blue border around it.

If you dig into the PivotViewer XAML you will find that there is actually a bug here.  That light blue border is actually the selected border.  The mouse over border is a different color.  The item adorner defines a couple visual states in the group “ItemStates”.  The selected border is driven off of the “IsSelected” state.  However, the “IsSelected” state also fires on a simple mouse over, even if the items itself is not selected.  Since the selected border sits on top of the mouse over border, you will always see the selected one.  What does this mean for us?  It simply means we are not going to use the “IsSelected” visual state to drive our adorner.

Now that we have that out of the way, let’s create our item adorner.  If you read the last post , you might recall that the PivotViewer has a ItemAdornerStyle where we implemented the PivotViewerBasicItemAdorner.  Our first item adorner is going to look very similar, except we are going to remove the basic item adorner.  In fact, to show a point, it is going to look rather blank.

<Style x:Key="basicAdorner" TargetType="pivot:PivotViewerItemAdorner">
    <Setter Property="Template">
        <Setter.Value>
            <ControlTemplate>
                <Grid Background="Transparent">
                </Grid>
            </ControlTemplate>
        </Setter.Value>
    </Setter>
</Style>

To assign our adorner to the PivotViewer, we can set the ItemAdornerStyle property to our new style.

<pivot:PivotViewer x:Name="pViewer"
ItemAdornerStyle="{StaticResource basicAdorner}">
   ...
</pivot:PivotViewer>

If you run the project you will see that it’s not very exciting.  In fact, you will notice that the highlight border is missing completely.  However, that’s good.  The gives us a nice blank canvas to start from.  In order to add our highlight border back, we are going to add two Border objects to our Grid.  The first one will be visible when we you mouse over an item.  The second will show when the item is selected.  By adding the selected Border second, it will hide the mouse over one when an item is selected and the mouse is over it.

<Style x:Key="basicAdorner" TargetType="pivot:PivotViewerItemAdorner">
    <Setter Property="Template">
        <Setter.Value>
            <ControlTemplate>
                <Grid Background="Transparent">
                    <VisualStateManager.VisualStateGroups>
                        <VisualStateGroup x:Name="CommonStates">
                            <VisualState x:Name="Normal"/>
                            <VisualState x:Name="MouseOver">
                                <Storyboard>
                                   <DoubleAnimationUsingKeyFrames
                   Storyboard.TargetProperty="(UIElement.Opacity)"
                       Storyboard.TargetName="ButtonBorder">
                                 <EasingDoubleKeyFrame KeyTime="0"
                                        Value="1"/>
                                 </DoubleAnimationUsingKeyFrames>
                                </Storyboard>
                            </VisualState>
                            <VisualState x:Name="Disabled"/>
                        </VisualStateGroup>
                        <VisualStateGroup x:Name="ItemStates">
                            <VisualState x:Name="Default"/>
                            <VisualState x:Name="IsSelected"/>
                        </VisualStateGroup>
                    </VisualStateManager.VisualStateGroups>
                  <conv:CustomAdorner DataContext="{Binding .}"/>
                    <Border x:Name="ButtonBorder"
                                        Margin="-1"
                                        BorderThickness="4"
                                        BorderBrush="#AAfffc08"
                                        Opacity="1"/>
                    <Border x:Name="FocusedItemBorder"
                             Visibility="{Binding IsItemSelected,
                  RelativeSource={RelativeSource TemplatedParent},
                             Converter={StaticResource convBool}}"
                                        Margin="-1"
                                        BorderThickness="4"
                                        BorderBrush="Purple"
                                    Opacity="1"/>
                </Grid>
            </ControlTemplate>
        </Setter.Value>
    </Setter>
</Style>

Now we have some meat to work with here.  Let’s take a closer look at what is going on.  First you will notice that we added a couple of VisualStateGroups.  For this example we are going to leave the IsSelected blank due to that bug I discussed earlier.  In the MouseOver state we are setting our ButtonBorder Border objects Opacity to 1.

So how do we show the FocusedItemBorder?  The PivotViewerItemAdorner class (whose style we are currently setting) has a IsItemSelected property.  By binding the Visibility of our Border to it, we can toggle based off of that value.  In order to convert the IsItemSelected property from a bool to a Visibility, I had to create a ValueConverter that looks like this.

*Note: This is a handy little ValueConverter and you should keep this type of converter handy for your projects.

public class BoolToVisibility : IValueConverter
{

    public object Convert(object value,
        Type targetType, object parameter,
        System.Globalization.CultureInfo culture)
    {
        if(value is bool)
        {
            if((bool)value)
            {
                return Visibility.Visible;
            }
        }

        return Visibility.Collapsed;
    }

    public object ConvertBack(object value,
        Type targetType, object parameter,
        System.Globalization.CultureInfo culture)
    {
        throw new NotImplementedException();
    }
}

Don’t forget to add the ValueConverter to our XAML so we can reference it in our adorner.

<conv:BoolToVisibility x:Key="convBool"/>

If you rerun your application, you should now have two different borders that show on your trading cards.  A yellow border on the mouse over and a purple one when you select the item.  If you were wanting nothing more to get the default borders to work correctly, you are now done.  Hopefully you want to stick around and see how to take this a bit further though.

Adding Custom XAML

The above example is a great starting point, but what if we want to add a bit more interactivity in our adorners?  Turns out, it is rather easy (with a few minor catches) to do this.  We are going to wrap the rest of our adorner in a UserControl, CustomAdorner.xaml.   Our UI is going to consist of a single button for the demo’s sake.  Just to separate it from the default item adorner, we will center this button on the bottom of the card.  Here is what our new UserControl looks like:

<Grid x:Name="LayoutRoot" Background="Transparent"  >
    <StackPanel x:Name="spContainer" Orientation="Horizontal"
       HorizontalAlignment="Center" VerticalAlignment="Bottom">
        <Button Content="Time for Change" Width="200"
               Height="50" Click="Button_Click"/>
    </StackPanel>
</Grid>

The Button has a Click event handler.  Jumping to our code behind, we will show a simple MessageBox to prove we are getting what we expect.

private void Button_Click(object sender, RoutedEventArgs e)
{
    if(DataContext is DemoItem)
    {
        MessageBox.Show("DemoItem : "
              + (DataContext as DemoItem).ShortName);
    }
}

With our UserControl completed, let’s add it to our item adorner. 

<Grid Background="Transparent">
    <VisualStateManager.VisualStateGroups>
...
    </VisualStateManager.VisualStateGroups>
    <conv:CustomAdorner DataContext="{Binding .}"
        Visibility="{Binding IsItemSelected,
        RelativeSource={RelativeSource TemplatedParent},
        Converter={StaticResource convBool}}"/>
    <Border x:Name="ButtonBorder"
                Margin="-1"
                BorderThickness="4"
                BorderBrush="#AAfffc08"
                Opacity="1"/>
    <Border x:Name="FocusedItemBorder"
            Visibility="{Binding IsItemSelected,
            RelativeSource={RelativeSource TemplatedParent},
            Converter={StaticResource convBool}}"
                Margin="-1"
                BorderThickness="4"
                BorderBrush="Purple"
            Opacity="1"/>
</Grid>

If you rerun the project, you will see that our button is now shown on the trading cards whenever you mouse over a trading card.  If you click the button, you will get a MessageBox with the name of the DemoItem displayed.  Instant success right?  Well, sort of.

You might notice that this isn’t exactly what we are looking for.  If you zoom into an item, the button is positioned nice and neat in the bottom center of card.  However, when zoomed in it looks something like above. 

Why is this happening?  It is important to remember that the trading cards are XAML that have been rendered to an image.  When you define a ItemTemplate, it is always important to design for the largest size that you want to display.  This will insure that your cards always look clean.

This same philosophy is carried over to the item adorners.  The Grid in our UserControl is adjusting to the current display width and height of the trading card.  However, we defined our Button to a static width and height.  Therefore, as you zoom out, the Button begins to take up too much space.  The opposite is true if you design it too small.  Zooming into the object will make the Button look out of place by being too small.

So how do we address this?  Your first thought might be to change the size of the Button as the Grid changes its size.  While this will work, what happens when you have more than one element?  What if the item isn’t on the bottom, but is some set offset from the top?  Scaling can quickly become an issue. 

Fortunately, Silverlight has already provided an answer for us. Silverlight 5 contains a control called the ViewBox, which use to be a part of the Toolkit.  The ViewBox will automatically scale the UI within it to the appropriate size while maintaining accurate spacing, etc. This means that we can scale our Grid and everything within it will scale accordingly.

In order to implement our ViewBox scenario, we first must decide a base size for our adorner.  This is the size that all of the child elements will be designed to.  For our example, let’s choose 500×500.  We are going to wrap our StackPanel inside a new Grid that is set to the 500×500.  That Grid will then be wrapped in a ViewBox.

<Grid x:Name="LayoutRoot" Background="Transparent" >
    <Viewbox>
        <Grid x:Name="Container" Background="Transparent"
              HorizontalAlignment="Center"
              VerticalAlignment="Center"
              Height="500" Width="500"
              RenderTransformOrigin="0.5,0.5">
            <StackPanel x:Name="spContainer"
                        Orientation="Horizontal"
                        HorizontalAlignment="Center"
                        VerticalAlignment="Bottom">
                    <Button Content="Time for Change"
                            Width="200"
                            Height="50" Click="Button_Click"
                            HorizontalAlignment="Center"
                       VerticalAlignment="Center"/>
            </StackPanel>
        </Grid>
    </Viewbox>
</Grid>

If you rerun your application, you will now see that the button scales according to the size of the trading card.

If you wanted the button to only show up when the item is selected, then we can borrow the Visibility binding for our selected Border.

<conv:CustomAdorner DataContext="{Binding .}"
                    Visibility="{Binding IsItemSelected,
    RelativeSource={RelativeSource TemplatedParent},
    Converter={StaticResource convBool}}"/>

And there you have it.  The sky is now the limit on what you can do.  Well, that is until you run into a wall somewhere that I haven’t found.  Regardless, this does open up a great deal of possibilities on what you can add to your trading cards.

You can download the source to this post here : PVB05_CustomAdorner.zip

As I said at the beginning of this post, this wraps up our basics series.  What’s next?  Well I have a stack of random posts that need to be written to address various topics.  I thought I would then come back and maybe do a series on trading card designs. Until then…

Happy Pivoting…

In the original PivotViewer, there was a concept of custom actions.  Defining custom actions allowed you to add a button on top of the selected trading card.  In fact, you could add several items to the card.  This gave you the ability to provide limited interactivity with the trading card to the user.  The new Silverlight does away with custom actions and replaces them with item adorners. (note: if you implemented custom actions in the previous version, this is another breaking code change)

Simply put, an item adorner is XAML that is placed over a trading card.  If you define an item adorner it is displayed over a trading card when either a mouse over event happens or the item is selected.  This opens a wide range of possibilities for your trading cards.  Now you can add additional information or interactive controls without the need to leave the PivotViewer.  PivotViewer comes with a default adorner, PivotViewerDefaultItemAdorner (yep, gotta love those short names).  This adorner mimics the functionality of the custom actions in the previous version.  In this post we will take a look at this new control.

Implementing the Default Item Adorner

In order to get us up and running quicker, we are going to start with the project created in the 1st post of the series, Client-Side Collections.  You can download the code here: PVB01_ClientSideCreation.zip

Adding the default item adorner is not the most trivial thing in the world, however it’s not overly complicated.  PivotViewer exposes  an ItemAdornerStyle property where you can set a style to define your item adorner.  Let’s look at what this style will look like using the PivotViewerDefaultItemAdorner.

<Style x:Key="basicAdorner"
          TargetType="pivot:PivotViewerItemAdorner">
    <Setter Property="Template">
        <Setter.Value>
            <ControlTemplate>
                <pivot:PivotViewerDefaultItemAdorner
                    IsItemSelected="{Binding IsItemSelected,
                RelativeSource={RelativeSource TemplatedParent}}"
              CommandsRequested="basicAdorner_CommandsRequested"/>
            </ControlTemplate>
        </Setter.Value>
    </Setter>
</Style>

This code creates a style of a PivotViewerItemAdorner.  In the template of that control, we are adding a PivotViewerDefaultItemAdorner.  The IsItemSelected property binds that property to the base PivotViewerItemAdorner.  This let’s us know when the item is simply a mouse-over event or the item has been selected.  The CommandsRequested property allows us to create custom commands and display/interact with them on the current trading card.

Here is an example of what the CommandsRequested event handler will look like.

private void basicAdorner_CommandsRequested(object sender,
    PivotViewerCommandsRequestedEventArgs e)
{
     e.Commands.Add(new AddCommand());
}

The PivotViewerCommandRequestedEventArgs has 3 important properties.  The first, as shown above, is a collection of IPivotViewerUICommand objects that defines what commands (aka buttons) to add to the control.  Next is an Item property that gives you access to the data object being referred to.  Finally, an IsItemSelected property tells us if the object has been selected or not.  We will look at that more in a little while.

The IPivotViewerUICommand interface allows you to define what it being displayed to the user and what do to if the user selects it.  Here is what a base implementation of the interface will look like.

public class Class1 : IPivotViewerUICommand
{

    public string DisplayName
    {
        get { throw new NotImplementedException(); }
    }

    public Uri Icon
    {
        get { throw new NotImplementedException(); }
    }

    public object ToolTip
    {
        get { throw new NotImplementedException(); }
    }

    public bool CanExecute(object parameter)
    {
        throw new NotImplementedException();
    }

    public event EventHandler CanExecuteChanged;

    public void Execute(object parameter)
    {
        throw new NotImplementedException();
    }
}

As you can see there isn’t a whole lot going on here.  The DisplayName, ToolTip, and Icon properties are used for the display.  If CanExecute returns true, then the Execute method is called when the user selects it.  If you go back to our event handler above, you will see that I added an AddCommand to the item.  The AddCommand class will display a MessageBox if the user selects the command.

public class AddCommand : IPivotViewerUICommand
{

    public string DisplayName
    {
        get { return "Add Item"; }
    }

    public Uri Icon
    {
        get { return null; }
    }

    public object ToolTip
    {
        get { return "Add Item to cart."; }
    }

    public bool CanExecute(object parameter)
    {
        return true;
    }

    public event EventHandler CanExecuteChanged;

    public void Execute(object parameter)
    {
        var itm = parameter as DemoItem;
        MessageBox.Show( itm.ShortName + " was added");
    }
}

The only thing left to do is to let our PivotViewer know of the new ItemAdornerStyle that we wish to use.  You can set this in code of XAML.  Here we will simply set it in our XAML.

<pivot:PivotViewer x:Name="pViewer"
    ItemAdornerStyle="{StaticResource basicAdorner}">
...
</pivot:PivotViewer>

If you run the project, you will now see a new command on each trading card when you select it.  Clicking the Add Item button will show a MessageBox letting you know that your item has been added to our mythical shopping cart, bug list, or what ever we decide to build.

You may also notice that the command will show up whether the item is selected or if you simply mouse over it.  This gets us back to the IsItemSelected property of the PivotViewerCommandRequestedEventArgs. We can take advantage of this property in our event handler and only add the AddCommand if the item is actually selected.

private void basicAdorner_CommandsRequested(object sender,
    PivotViewerCommandsRequestedEventArgs e)
{
    if (e.IsItemSelected)
    {
        e.Commands.Add(new AddCommand());
    }
}

If you re-run your application, you will notice that we are no longer showing the command on the mouse over.

Creating an Interactive Adorner

The above example shows you how to use the PivotViewerDefaultItemAdorner to mimic the custom actions of the first release.  However, this isn’t the first release, so let’s advance things just a bit to get a better feel for how this can work.

For this example, we are going to create a new command.  This new ColorCommand will allow us to change the color of the current object.  Like the AddCommand, this command is rather straight forward.  However, in the Execute method, we will assign the item’s color to the CommandColor property defined in the command.  It wasn’t addressed in the example above, but the parameter argument that is passed into the Execute method is the data object that we are currently interacting with.  Here is what the new ColorCommand looks like.

public class ColorCommand : IPivotViewerUICommand
{

    public string CommandColor { get; set; }

    public string DisplayName
    {
        get { return CommandColor; }
    }

    public Uri Icon
    {
        get { return null; }
    }

    public object ToolTip
    {
        get { return "Change color to " + CommandColor; }
    }

    public bool CanExecute(object parameter)
    {
        return true;
    }

    public event EventHandler CanExecuteChanged;

    public void Execute(object parameter)
    {
        var itm = parameter as DemoItem;

        itm.Color = CommandColor;
    }
}

Now we need to modify our event handler to add the new command.  We are going to add several command in this example.  The commands we add will be based on the current item’s color.  For example, if the current item is red, then we will add a blue, green, and purple command.  By adding logic into the command creation, we are able to provide a better experience to the user.  For instance, what good does a red button have on a red object?

private void basicAdorner_CommandsRequested(object sender,
    PivotViewerCommandsRequestedEventArgs e)
{

    if (e.IsItemSelected)
    {
        var itm = e.Item as DemoItem;

        if(itm.Color != "Red")
            e.Commands.Add(new ColorCommand()
                               {
                                   CommandColor = "Red"
                               });
        if (itm.Color != "Blue")
            e.Commands.Add(new ColorCommand()
                               {
                                   CommandColor = "Blue"
                               });
        if (itm.Color != "Green")
            e.Commands.Add(new ColorCommand()
                               {
                                   CommandColor = "Green"
                               });
        if (itm.Color != "Purple")
            e.Commands.Add(new ColorCommand()
                               {
                                   CommandColor = "Purple"
                               });
    }
}

Running our application now, you will notice that any selected item will have 3 commands.  Selecting the command will update the object and dynamically change the color of the trading card.  Hopefully you can see how this could be very beneficial to you in more advanced situations.

In the next post in this series, we are going to look at creating our own item adorners.  I have received a lot of questions on this subject and thought we would explore it some.  You can download the source code for this project here: PVB04_BasicItemAdorners.zip

Until then… Happy Pivoting…

Setting the Stage

Before I get into the review itself, let me set the stage a bit first.  I have been giving technical presentations for the last two years.  I don’t really get the opportunity to present as often as I would like, but I give about a dozen presentations a year.  I have had the opportunity to speak at some great conferences, like VS Live, and am looking forward to future opportunities.  Not being a naturally gifted speaker, I still remember my first presentation and what a train wreck it was (it was bad…).

However things have gotten better over the last two years and my presentations continue to improve. I have learned a ton of things over the this time, mostly what not to do, and have received a lot of tips from some very accomplished speakers.  When Scott released the new TekPub video I decided to give a look.  I watched it a few weeks ago and tried to put some of the things I learned into practice last night.  So how did it go?  Well…

I don’t really want to give out too much of the video, but I started off with a bang.  Scott talks about his need to make sure he knows the exact setup of the room, hardware, connectivity, etc.  That point got beat into my head last night with a sledge hammer.

I had given a presentation at this user group a few months back and the projector had a HDMI port.  So I thought nothing off it last night and showed up with my fancy new ultrabook to present my Windows 8 talk on.  I even had a backup machine in case I needed it.  However, it was the Build tablet and guess what, only HDMI.  So imagine how happy I was when a room change put us in a room with no HDMI port.   After running through several attempts to get a work around, we were finally successful.  Now you geeks out there will probably like this.  We had to create an Ad-Hoc network on another laptop (one with a VGA port) and remote desktop into my box.  It killed my one demo that needed internet access, but it got me up and running.  Boys and girls, anyone care to guess what the lesson we learned here was?

After getting off to a very shaky start, the presentation went well enough.  Ok, no one fell asleep so I figure that has to be a win, right?  On the way home I was reviewing the talk and decided it would be a good idea to write this review.

Finally, the Video Review…

Hopefully that gives you a better idea of where I am coming from on this review.  I started off as most technical presenters do and am still working my way to becoming a better speaker.  So that brought me to Scott’s video. 

To sum it up, the video itself is excellent and has probably been the most I have learned about giving presentations in a single shot.  In the video Rob Conery presents Scott with a topic and asks him to prepare and give a 15 minute presentation on it.  That is where the value of this video comes in.  Scott has written several posts over the years on tips to becoming a better speaker and there are several other great resources out there as well.  However, being able to watch an accomplish speaker prep for a talk has a ton of value that you can not get from a list of tips.  It gives you a chance to see how he dissects the topic, preps the demos, and how it all comes together in the final presentation.  Of course the process is scaled back so that it will all fit in a reasonable length video, but you still are able to get a sense of the his process.

So I put some of the things I learned in the video to the test.  First off, preparing for my talk was much easier and I felt much more comfortable with what I had going into my presentation (that is before the HDMI fiasco).  As for the talk itself, I honestly didn’t see a lot of changes though.  Which, at first, was a bit disappointing.  However, when I was reviewing the talk on my way home I started making several connections.  Instead of simply thinking that the talk could have gone better, I began to map specific things that I did or did not do to some of the things I saw in the video.  It gave me a better understanding of what needed to be changed and an example of how I could change it.  To me, that is a win.  It is always easier to improve something when you have an idea of what to improve and how to improve it.

Would I recommend this video? Without a doubt I would.  I believe you can purchase the video by itself for $18.  I went for the annual subscription to TekPub instead.  I honestly think Scott’s video alone would be worth the price of the annual subscription but now I get access to all of TekPub’s other great material as well. 

Scott has some more information about the video and links to his other posts on speaking at SpeakingHacks.com.  Scott and Rob also have a podcast that is quite interesting called This Developer’s Life.  Of course they both have very active twitter accounts (@shanselman and @robconery).

For any of the speakers out there, especially the ones just starting or thinking about starting, I wish you all the best.  While speaking is something that I forced myself to start doing, I have really began to enjoy it and hope others do as well.

On the twelfth day of Silverlight the team delivered to me… PivotViewer.

Anyone who knows me, knows I have a special interest in the PivotViewer.  Simply poking around this blog should show you that.  I’ve given talks across the country on the subject, I’ve blogged about it, and I’ve even tried to write a book on the subject (although I couldn’t find a publisher to pick it up).  Why the interest?  Because I think it is an amazing example of data visualization. 

History of PivotViewer

PivotViewer got it’s start in the Live Labs team.  It original appeared as a WPF application called Pivot.  Although no longer supported, you can still download the original application on Microsoft’s Research page.

The first version of PivotViewer was release in 2010 and worked with Silverlight 4.  While containing most of the features you have in the latest version, it’s data was largely static in nature.  It utilized a XML format, CXML, and mapped data items to members of a DeepZoom collection (which was also written by the Live Labs team).  While useful in certain use cases, it’s limited API and static image nature kept the control from being used in many scenarios.

Even with these limitations, the PivotViewer was well received and in time the team moved to the Silverlight team and PivotViewer became an official Silverlight control.  With a major revamp the new PivotViewer came packed with a lot of new goodies.  While still supporting CXML, you can now create client side collections and generate your visuals dynamically with XAML data templates.  The API has been expanded and you now have a lot more control over appearance and behavior.

While still not perfect, it has come a long way and can now be used in a lot of scenarios that it previously couldn’t.

Anatomy of PivotViewer

The first two things you need is data and visualizations (hey, maybe that’s where data visualizations came from <grin>).  The new PivotViewer gives you several ways to accomplish this.  Once you populate PivotViewer with both of these, your screen will load and you will see 3 distinct areas.

The main area is the collection container.  It is the heart of the control.  You are able to zoom in and out, pan and scroll with the mouse, etc.  The collection container has two different views: grid view and histogram view.  The grid view lays out your items in a nice grid based on the selected sorting property.  The histogram view will group the items (based on the sorting property) and show them in more of a bar chart.  This gives the user a powerful visualization of comparing counts based on a selected property.  A nice bonus is if you double click a histogram column, it will drill down into that column to give you a finer resolution of the data within.

Above the collection container you have the control bar.  It contains items such as a zoom bar, the sorting property selector, and the ability to switch between grid and histogram view.

To the left you will find the filter panel.  The nicest thing about the filter panel is that it is generated for you.  Each property you define in your data objects is displayed here.  It automatically generates data ranges, value selections, etc.  Adjusting the filter conditions will instantly adjust the items included in the collection container.  Not bad functionality for free.

If you select an item you will see an additional panel displayed on the right, the detail pane.  This contains the specifics about the selected item.  While having a built in view, the new PivotViewer also allows you to create a custom detail pane and I show you a walk through here : Creating a Custom DetailPaneStyle.

By far the best addition to PivotViewer in SL5 is the dynamic nature of it.  If you make any changes to the data items within the application, the changes are instantly reflected in the information and visualization of the object within the PivotViewer.  This creates a lot of use cases where PivotViewer would be a great fit.

Developing with PivotViewer

So I’m going to take the easy way out here and we are not going to run thru a PivotViewer example in this post.  The reason is I have another series on doing just that.  If you want to get your feet wet with the new PivotViewer take a look at my PivotViewer Basics series.

I do want to make a quick shout out here.  Chris Arnold has two great products out there that include PivotViewer: PhotoPivot and Percollate. If you want to see some of the exciting ways you can use PivotViewer in your applications, I highly recommend checking both of those out.

The End of a Series…

As I said at the beginning of this post, this has been a great series to write.  I think the Silverlight 5 release goes a long ways in the right direction.  There are a lot of additional features that this series did not touch on and I would encourage you to go explore them.  You can find out all about the new release on Silverlight.net.

I will wrap up this series by stealing a phrase from a good friend of mine (who will probably exclude this post from his site because of it <grin>).

.. stay in the ‘light ..

On the eleventh day of Silverlight the team delivered to me… 3D.

Yep, that’s right, we now have a 3D stack in Silverlight.  For any of you Xbox developers out there, it should look fairly familiar.  The 3D stack in Silverlight is based off of the XNA framework.  Call it a XNA lite if you will.  While we are not going to build the next blockbuster game, I do think it will be fun to take a look at what 3D looks like inside of Silverlight.

Creating a 3D Applications

If you fire up Visual Studio, you will see two new Silverlight solution types available to you : Silverlight 3D Application and Silverlight 3D Library.

Our example is going to focus on the 3D Application.  If you create the new solution you will see that it creates 4 projects for you.  Two of them should be familiar to you, a SL project and a Web project.  For our 3D application, we have two additional projects (one for the SL side and one for the web).  These projects are there to hold your resources for your application.  In fact, if you try and add a new item to either project you will notice that you are limited to the following items:

So now that we have a project created, let’s F5 it and see what we get.  Isn’t that a nice little error?  You probably are looking at a notification that you need to enable GPU acceleration.

Now the fun thing is that when you look at the created web pages, you should see that GPU acceleration is already turned on.  So what’s going on?  Well it turns out that elevated trust is required to run 3D applications.  So turning on elevated trust, whether you are in-browser or out, will get you going.  However, you will still need GPU acceleration so don’t turn that off. 

Giving the old F5 another try, we see that we have our first 3D application.  It even comes complete with a spinning cube.

Going down the rabbit hole of developing 3D applications is beyond the scope of this post, but I did want you to at least get something up and running.  Make sure you let me know what cool things you come up with.

Eleven down and one to go.  Anyone care to guess what the last post is going be?  See you soon.