The hands-on-lab is intended to be an introduction to the Model-View-ViewModel (MVVM) pattern. It integrates directly inside Visual Studio, with documentation, examples and even automatic code snippet copying, all in one place. The hands-on-lab walks through the pattern step-by-step using examples that are easy to understand, and illustrates the benefits of MVVM in a concrete way.

As was the case with the VS2008 MVVM Toolkit, it is not intended to replace community libraries. I hope you find it useful!

At the time we started working on the toolkit, there were a multitude of MVVM libraries in development, but few had documentation or samples, and even less were targetting people who had never tried MVVM before. We felt the ramp up needed to try MVVM and get the basics of the pattern with these libraries were such that it hindered adoption. At the same time, as a member of the WPF team, it was difficult to justify spending too much time writing libraries and templates, given we had more than enough work on the platform itself.

For that reason, we decided to invest some limited resources in developing a toolkit for VS2008, in the hope that it would justify changing the default WPF template in Visual Studio, given VS2010 was still in development. The positive outcome is that the toolkit was more successful than we had hoped, but the templates unfortunately didn't make the cut for VS2010.  I moved shortly afterwards to a different role and team; in fact, I also physically moved to a different country and a different continent.

I also wanted to say thanks to the numerous people who took the time to provide feedback. Although I realize it was far from perfect, I hope many found the VS2008 MVVM toolkit useful!

• Silverlight 4.0 RC available here.
• Windows Phone platform tools available here.
• VS 2010 Express
• Windows Phone Emulator
• Silverlight for Windows Phone
• XNA 4.0 Game Studio
• Expression Blend 4.0 Beta, available here.
• Windows Phone add-in for Expression Blend 4.0 Beta available here.
• Expression Blend SDK for Windows Phone available here.

There were a number of other announcements made already, including the Pivot control for Silverlight 4.0, which lets you slice and visualize large amounts of data in a seamless and intuitive way. Very impressive, and I'm looking forward to seeing the samples and applications developers will be creating!

The three controls in question are:

• Accordion
• AutoCompleteBox
• Rating

The controls are nearly identical to their SL counterparts, with an explicit goal of maintaining compatibility between the two. This will hopefully make it easier to take a dependency on either toolkit, and allow the application to be ported from SL to WPF, or WPF to SL, without having to come up with creative solutions.

Many thanks to David Anson, who wrote a great blog post on the new release, for his continued support and help, as well as both the SL and WPF toolkit teams. We hope you find the newly added controls useful, and always appreciate the feedback!

First, a new Facebook SDK was unveiled last week, making it easy to develop .Net applications that interact with the popular website. The SDK has support for both WPF and SL. If you're not sure which technology to pick, why not both? At least, that's what we're going for!

We recently released a WPF application called Fishbowl, which makes use of the SDK and provides a great client experience. You can get the application here and read more about it here. There unfortunately isn't a Silverlight version available, but that may very well change!

One of the reasons I've been working with WPF for so long is because I believe it's one of the few platforms that enables truly compelling user experiences. One such application is called Pivot, from the MS Live Labs team. The chrome of the application was done in WPF, and the application leverages DirectX as well. Although the app is currently only available by invitation, I still recommend checking its website if you want to learn more. For the time being, here's a video that demonstrates some of the things you can do:

First, kudos to the customer for taking the time to test the custom control, and realizing there was an issue to begin with. This is a good example of why it's important to do software testing and verify assumptions, as although things seem to “just work”, that’s not always the case.

The custom control in question is a modified tab control, with a Header property that allows you to specify content in addition to the usual tab items. This is a little similar to the concept of a HeaderedContentControl, and the markup would look like this:

   <local:CustomTabControl Style="{StaticResource TabControlStyle}">
      <local:CustomTabControl.Header>
         <!-- Any content can go here -->
         <Button Content="Header Button" />
      </local:CustomTabControl.Header>
      <local:CustomTabControl.Items>
         <TabItem Header="Tab 1" />
         <TabItem Header="Tab 2" />
      </local:CustomTabControl.Items>
   </local:CustomTabControl>

As you may have guessed, the problem is that although the custom tab control exposed the tab items properly to UIA, it didn’t also expose the Header content. Is this expected? Yes, because controls in WPF are responsible for exposing their UIA items themselves.

This is done through the AutomationPeer class. All the major control classes in WPF, such as TabControl, have a corresponding AutomationPeer class that exposes the control’s functionality to UIA, creatively named TabControlAutomationPeer in this case. This is explained in some detail in this MSDN page.

When a UIA client looks at the structure of the application, WPF will raise the OnCreateAutomationPeer event on elements in the WPF application tree. In the case of a regular TabControl, when the event is raised, a TabControlAutomationPeer instance is created. If you write a custom control but don’t handle this event, the behavior of the base class your control derives from is the behavior that will be exposed to UIA. Since TabControlAutomationPeer doesn’t know about the newly added Header property in CustomTabControl, it doesn’t expose it to UIA.

Now that the problem is clearer, lets focus on a solution. In order for CustomTabControl to behave as expected, you would need to create its CustomTabControlAutomationPeer counterpart. Since we’re only adding one property to TabControl, we can derive from TabControlAutomationPeer and reuse most of the base class functionality:

   public class CustomTabControlAutomationPeer : TabControlAutomationPeer
   {
      public CustomTabControlAutomationPeer(TabControl owner)
         : base(owner)
      {
      }
      
      protected override string GetClassNameCore()
      {
         return "CustomTabControl";
      }
      
      protected override List<AutomationPeer> GetChildrenCore()
      {
         List<AutomationPeer> automationPeers = base.GetChildrenCore();
         CustomTabControl owner = base.Owner as CustomTabControl;
         if (owner != null)
         {
            UIElement headerUIElement = owner.Header as UIElement;
            if (headerUIElement != null)
            {
               AutomationPeer peer = UIElementAutomationPeer.CreatePeerForElement(headerUIElement);
               if (peer != null)
               {
                  automationPeers.Add(peer);
               }
            }
         }
      
         return automationPeers;
      }
   }

   public class CustomTabControl : TabControl
   {
      ...
      protected override AutomationPeer OnCreateAutomationPeer()
      {
         return new CustomTabControlAutomationPeer(this);
      }
   }

If you launch a UIA tool like UI Spy (great tool which is available in the .Net Framework SDK), this is what you would see before the change, with a view scoped to the custom tab control:

This is what you can see after the change, with the Header button properly exposed:

So is that all we need? Actually, no. There is an issue with the solution I have described so far. What happens if the content of the Header property is changed to something else? At the moment, nothing from a UIA perspective. Because UIA doesn’t keep track of changes, and because you didn’t notify it of any changes, the image you see above would remain the same, and it would incorrectly believe the Header content is the same.

To solve this, you need to find a way to notify UIA of the change. Luckily, WPF makes this fairly straightforward when using a DependencyProperty, which is how you would expose a Header property in the custom control. When you declare the property, you can specify a PropertyChanged handler for the Header which would look like this:

   public class CustomTabControl : TabControl
   {
      ...
      public static readonly DependencyProperty HeaderProperty = DependencyProperty.Register("Header", typeof(object), typeof(CustomTabControl),
         new FrameworkPropertyMetadata(OnPropertyChanged));
      private static void OnPropertyChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
      {
         CustomTabControl tabControl = d as CustomTabControl;
         if (tabControl != null && (e.OldValue != e.NewValue))
         {
            if (AutomationPeer.ListenerExists(AutomationEvents.StructureChanged))
            {
               // Notify the UI automation client that the content changed
               TabControlAutomationPeer peer = UIElementAutomationPeer.FromElement(tabControl) as TabControlAutomationPeer;
               if (peer != null)
               {
                  peer.RaiseAutomationEvent(AutomationEvents.StructureChanged);
               }
            }
         }
      }
   }

When the Header content changes, this raises an event which lets UIA know it needs to perform an update. A VS 2008 sample with all the code in this post can be found below, and hope you found this useful!

CustomTabControlSample.zip

The set of 4 posts walk through how to write a simple panel that implements part of the IScrollInfo interface, which is needed to allow the ScrollViewer control to delegate the responsibility of scrolling.

Part 1, Part 2, Part 3, Part 4

We encourage you to try it out and give us your feedback! You can find the latest release of the TestAPI library here.

The template is meant to introduce the Model-View-ViewModel (M-V-VM) design pattern to the WPF community. It includes:

• A Visual Studio 2008 template (Visual C# Express 2008 also supported)
• Documentation
• General introduction to M-V-VM
• Walkthrough using the VS template
• A complete WPF application demonstrating the MVVM pattern

We hope you find it useful. Feel free to try it out and share your comments/suggestions!

The list of new features being released in the products is nothing short of impressive. This article at Wired Magazine does a good job of going through the main features, but if you’re short on time, the highlights are as follows:

Silverlight:

• HD Streaming of 720p without buffering
• Standalone application support (aka out of browser!)
• Hardware acceleration
• 3D visual features
• Multi-touch support
• Eclipse for Silverlight support on the Mac

Expression Blend:

• Sketchflow feature allows for quick prototyping of workflow by defining states and transitions between states
• Import files directly from Adobe Illustrator/Photoshop
• Export workflow to an automatically generated Word document

If you’ve been holding off trying out Silverlight, this seems like a great time to take a closer look!