Following up on that previous post, the other side of the PivotViewer story is about the PivotViewer control itself.

I find it “interesting” that my simple use of the control here;

is using a collection that is available to anyone else to display in a PivotViewer control but the overall way in which a user “experiences” the collection is defined by a combination of the collection, the control and the code that’s been written around the control.

That is, the collection itself doesn’t define everything about how it’s interpreted – it’s up to the programmer using the control for instance to decide what to do when a hyperlink is clicked which means that there’s some level of coupling between the links in the collection and the code that’s interpreting those links.

Anyway, the control is easy enough to add a reference to and to drag and drop out on the design surface.

In Visual Studio and Expression Blend the route to success seemed to be to add a reference to all of the Pivot related assemblies;

• System.Windows.Pivot.dll
• System.Windows.Pivot.Model.dll
• System.Windows.Pivot.SharedUI.dll
• System.Windows.Pivot.StringResources.dll
• System.Windows.Pivot.Utilities.dll

then doing a quick build before dragging the control from the Toolbox ( which you might have to do a right mouse on and “Customize” to get it to show the PivotViewer control ) seemed to work pretty well.

I did encounter one or two error messages with “COM” in the description when dragging the control from the ToolBox. Generally though they were worked around by just building in Visual Studio and trying again.

In this version of the control, if you go into Blend and edit the template for the control then you’ll find an empty template so the look and feel of the control is “baked” into it right now unlike most Silverlight controls that can have their look-and-feel customised by editing templates.

I’ve seen some “we would like this to change” feedback on this aspect of the control in the sense that Silverlight developers expect controls to be highly templated but, nonetheless, it’s a control with a tonne of functionality so even minus templates there’s a lot that you get here.

I also found that setting properties like FontSize, FontFamily, Foreground, Background didn’t really seem to make any difference to the control – I had to research that a little bit and watched the video up here which talks about it but I still didn’t figure it out and the forum post here looks to suggest that there’s no styling here and, as far as I know from asking the team involved, that’s true – the styling of the control is fixed right now.

So, beyond styling – what are the client-side interactions that are enabled by the control? There’s a number of events you can handle which seem fairly self-explanatory;

• CollectionLoadingCompleted/CollectionLoadingFailed
• ItemDoubleClicked
• ItemActionExecuted
• LinkClicked

I looked at the last one in the previous post around using it to respond to links clicked in the info panel so apart from that the only other one that’s not so intuitive is the ItemActionExecuted. To get that “Item Action” event to fire you need to derive from PivotViewer and then override the GetCustomActionsForItem method which looks something like;

protected override List<CustomAction> GetCustomActionsForItem(string itemId)
    {
      return (new List<CustomAction>()
      {
        new CustomAction("Action1", new Uri("info:action1"), "Action 1 Tooltip", "Action 1 id"),
        new CustomAction("Action2", new Uri("info:action2"), "Action 2 Tooltip", "Action 2 id")
      });
    }    

and that manifests itself in the UI with;

There’s also a slot to supply an Icon for those custom actions and clicking on one causes the PivotViewer.ItemActionExecuted event to fire and delivers an event args shown here in the debugger;

so it’s fairly clear that the Id associated with the action that fired is being passed through to this event and so is the Id of the Item on which it was fired and then you can go and “do something” with that information to respond to the user taking the action on the particular item.

Similarly, if an item is double-clicked you get to know which item it was.

To get more information about an item ( Facets, Href, Id, Name ) there’s the GetItem() method on the PivotViewer which returns those details about an item when passed an id such as the one being presented in these events.

Beyond that, there’s a bunch of properties that the control is surfacing – namely things like CollectionName, CollectionItemCount, CollectionUri, CurrentItemId, SortFacetCategory, ViewerState. I did a bit of element binding to pick those up as in simple stuff like;

        <StackPanel
            Grid.Row="1">
            <TextBlock
                Text="{Binding ElementName=pivotViewer1,Path=CollectionName,StringFormat=CollectionName \{0\}}" />
            <TextBlock
                Text="{Binding ElementName=pivotViewer1,Path=CollectionUri,StringFormat=CollectionUri \{0\}}" />
            <TextBlock
                Text="{Binding ElementName=pivotViewer1,Path=CollectionItemCount,StringFormat=CollectionItemCount \{0\}}" />
            <TextBlock
                Text="{Binding ElementName=pivotViewer1,Path=CurrentItemId,StringFormat=CurrentItemId \{0\}}" />
            <TextBlock
                Text="{Binding ElementName=pivotViewer1,Path=SortFacetCategory,StringFormat=SortFacetCategory \{0\}}" />
            <TextBlock
                Text="{Binding ElementName=pivotViewer1,Path=ViewerState,StringFormat=ViewerState \{0\}}" />
        </StackPanel>

and so that displays for me those properties as they change;

so I can see which item I’m currently focused on and how many items there are in the collection and so on. There’s also properties to get hold of the InScopeItemIds and the AppliedFilters which are Dictionaries so I’d need to do more work to bind to those as I did with my simple TextBlocks up above.

However, they’re pretty intuitive representing the filters that have been applied ( e.g. with this MSDN example I could filter down to the articles that have been “Viewed Often” and if I do so then my InScopeItemIds gets reduced from the full 2060 down to just 206 and the filter that I’ve appled gets added to the AppliedFilters list.

In comparison to the collection side of things, the viewer control seems relatively simple but I guess that’s because it’s already doing a lot of work for you “out of the box” – I guess it’ll grow more abilities over time as/when new versions become available.