In this blog post I take a look at Windows 8 on the outside, from a user perspective; and on the inside, from a developer perspective to see how it will change the way we develop with Windows on tablets, smartphones and the desktop when it is released next year.

In Anaheim, California, the Microsoft //build/ conference is drawing to a close. And as the attendees head for home, with their shiny new Samsung tablets under their arms, the news of Windows 8 and the impact it has on end-users and developers is starting to sink in around the globe.

There is no doubt that the impact of Windows 8 is going to be very large, it heralds the biggest change in the Windows architecture since 1993 and from an end-user perspective it is like no other version of Windows before it.

So why such a radical change to both the UI and the architecture? and why now? The answer to this question is quite simple … tablets. Previous versions of Windows have been targeted primarily at the desktop, laptop and netbook form-factors where the primary input devices are mouse and keyboard, and memory, disk-space, CPU performance is aplenty. Tablets have made the odd cameo appearance in the history of computing, but it is only recently with the launch of the iPad that they have suddenly become mainstream.

To take the Windows OS to a tablet it needs to be stripped-down, made faster and support multi-touch (or touch-first – a new Microsoft buzzword) and with Windows 8 Microsoft have done just that. With the requirements of a tablet interface being so different to a desktop, how have Microsoft reconciled these differences? The answer is a little surprising … they haven’t! They could have launched a dedicated Tablet Windows OS, just as they have done on the mobile with Windows Phone 7, but instead they have launched a single OS that works for both tablet and desktop. As a result it has something of a split personality. You can choose to run either the Metro or the ‘classic’ desktop UI on your tablet computer and you have exactly the same choice on your desktop.

An end-user perspective

The Windows 8 user interface uses the same Metro style that Microsoft introduced with Windows Phone 7, bright colours, clean edges, a lack of drop-shadows and other adornments. The style is heavily influenced by fonts and designs used for road and street-signs. The same concepts of clarity-at-a-distance translates very well to a small smartphone screen and should be equally at home on the tablet.

When applications are launched they run full-screen, with a similar multi-tasking model to Windows Phone 7 where hidden applications are suspended. These features, combined with the fast shutdown / restart times make sense for tablet users where limiting the work that the processor does will significantly enhance battery life.

You can run multiple applications side-by-side in a split-screen mode:

The current preview of Windows 8 has a few of the familiar applications available in the new Metro-desktop, these include IE which is now chromeless, i.e. it is permanently in full-screen mode. Gestures are used to reveal the open tabs or URL. Notably the Metro IE does not support any plugins, i.e. Flash, Silverlight – more on this later!

Metro applications for Windows 8 are distributed via the Windows Marketplace in much the same way as they are for Windows Phone (and iPad, Android etc…).

The Windows 8 UI clearly has tablets in mind and recent reviews by Engadget and Gizmodo seem to indicate that the experience is very good and agree that when released it could be a serious competitor to the iPad.

However, hidden behind the glossy Windows 8 UI sits the more traditional Windows 7 style desktop. Simply click (or touch) the desktop button and the old-familiar Windows desktop appears. It almost feels like the desktop is an app running within the new Metro UI – you can also run a split screen which combines the Metro and desktop UIs:

Interestingly if you want to run IE with plugins, there is a fully-featured version of IE present on the desktop. Try explaining these differences to your grandmother!

For a tablet, Windows 8 gives you the best of both worlds, an immersive and tactile Metro interface, plus the old-familiar Windows desktop.

On the desktop, Windows 8 does feel a bit strange. Metro applications are designed to work with the mouse and the keyboard, so it functions just fine, however, on a desktop monitor the Metro UI feels like a bit large and a touch gimmicky. The Metro concepts work well for small screens, but in my opinion are less effective on a large desktop monitor, especially in the absence of touch. I doubt it will make a big impact for desktop users, but at least they have the choice! When used on a PC with multiple monitors the new Metro UI is confined to a single screen, again further illustrating its tablet focus.

A developer perspective

Windows 8 marks a radical change from the outside, but what about on the inside? What is the developer story?

One of the most important diagrams revealed in the keynote is the Windows 8 architecture diagram:

It is clear that the split personality of Windows 8 runs very deep. In this diagram you can see that Metro style apps and desktop apps share the kernel, but nothing else. This is a pretty significant change in Windows architecture; Metro apps are finally free of the Win32 APIs which .NET has been built upon.

The APIs for developing Metro apps reside within the WinRT. A few keys things to know about this new architecture are:

• WinRT applications are chromless, fullscreen, with no pop-up or modal dialogs
• WinRT is an Object Oriented replacement for Win32
• WinRT is very similar to .NET, however a number of APIs such as file I/O, security etc… are not present.
• You can develop with C++, or C# etc… in much the same way as .NET applications
• The UI defined using XAML, as per WPF and Silverlight
• You can potentially port Silverlight applications to WinRT by changing a few namespaces
• JavaScript is a first-class citizen of Windows 8, using a HTML UI

The above already tells us a lot about WinRT and Metro applications. My first thoughts are that they are much more similar to Windows Phone 7 applications than desktop WPF applications. They live within a sandbox which uses a restricted subset of APIs, you certainly cannot write a virus checked or hard disk partitioning tool with WinRT!

Furthermore, when developing Metro UI apps, Visual Studio ‘deploys’ your application too your Windows 8 Metro desktop in exactly the same way as it does with the WP7 phone.

So what about existing .NET applications? The important thing to know is that all the ‘old’ APIs are still there. Your WPF, Silverlight and WinForms applications are safe! There were also a few new WPF features announced at //build/ as part of .NET4.5, but they are not very interesting, it is clear that Microsoft has been putting its energy into other things.

The JavaScript / HTML5 story is a bit of an odd one. Clearly Microsoft has embraced these technologies, with JavaScript having full access to the WinRT. Furthermore, they have added APIs for creating Metro UIs with HTML. However, I am not sure why someone would want to use JavaScript to create Windows 8 Metro applications? The main strength of JavaScript and HTML5 is the portability due to its support on a wide range of browsers, tablets, phones, etc… The Windows 8 JavaScript Metro apps are ‘tied’ to WinRT so are in no way portable.

Questions …

Lots of questions … the rather complicated nature of Windows 8 has resulted in quite a lot of confusion.

Is Silverlight Dead? – this was probably the most oft asked question before //build/ and it is still being asked. The news that the Metro IE10 will not run Silverlight is certainly not good news for the technology, however, it does not mean it is dead – Silverlight is still present in the desktop IE10 browser (as is Flash). Recently Silverlight has been re-positioned as the technology of choice for more complex line-of-business applications, the types of application which sit better in the Windows 8 ‘classic’ desktop. Furthermore, whilst the Metro UI is leading the push into tablet computing, I doubt it will take off on the desktop. So, no, Silverlight is not dead, but it has unfortunately missed out on being part of the Metro UI for tablets.

There is a relatively simple migration path for Silverlight and Windows Phone 7 applications to the new Metro WinRT. This might work for full-screen Silverlight applications, but will not work for applications that mix HTML and Silverlight content within a browser.

Is WPF Dead? – Again, for much the same reasons as Silerlight the answer is “no”. WPF is a framework intended for line-of-business applications, and those belong on the Windows 8 desktop.

How does this impact Windows Phone 7? – it doesn’t. The next version of WP7 is going RTM shortly and there has been no change to these plans. In fact for WP7 developers Windows 8 is a great opportunity. The WinRT seems most closely related to Silverlight for WP7, so your skills and code are readily portable to the tablet.

Should I write my app as a desktop or Metro app? – this is probably the single hardest question that the Windows 8 preview has raised. As application developers we now have two very different ways which we can deliver applications to the desktop and tablet, either the new Metro UI, powered by the (deliberately) limited WinRT; or desktop applications using WPF or Silverlight. I think it will be very interesting to see how Microsoft tackles this problem with its own applications. So far the Windows 8 preview has Metro UI based Twitter, Weather and Social Networking applications and a desktop based Visual Studio. There is also IE which is available in both desktop and Metro, albeit with quite different functionality. Where will Outlook, Word, Excel sit in the new Windows 8?

I think there are rather a lot of applications that will want to make use of both Metro and desktop UIs. Take Outlook for example, you could imagine a simplified Metro interface sitting on one of your monitors, but a more feature rich desktop version available on the other.

One other point worth considering is ‘reach’. It will take a long time before everyone is running a Windows 8 PC, so if you choose to deliver your application as a Metro app, you are restricting yourself just to the Windows 8 user-base. However, if you are targeting the Windows tablet, you can of course guarantee that they will run Windows 8.

Conclusions

Windows 8 presents a significant change in the way we develop Windows applications. The split personality of the Windows 8 user interface and architecture is going to cause confusion on many levels.

The technical implications of WinRT and how it relates to .NET are slowly starting to become clear, thanks to great blog posts like “WinRT Demystified”.

Personally what I think will take a little bit longer to understand is how we design applications for Windows 8, as we start to discover what works well in Metro, what should remain on the desktop and what we deliver to both.

Regards, Colin E.

Earlier this week I presented a talk to the Silverlight UK User Group on cross-platform application development with WPF, Silverlight and Windows Phone 7.

Thanks to Gergley Orosz for these pictures

Thanks to all who attended my talk. Here is a copy of the presentation I gave:

You can see the Windows Phone 7 XAML Finance application which I demonstrated in the following video:

The Silverlight version is also available online.

Finally, the sourcecode for the simple cross-platform Twitter application I demonstrated is available to download: CrossPlatformDemo.zip

Regards, Colin E.

Both WPF and Silverlight have a property TextTrimming=”WordEllipsis”, which trims the text that a TextBlock displays based on the available width. This blog post describes a simple method for automatically showing the full text as a tooltip whenever the text is trimmed. This is presented as an attached behaviour and works in both WPF and Silverlight

A few weeks ago I blogged about a Silverlight solution for automatically adding tooltips when a TextBlock Text is trimmed and renders an ellipsis. I found a decent looking WPF solutions on the web and linked it in my article, however, based on the comments to my previous blog post, it looks like the WPF solution didn’t work too well, failing to respect font size etc… In this blog post I have updated my solution to be cross-platform, working on WPF and Silverlight.

To briefly recap, my solution for automatically adding tooltips to trimmed text relies on the slightly odd behaviour of the TextBlock where its ActualWidth is reported as the width of the text without trimming:

In order to determine whether to show a tooltip, all you have to do is compare the ActualWidth of the TextBlock to the ActualWidth of its parent.

However, the WPF TextBlock does not have this same quirky behaviour, so a completely different approach is required. The other solutions I have seen involve using the low-level WPF drawing APIs to compute the size of the rendered text, however, there is a simpler solution to this problem …

UPDATE: I originally wrote about a method of finding the overall text width from various internal fields within the TextBlock via reflection, as shown below. However, a kind reader of my blog, Daniel Fihnn, pointed out that there is a simpler solution that does not require any reflection.

Daniel pointed out that the width of the TextBlock without the trimming can be obtained using the Measure method. This method is typically used by panels during layout, the Measure method is invoked with the size made available to the element, calling this method causes the element to update its DesiredSize property. Therefore, if you invoke Measure on a TextBlock which has trimming enabled, giving it an infinite available space, its DesiredSize property will report the width that the text would occupy without trimming.

The ComputeAutoTooltip method of the attached behaviour I described in my previous post is updated to have a completely different WPF implementation:

public class TextBlockUtils
{
  /// <summary>
  /// Gets the value of the AutoTooltipProperty dependency property
  /// </summary>
  public static bool GetAutoTooltip(DependencyObject obj)
  {
    return (bool)obj.GetValue(AutoTooltipProperty);
  }
 
  /// <summary>
  /// Sets the value of the AutoTooltipProperty dependency property
  /// </summary>
  public static void SetAutoTooltip(DependencyObject obj, bool value)
  {
    obj.SetValue(AutoTooltipProperty, value);
  }
 
  /// <summary>
  /// Identified the attached AutoTooltip property. When true, this will set the TextBlock TextTrimming
  /// property to WordEllipsis, and display a tooltip with the full text whenever the text is trimmed.
  /// </summary>
  public static readonly DependencyProperty AutoTooltipProperty = DependencyProperty.RegisterAttached("AutoTooltip",
          typeof(bool), typeof(TextBlockUtils), new PropertyMetadata(false, OnAutoTooltipPropertyChanged));
 
  private static void OnAutoTooltipPropertyChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
  {
    TextBlock textBlock = d as TextBlock;
    if (textBlock == null)
      return;
 
    if (e.NewValue.Equals(true))
    {
      textBlock.TextTrimming = TextTrimming.WordEllipsis;
      ComputeAutoTooltip(textBlock);
      textBlock.SizeChanged += TextBlock_SizeChanged;
    }
    else
    {
      textBlock.SizeChanged -= TextBlock_SizeChanged;
    }
  }
 
  private static void TextBlock_SizeChanged(object sender, SizeChangedEventArgs e)
  {
    TextBlock textBlock = sender as TextBlock;
    ComputeAutoTooltip(textBlock);
  }
 
  /// <summary>
  /// Assigns the ToolTip for the given TextBlock based on whether the text is trimmed
  /// </summary>
  private static void ComputeAutoTooltip(TextBlock textBlock)
  {
#if WPF
    textBlock.Measure(new Size(Double.PositiveInfinity, Double.PositiveInfinity));
    var width = textBlock.DesiredSize.Width;
 
    if (textBlock.ActualWidth < width)
    {
      ToolTipService.SetToolTip(textBlock, textBlock.Text);
    }
    else
    {
      ToolTipService.SetToolTip(textBlock, null);
    }
 
#else
    FrameworkElement parentElement = VisualTreeHelper.GetParent(textBlock) as FrameworkElement;
    if (parentElement != null)
    {
      if (textBlock.ActualWidth > parentElement.ActualWidth)
      {
        ToolTipService.SetToolTip(textBlock, textBlock.Text);
      }
      else
      {
        ToolTipService.SetToolTip(textBlock, null);
      }
    }
#endif 
  }
}

This code now works in both a WPF and a Silverlight context. Here’s a screenshot of it working in WPF:

You can download the full sourcecode, including the WPF and Silverlight demo: AutoTooltipTextBlock.zip

Thanks to Daniel Fihnn for a much improved WPF version of this code!

Regards, Colin E.

This blog post looks at the fallout after last week’s PDC conference where Microsoft were quoted as saying “our strategy on Silverlight has shifted”, and the resulting fallout in the developer community. In this post I will describe why I think Silverlight has a future ahead of it and exactly where that future lies.

Bob Puts His Foot In It!

Last week’s Microsoft Professional Developer Conference (PDC) has caused quite a stir. It was clear from Steve Ballmer’s keynote speech that HTML5 was taking centre stage, with Silverlight not getting a single mention in his opening speech.

The image below shows a word cloud showing the most frequent words in Steve Ballmer’s PDC keynote speech, rendered using Wordle

This is in contrast to previous events such as MIX9 where (just over a year ago) Silverlight 3 took centre stage. This focus on HTML5, which many see as a competing technology to Silverlight was enough to get the community a little worried, however, it was the interview that Bob Muglia gave to ZDNet that really caused a storm.

The key quotes are given below:

“[...] when it comes to touting Silverlight as Microsoft’s vehicle for delivering a cross-platform runtime, our strategy has shifted.”

“But HTML is the only true cross platform solution for everything, including (Apple’s) iOS platform”

The above statements caused quite a stir, with calls for Bob to clarify his statements which seemed to contradict the recent “Future of Silverlight” blog post which contrasted the difference between standardisation (HTML5) and innovation (Silverlight) to show a very positive future for the technology. I think this is the first time I had seen such a direct comparison of HTML5 vs. Silverlight from Microsoft’s Silverlight team, and the arguments they made were quite compelling.

Bob Pulls His Foot Out Again

As a result of Bob’s interview, which was commented upon by virtually everyone in the Silverlight community (Jeremy Likeness, Mike Taulty, and many many more), Bob quickly followed up with a blog post where he stated the following:

“I said, ‘Our Silverlight strategy and focus going forward has shifted.’ This isn’t a negative statement, but rather, it’s a comment on how the industry has changed and how we’re adapting our Silverlight strategy to take advantage of that”

However, I think that the most important point he made came at the very end of his post:

“The purpose of Silverlight has never been to replace HTML, but rather to do the things that HTML (and other technologies) can’t, and to do so in a way that’s easy for developers to use.”

I think it is people’s misunderstanding of the differences between Silverlight and HTML that caused most of this uproar in the first place. It is this point which I would like to concentrate on, and hopefully provide a bit more clarity.

PDC is an Event

Before I focus on the differences between HTML and Silverlight I think it is worth noting that PDC is an event, and just like any other event it needs to be marketed in order to fuel people’s interest and get them through the door. Microsoft embraces a very wide range of technologies, and if the PDC tried to be a true reflection of this diversity it would be very fragmented and hard to market. It is much better that the event focuses on something new and interesting to provide an underlying theme. This year that theme was HTML5.

Interestingly after MIX9 where Silverlight was the main focus and out-of-browser support was announced, there was noticeable unrest amongst the WPF community, they felt short-changed (4 MIX sessions on WPF to Silverlight’s 31) and there was speculation that Silverlight would replace WPF entirely. However, when the knee-jerk reactions were forgotten about and a more sensible analysis of the difference between the two was considered (see Pete Brown’s Future of Client App Development blog post for example), it was clear that WPF does have a future.

The Web Landscape

Back to HTML and Silverlight, if we look at the current landscape of the internet we can crudely characterise web sites and web based applications based on the degree of interactivity that provide:

In the above diagram we see a sliding scale of interactivity and complexity with a few well known sites positioned along this scale (don’t ask me about what units I am using to measure each site!).

With the above sliding scale we can position the popular internet technologies based on their relative strengths and the types of site they are most suited to:

I have not tried to pin each technology to a specific location on the scale because in my opinion the boundaries between each are blurred … a lot. It is possible to use any of the above technologies to create a web site / web application at either end of the spectrum, however, the further away you move from the ‘comfort zone’ of each technology, the harder the job becomes.

We’ll start at the Flash / Silverlight end of the spectrum. Why not capitalise on the fact that these plugin technologies provide a controlled environment for your code to run in, providing great performance and virtually zero browser compatibility issues?

Whilst this point may not have been addressed in great detail for Silverlight, there are certainly numerous strong arguments presented on the internet which describe quite clearly why full-page Flash sites will never fully replace HTML (For a thorough analysis take a look at Emil Stenström’s blog post on Flash vs. Ajax sites). The main reasons cited are:

• Splash screens – Flash / Silverlight sites need to load the entire ‘executable’ before they can render. Contrast this with how quickly the pages from Wikipedia appear.
• Maintenance – Quick fixes are often required for websites, with HTML / JavaScript this can often be left to the support team. For Silverlight / Flash this requires a full rebuild of the application.

(There are a number of other points, including search engine indexing, etc …)

There is not a strong case for replacing simpler web sites with Silverlight. I think my fellow WPF Disciple Justin Angel’s blog, which is powered entirely with Silverlight is unfortunately a good illustration of why Silverlight should not be used to replace HTML for the presentation of largely static content. Sitting here on a train using the pitiful WiFi connection I can see Justin’s stylish loading ‘splash screen’, however, after I minute of waiting I grow tired of staring at his beard and sunglasses and little else!

On the flip-side, when HTML and JavaScript technologies are used to create complex applications, development becomes costly and complex. Cross-browser problems, lack of support for business concepts such as controls and validation, performance issues all start to have a significant impact on the development. To combat this more and more sophisticated solutions are being applied, from the numerous libraries that abstract the differences in browser DOM APIs (jQuery etc…) to Google Web Toolkit, which generates JavaScript code from Java (which provides strong typing and better structuring).

Interestingly in the book Google Closure the Definitive Guide, the preface describes how Google Closure (a JavaScript compiler and mechanism for checking types) was developed to combat the problems the Google Mail development team were experiencing in developing a complex JavaScript application composed of tens of thousands of lines of JavaScript. The take-home message of this is that for complex applications you need more than the JavaScript language alone provides.

Bob’s Comments in Perspective

In the previous section I described how the web landscape can be illustrated as a sliding scale of complexity, with HTML and Silverlight at opposite ends of the spectrum and HTML5 sitting somewhere in-between. With this in mind, Silverlight developers should not fear that HTML5 will replace Silverlight. Whilst it is true that there is some common ground between the two, i.e. a certain interactivity / web-site complexity where the two technologies are equally suited, Silverlight users should feel comfortable that for the more complex problems, Silverlight has a clear advantage.

To repeat Bob’s closing statement of his follow-up blog post:

“The purpose of Silverlight has never been to replace HTML, but rather to do the things that HTML (and other technologies) can’t, and to do so in a way that’s easy for developers to use.”

I think it is the failure of the developer community to realise that there is little direct competition between HTML5 and Silverlight and failure of Microsoft’s marketing to highlight this.

The Web Increases its Reach.

However, there are some important points to note in Bob’s comments and his reference to iOS (i.e. iPhone, iPad etc…). Whilst I do not think HTML5 is a significant threat to Silverlight for web based application development, the introduction of a more diverse range of mobile devices potentially increase the market for HTML.

Most people who use an Android phone or an iPad do not use them as a replacement for their laptop or desktop PC. They use them on the train, in the coffee shop and at home on the sofa as a way to stay online and connected for more of their waking hours. HTML5 is a suitable technology for delivering a interactivity to a diverse range of devices and it looks like the overall market size is increasing.

However, if Microsoft can produce Silverlight plugins for these devices, on the Android phone for example, there is no reason why Silverlight cannot be part of this growing market, delivering more than just interactivity to the mobile platform.

Unfortunately, more recent news, like today’s announcement by the Bing Maps team that seems to indicates they will be dropping their Silverlight based 3D libraries in favour of HTML5 is going to fuel the fire which Bob and Steve Ballmer are currently trying to dowse.

Regards, Colin E.

Last week I gave a presentation at a joint Scott Logic / Microsoft event about how WPF and Silverlight are unifying the development platform for desktop, web and mobile. To accompany the talk I wrote a white paper which delves into this subject in a little more detail.

You can download the whitepaper here: WPF and Silverlight Cross Platform Development White Paper (PDF, 1.8 MBytes)

Or view it online in the PDF viewer below:

I also created a cross platform application that has a 75% shared codebase between the WPF (desktop), Silverlight (web) and Windows Phone 7 (mobile) versions. I plan to share more of this at a later date.

Any thoughts, ideas or comments, please share them below.

Regards,
Colin E.

This post compares the implementation of a simple ListBox layout with Windows Forms and Windows Presentation Foundation. The use of Templates within WPF are a clear winner over the WinForms ‘owner draw’ route.

Application user interfaces are becoming much more graphical, with users expecting a more engaging and ‘lively’ experience. However, rich graphical UIs can do much more for the user than just provide an experience that looks and feels good. Graphics can be used to more effectively convey the options available to the user. For example, which of these line weight selectors would assist best in helping a a user determine a suitable selection …

I think most users would prefer the second option where they can visualise a range of line weights and actually see how they look (after all, how many users know what a ‘pt’ actually is?) before making a selection. However, for a Windows Forms developer, the first option, a simple text box with the label ‘pt’ next to it, is trivial to implement, whereas the second is not.

Applications such as Word 2007 present as many of the user options as possible in a visual style, for example, the font selector in previous versions of Word simply presented a list of font names, whereas in Word 2007 each font is rendered as it would appear to the user. Furthermore, the font selector combo-box is grouped to include recently used fonts:

Unfortunately for the developer, creating visual UIs can be quite challenging.

Windows Forms has been the technology of choice for the creation of business desktop applications for a number of years. The developer is presented with a large number of standard controls with which they can build their application, however these controls lack the flexibility required to create a more visual interface. For example, combo-boxes and list-boxes are designed to render text content, not mixed font text with icons, or lines of varying weight as seen in our above examples. To create a control that renders non-standard content, the only route available to the developer is ‘owner draw’ where the developer handles events in order to render all or part of the control. This is a time consuming and highly iterative process, with the developer having to compile and run their code repeatedly to see the results of their graphics code.

One of the key differences between Windows Forms and WPF is the way in which the visual representation of controls and their content is encoded. WPF has the concept of templates, an XML (or more accurately XAML) representation of how a control is rendered to the screen. This is what allows WPF developers / designers to create funky looking round buttons and other impressive UI fluff! However, probably of more interest to developers of business applications are data templates, which detail how data is represented on the screen.

Controls such as list-boxes and combo-boxes are used to represent, and provide selection from, a list of data objects. With the WPF framework, the way in which this data is represented is specified by a DataTemplate. We’ll take a look at how this differs from the WinForms owner-draw route by rendering the same content with each technology.

There are quite a few articles available on the internet which describe how to create an owner draw listbox. I took the sourcecode from an article on codeproject by GiedriusBan, his article describes how to owner-draw a listbox to add some more complex content into each item:

Because the listbox is being used to render more than just text, the only viable solution is to ‘owner draw’ each listbox item, this is done by handling an event provided by the listbox and the following GDI graphics code:

public void drawItem(DrawItemEventArgs e, Padding margin, 
                        Font titleFont, Font detailsFont, StringFormat aligment, 
                        Size imageSize)
{
    bool isHighlighted = (e.State & DrawItemState.Selected) == DrawItemState.Selected;
 
    // if selected, mark the background differently
    e.Graphics.FillRectangle(isHighlighted ? Brushes.DarkBlue : Brushes.White, e.Bounds);
 
 
    // draw some item separator
    e.Graphics.DrawLine(Pens.DarkGray, e.Bounds.X, e.Bounds.Y,
                               e.Bounds.X + e.Bounds.Width, e.Bounds.Y);
 
    // draw item image
    e.Graphics.DrawImage(this.ItemImage, e.Bounds.X + margin.Left,
                                  e.Bounds.Y + margin.Top, imageSize.Width, imageSize.Height);
 
    // draw a border around the image
    e.Graphics.DrawRectangle(Pens.DarkGray, e.Bounds.X + margin.Left, e.Bounds.Y + margin.Top,
                                       imageSize.Width, imageSize.Height);
 
    // calculate bounds for title text drawing
    Rectangle titleBounds = new Rectangle(e.Bounds.X + margin.Horizontal + imageSize.Width,
                  e.Bounds.Y + margin.Top,
                  e.Bounds.Width - margin.Right - imageSize.Width - margin.Horizontal,
                  (int)titleFont.GetHeight() + 2);
 
    // calculate bounds for details text drawing
    Rectangle detailBounds = new Rectangle(e.Bounds.X + margin.Horizontal + imageSize.Width,
                    e.Bounds.Y + (int)titleFont.GetHeight() + 2 + margin.Vertical + margin.Top,
                    e.Bounds.Width - margin.Right - imageSize.Width - margin.Horizontal,
                    e.Bounds.Height - margin.Bottom - (int)titleFont.GetHeight() - 2 - margin.Vertical - margin.Top);
 
    // draw the text within the bounds
    var brush = isHighlighted ? Brushes.White : Brushes.Black;
    e.Graphics.DrawString(this.Title, titleFont, brush, titleBounds, aligment);
    e.Graphics.DrawString(this.Details, detailsFont, brush, detailBounds, aligment);            
 
    // put some focus rectangle
    e.DrawFocusRectangle();
 
}

This is a lot of ‘heavy’ and hard to follow graphics code to achieve such a simple listbox item layout!

With WPF the listbox uses a template to render the data within the list. Here is the same list rendered with a WPF application:

And here is the XAML code to create this layout:

<ListBox Margin="5" ItemsSource="{Binding}"
            ItemContainerStyle="{StaticResource StretchedContainerStyle}">
    <ListBox.ItemTemplate>
        <DataTemplate>
            <Grid HorizontalAlignment="Stretch">
                <Grid Margin="5">
                    <Grid.ColumnDefinitions>
                        <ColumnDefinition Width="Auto"/>
                        <ColumnDefinition/>
                    </Grid.ColumnDefinitions>
                    <Grid.RowDefinitions>
                        <RowDefinition Height="Auto"/>
                        <RowDefinition/>
                    </Grid.RowDefinitions>
 
                    <Border  Grid.RowSpan="2"
                                BorderBrush="LightGray" BorderThickness="1"
                                Margin="0,0,5,0">
                        <Image Source="{Binding Image}"/>
                    </Border>
                    <TextBlock Text="{Binding Name}"
                                FontWeight="Bold"
                                Grid.Column="2"
                                Margin="0,0,0,5"/>
                    <TextBlock Text="{Binding Details}"
                                Grid.Column="2" Grid.Row="2"/>
                </Grid>
                <Line X1="0" Y1="0" X2="1" Y2="0" Stretch="Uniform"
                        Stroke="DarkGray"
                        VerticalAlignment="Bottom"/>
            </Grid>
        </DataTemplate>
    </ListBox.ItemTemplate>
</ListBox>

Comparing the two approaches; not only is there less code in the WPF version, it is also much clearer and easy to follow. However, the advantages of the WPF approach do not end there …

WPF uses a retained graphics mode, which means the various elements in the above XAML code are assembled into a visual tree that is retained in memory, rather than just being painted to some bitmap. This means that the developer does not have to worry about invalidation, and does not need to employ techniques to avoid flicker when re-drawing.

The original author of the WinForms code above subclassed ListBox and created a concrete control for rendering this specific data with this specific layout. With WPF there is no subclassing, and no need to create a specific ListBoxItem for each row to provide the data for the control, instead the list binds directly to the business objects, with the DataTemplate doing all the work.

Finally, you can supply design time data to your WPF / Silverlight applications, allowing you to get immediate feedback when designing your templates, removing the time consuming build / execution cycle required with WinForms. The screenshot below shows how the listbox looks in visual studio:

And here is the design time data:

<PersonCollection xmlns="clr-namespace:TemplatedListBox">
    <Person Name="John, the Tester"
            Details="First details text is used to check it out"
            Image="image1.jpg"/>
    <Person Name="John, the Tester"
                Details="First details text is used to check it out"
                Image="image2.jpg"/>
</PersonCollection>

In conclusion, templates are a very powerful features of the WPF (and Silverlight) framework that provide far more that just a mechanism for creating round buttons! If we look at the font selector used in Word 2007, I can imagine creating this UI with WPF in a matter of hours, whereas with WinForms it would take days. That is why I love WPF!

You can download the WPF and WinForms source for this article: WPFLove.zip

Regards, Colin E.

This blog post describes an update to the Silverlight 4 MultiBinding technique I blogged about a couple of months ago to add support for ElementName binding and TwoWay binding.

A few months ago I posted an update to my MultiBinding solution for Silverlight 4. This technique allows you to perform the same kind of multibindings which are possible in WPF, where a property value is bound to multiple sources via a special value converter that implements the IMultiValueConverter interface, which describes how these values are combined. This update proved popular once again, and I received a few requests to add support for ElementName and TwoWay binding. I like challenge! This blog post describes how these two features were implemented, but if you just want to grab the code, you will find the link at the end of this article.

A brief recap

Before I go into the implementation details for the new features I will provide a brief recap of how my multibinding solution works. The XAML for creating a multibinding looks like the following:

<TextBlock Foreground="White" 
  <local:BindingUtil.MultiBindings>
    <local:MultiBindings>
      <local:MultiBinding TargetProperty="Text"
                          Converter="{StaticResource TitleConverter}">
        <local:BindingCollection>
          <Binding Path="Surname"/>
          <Binding Path="Forename"/>
        </local:BindingCollection>
      </local:MultiBinding>
      <local:MultiBinding TargetProperty="ToolTipService.ToolTip"
                          Converter="{StaticResource TitleConverter}">
        <local:BindingCollection>
          <Binding Path="Surname"/>
          <Binding Path="Forename"/>
        </local:BindingCollection>
      </local:MultiBinding>
    </local:MultiBindings>
  </local:BindingUtil.MultiBindings>
</TextBlock>

Here the Text property and attached ToolTip property of the TextBlock are bound to both the Surname and Forename property of the business object which is set as the DataContext of our view.

The value converter is as follows:

public class TitleConverter : IMultiValueConverter
{
 
  public object Convert(object[] values, Type targetType,
    object parameter, CultureInfo culture)
  {
    string forename = values[0] as string;
    string surname = values[1] as string;
 
    return string.Format("{0}, {1}", surname, forename);
  }
 
  ...
}

In the example below you can see that as you change the forename or surname, the title text and tooltip are updated by the multibinding.

So how does this work?

When a multibinding is created and added to an element via the BindingUtil.MultiBindings attached property, the MultiBinding instance is added to a virtual-branch, this is a branch of the visual tree that obtains the DataContext of the element to which it is bound, but is not added to the visual tree itself. The MultiBinding then creates a BindingSlave instance for each of the given Bindings. These ‘slave’ elements inherit the MultiBinding DataContext and are used to evaluate each of the individual Bindings. The MultiBinding instance aggregate the results of each binding with the IMultiValueConverter used to compute the ConvertedValue property which is bound to the target property on the element to which this MultiBinding as attached.

ElementName binding

So why does the above solution not work if one of the multibindings uses ElementName to locate the source rather than using the inherited DataContext? The problem here is that the MultiBinding and its BindingSlave instances are located in a virtual branch and are therefore not in the same namescope as the target element. As a result, they cannot perform look up of named elements.

In order to solve this problem I created a BindingSlave subclass specifically for ElementName binding. This slave locates the source element named via the ElementName property and sets it as the Source of the binding it uses to compute its Value property.

The only minor complication I encountered is that the MultiBinding might be constructed before the element referenced via ElementName. For this reason the binding slave must handle LayoutUpdated events to ensure that the named element is located if it is constructed after the multibinding.

public class ElementNameBindingSlave : BindingSlave
{
  private FrameworkElement _multiBindingTarget;
 
  /// <summary>
  /// The source element named in the ElementName binding
  /// </summary>
  private FrameworkElement _elementNameSource;
 
  private Binding _binding;
 
  public ElementNameBindingSlave(FrameworkElement target, Binding binding)
  {
    _multiBindingTarget = target;
    _binding = binding;
 
    // try to locate the named element
    ResolveElementNameBinding();
 
    _multiBindingTarget.LayoutUpdated += MultiBindingTarget_LayoutUpdated;
  }
 
  /// <summary>
  /// Try to locate the named element. If the element can be located, create the required
  /// binding.
  /// </summary>
  private void ResolveElementNameBinding()
  {
    _elementNameSource = _multiBindingTarget.FindName(_binding.ElementName) as FrameworkElement;
    if (_elementNameSource != null)
    {
      SetBinding(BindingSlave.ValueProperty, new Binding()
      {
        Source = _elementNameSource,
        Path = _binding.Path,
        Converter = _binding.Converter,
        ConverterParameter = _binding.ConverterParameter
      });
    }
  }
 
  private void MultiBindingTarget_LayoutUpdated(object sender, EventArgs e)
  {
    // try to locate the named element 
    ResolveElementNameBinding();
  }
}

The example below demonstrates element name binding by binding the Value of two Slider elements to a TextBlock which displays the sum of the two values.

<TextBlock Grid.Column="1">
  <local:BindingUtil.MultiBindings>
    <local:MultiBindings>
      <local:MultiBinding TargetProperty="Text"
                          Converter="{StaticResource SliderValueConverter}">
        <local:BindingCollection>
          <Binding ElementName="sliderOne" Path="Value"/>
          <Binding ElementName="sliderTwo" Path="Value"/>
        </local:BindingCollection>
      </local:MultiBinding>
    </local:MultiBindings>
  </local:BindingUtil.MultiBindings>
</TextBlock>
 
<Slider x:Name="sliderOne" Value="10"/>
 
<Slider x:Name="sliderTwo"  Value="20"/>

Here is the value converter that is used to compute the sum:

public class SliderValueConverter : IMultiValueConverter
{
 
  public object Convert(object[] values, Type targetType, object parameter, System.Globalization.CultureInfo culture)
  {
    if (values.Length != 2 ||
        values[0] == null ||
        values[1] == null)
      return null;
 
    return (double)values[0] + (double)values[1];
  }
 
  ...
}

You could of course use element name binding to combine the surname / forename in the first example in this blog post, but in this context it is more likely that you will want to back your UI with a business object. It is also possible to mix element name and regular (i.e. Source=DataContext) binding.

I find multibindings which use ElementName references most useful when creating complex UI layouts that do not lend themselves to being implemented using Panels. For a good example see my article on the implementation of a BulletGraph control which makes extensive use of this technique in order that the layout of the control is performed entirely within XAML.

TwoWay Binding

A two-way multibinding must be able to handle updates to the combined value and split it up into its constituent parts in order to update the multiple source bindings. In the first example where a forename and surname property are combined into a “surname, forename” string it is possible to convert back the other way, but in the example above where the values of two Sliders are combined a reverse conversion is not possible.

Modifying this multibinding solution to permit two way binding was relatively straightforward. A property changed event handler was added to the MultiBindig.ConverterValue (which is bound to the multi binding target) so that we can determine when changes have been made. This handler then uses the IMultiValueConverter to convert the value into the multiple source properties and updates the binding slaves accordingly:

/// <summary>
/// Handles property changes for the ConvertedValue property
/// </summary>
private void OnConvertedValuePropertyChanged()
{
    OnPropertyChanged("ConvertedValue");
 
    // if the value is being updated, but not due to one of the multibindings
    // then the target property has changed.
    if (!_updatingConvertedValue)
    {
      // convert back
      object[] convertedValues = Converter.ConvertBack(ConvertedValue, null,
          ConverterParameter, CultureInfo.InvariantCulture);
 
      // update all the binding slaves
      if (Children.Count == convertedValues.Length)
      {
        for (int index = 0; index < convertedValues.Length; index++)
        {
          ((BindingSlave)Children[index]).Value = convertedValues[index];
        }
      }
    }
}

In order to use two way multibinding both the multibinding mode and the bindings within the BindingCollection must be set to TwoWay. See the example given below:

<TextBlock Text="Surname:"/>
<TextBox  Grid.Column="1" Text="{Binding Path=Surname, Mode=TwoWay}"/>
 
<TextBlock Grid.Row="1" Text="Forename:"/>
<TextBox Grid.Row="1"  Grid.Column="1" Text="{Binding Path=Forename, Mode=TwoWay}"/>
 
<TextBlock Grid.Row="2" Text="Combined:"/>
<TextBox Grid.Row="2"  Grid.Column="1" >
  <local:BindingUtil.MultiBindings>
    <local:MultiBindings>
      <local:MultiBinding TargetProperty="Text"
                        Converter="{StaticResource TitleConverter}"
                        Mode="TwoWay">
        <local:BindingCollection>
          <Binding Path="Surname" Mode="TwoWay"/>
          <Binding Path="Forename" Mode="TwoWay"/>
        </local:BindingCollection>
      </local:MultiBinding>
    </local:MultiBindings>
  </local:BindingUtil.MultiBindings>
</TextBox>

You can have try of two way multibinding below where the values of the forename and surname text boxes are combined in the box below. However, you ca also make updates to the combined result which will then be converted back into its constituent parts:

And here is the value converter:

public class TitleConverter : IMultiValueConverter
{
  #region IMultiValueConverter Members
 
  public object Convert(object[] values, Type targetType,
    object parameter, System.Globalization.CultureInfo culture)
  {
    string forename = values[0] as string;
    string surname = values[1] as string;
 
    return string.Format("{0}, {1}", surname, forename);
  }
 
  public object[] ConvertBack(object value, Type[] targetTypes,
    object parameter, System.Globalization.CultureInfo culture)
  {
    string source = value as string;
    var pos = source.IndexOf(", ");
 
    string forename = source.Substring(pos + 2);
    string surname = source.Substring(0, pos);
 
    return new object[] { forename, surname };
  }
 
  #endregion
}

So, there you have it, two-way and element name multibinding

You can download the full source, including a WPF build (thanks to Stefan Olson) here: SLMultiBinding.zip

Now … go forth and multibind.

Regards, Colin E.

This post provides a simple IValueConverter implementation that makes use of the framework type converters in order to convert between a large range of source / target types. This converter can be used both within bindings and in code-behind to give more concise property setters.

Introduction

One of the great features of the XAML language is that it is flexible, concise and expressive (yes, I know that XML can be a little verbose, but if you try to create a complex UI purely in code-behind I think you will agree with my observations!). For example, you can set the fill of a rectangle by simply specifying the named color:

<Rectangle Fill="Green"/)

or … you can specify the RGB values directly:

<Rectangle Fill="#00FF00"/)

Looking at the above examples, you might be fooled into thinking that the Fill property is of type Color. People who are new to WPF often find that this is not the case the first time they try to bind a property of type Color to the Fill property (they would never set the Fill property directly in code behind, because that would be a cardinal sin!). The Fill property is actually of type Brush, and the XAML parser is performing some cunning type conversions in order to make the above markup work.

The solution to this problem of binding a Color to the Fill property is to create a value converter:

public class ColorToBrushConverter : IValueConverter
{
  public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
  {
    if (value is Color)
    {
      return new SolidColorBrush((Color)value);
    }
    return null;
  }
 
  public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
  {
    throw new Exception("The method or operation is not implemented.");
  }
}

Which can be used as follows:

<Rectangle Fill="{Binding Path=MyColorProperty,
                                  Converter={StaticResource ColorToBrushConverter}} "/)

If you search google for ColorToBrushConverter, you can see that there are a great many people who have implemented this simple little converter. But what happens if you want to bind to a string representation of color? or you want to bind to a stroke dash property or path geometry? Whilst value converters are simple to implement, it is a shame that you have to create so many of them!

A Universal Value Converter

Wouldn’t it be great to have a single value converter that has the same flexibility as the XAML parser? It is actually very simple to create such as converter (and after creating probably my 5th ColorToBrushConverter I have no idea why it took so long before I realised this!). The .NET framework has had an API for conversion between different types via TypeConverters for a long time. They used extensively in .NET technologies for databinding and designer support, and much more.

A value converter can obtain a suitable TypeConverter for the target property then perform the required conversion:

public class UniversalValueConverter : IValueConverter
{
    public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
    {
        // obtain the conveter for the target type
        TypeConverter converter = TypeDescriptor.GetConverter(targetType);
 
        try
        {
            // determine if the supplied value is of a suitable type
            if (converter.CanConvertFrom(value.GetType()))
            {
                // return the converted value
                return converter.ConvertFrom(value);
            }
            else
            {
                // try to convert from the string representation
                return converter.ConvertFrom(value.ToString());
            }
        }
        catch (Exception)
        {
            return value;
        }
 
    }
 
    public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
    {
        throw new NotImplementedException();
    }
}

Note, that this value converter first tries to convert directly from the source to the target type, if this is not possible it then tried to convert via a string representation (I am not sure whether it is more correct to obtain a TypeConverter for the String type, then use this rather that invoking ToString on the value being converted, but the above works for me ).

You can see this converter in action below where a range of type conversions are demonstrated:

<TextBlock Text="Converting String to Brush ...."/>
<Rectangle Fill="{Binding ElementName=colorTextBox, Path=Text, Converter={StaticResource UniversalValueConverter}}"/>
<TextBox x:Name="colorTextBox"
             Text="Red"/>
 
<TextBlock Text="Converting String to Geometry ...."/>
<Path Data="{Binding ElementName=geometryText, Path=Text, Converter={StaticResource UniversalValueConverter}}"/>
<TextBox x:Name="geometryText"                  
             Text="M 10,20 C 10,2.5 40,35 40,17 H 28"/>
 
<TextBlock Text="Converting String to DoubleCollection (stroke dash) ...."/>
<Line StrokeDashArray="{Binding ElementName=dashText, Path=Text, Converter={StaticResource UniversalValueConverter}}"/>
<TextBox x:Name="dashText"                  
            Text="2 2 4 5"/>

For the first conversion, string to brush, you can use named colors, and the hex notation in its range of abbreviated forms (#AF7, #AAFF77, #FFAAFF77 …). You can also use this converter to convert from string to their corresponding enum values, for example binding the string “Collapsed” to the Visbility property.

Value conversion in code behind

The above converter really is swiss army knife for bindings, but what about code-behind? You are still constrained by the type requirements of the property being set:

rect1.Fill = new SolidColorBrush()
{
    Color = Colors.Red
};

Value converters, whilst typically used in binding, can also be used directly in code-behind. The following extension method extends SetValue method for setting dependency properties to make use of the above value converter:

/// <summary>
/// Sets the given dependency property, applying type conversion where required
/// </summary>
public static void SetValueEx(this DependencyObject element, DependencyProperty property, object value)
{
    var conv = new UniversalValueConverter();
    var convertedValue = conv.Convert(value, property.PropertyType, null, CultureInfo.InvariantCulture);
    element.SetValue(property, convertedValue);
}

Which provides a more flexible mechanism for setting property values:

rect1.SetValueEx(Rectangle.FillProperty, Colors.Red);
rect2.SetValueEx(Rectangle.FillProperty, "Blue");
rect3.SetValueEx(Rectangle.FillProperty, "#FFEE55");
rect4.SetValueEx(Rectangle.FillProperty, new SolidColorBrush(Colors.Orange));

… and Silverlight?

Unfortunately Silverlight lacks the TypeDescriptor class which is used to obtain TypeConveters. I am guessing that type conversion within Silverlight is ‘baked-in’ to the XAML parser, which means that it is not possible to re-use this logic

You can download the full source for this blog post: UniversalValueConverter.zip

Regards,
Colin E.