Andrej Tozon's blog

In the Attic

NAVIGATION - SEARCH

Debugging WinRT/XAML bindings

Visual Studio 2012 may not (yet?) support debugging of XAML bindings debugging in WinRT/Metro-style applications in a way we’re used to from programming WPF and Silverlight (a.k.a. XAML breakpoints), but basic notifications of failed bindings in the output window seems to be present and working.

Let’s look at the basic set up (new blank application).

MainPage.xaml – DataContext is set to the same page class to keep it simple;  TextBlock’s text is bound to a MyBinding property.

<Page
    x:Class="App1.MainPage"
    IsTabStop="false"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="using:App1"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    DataContext="{Binding RelativeSource={RelativeSource Self}}"
    mc:Ignorable="d">
    <Grid Background="{StaticResource ApplicationPageBackgroundThemeBrush}">
        <TextBlock Text="{Binding BindingText}" VerticalAlignment="Center" HorizontalAlignment="Center" />
    </Grid>
</Page>

MainPage.xaml.cs

public sealed partial class MainPage : Page
{
    public MainPage()
    {
        this.InitializeComponent();
    }

    public string BindingText { get { return "OK"; } }
}

BindingText property in the code-behind class that TextBlock is bound to, exposes a fixed string.

Running this project should greet you with the “OK” string  centered on the screen, meaning the binding worked as expected.

Changing the name of the binding property should break the binding.

public string BindText { get { return "OK"; } }

After starting now broken app, we’re greeted with an empty screen and no exceptions thrown. We can, however, observe a subtle notification about thee binding failure in the Output window:

Error: BindingExpression path error: 'BindingText' property not found on 'App1.MainPage'. BindingExpression: Path='BindingText' DataItem='App1.MainPage'; target element is 'Windows.UI.Xaml.Controls.TextBlock' (Name='null'); target property is 'Text' (type 'String')

Because such notifications are really easy to miss, there’s now a way to subscribe to binding errors notifications right from your WinRT code – Application’s DebugSettings property exposes a BindingFailed event you can subscribe to. This event will be called whenever binding fails (well, not exactly always , but whenever the binding failure message gets written to the Output window, you can be sure it will get called.

You can use this event to make sure that caught binding errors will surely get your attention, by i.e. displaying the exception message all over the place:

sealed partial class App : Application
{
    public App()
    {
        this.InitializeComponent();
        this.Suspending += OnSuspending;
        DebugSettings.BindingFailed += OnDebugSettingsOnBindingFailed;
    }

    private void OnDebugSettingsOnBindingFailed(object sender, BindingFailedEventArgs args)
    {
        new MessageDialog(args.Message).ShowAsync();
    }
    ...
}

image

Unfortunately, the binding failure message text is currently just the only thing you’re provided with in the event handler, but you can still parse it manually and decide whether you want it displayed or not.

Other BindingSettings options enable you to override the above-described behavior – setting IsBindingTrackingEnabled to false (it’s true by default) will disable failed binding notifications: the event will not get called and there will be no trace in the Output window.
Additionally, both kind of notifications only work when the debugger is attached. That means that running the application with Ctrl+F5 (Start Without Debugging) won’t display any notification either.

There is, however, one tiny difference between when notifications are presented – Output window will never write the exception message when running in the Release configuration, while the event will still get called.

To summarize: while we wait for a proper XAML debugging in WinRT, tracking the output window is the default option to catch binding failures. Subscribing to BindingSettingsBindingFailed event will give you some more flexibility and display visibility, and it also works when running in the Release configuration.



Scraping the rust off of this thing

Has it really been that long?

For a quick recap before I reboot this blog, here's what I have been doing for the past months:

Windows phone development

I did a couple of new Windows Phone 7 apps, published to marketplace and currently working on some more.

Web development

I jumped into MVC development, with a pinch of Azure fun. Can't deny it, it feels great! Web Forms always felt so uncomfortable to me (I loooved classic ASP, BTW), and with MVC, web development feels like fun again.

Windows 8

Was heavily educating myself on Metro design language and principles, as well as practicing Windows 8 Metro-style application development. I have a few apps in the works, some of which should be available by the time Windows 8 launches, others will follow.

Speaking

I talked a lot about Metro design and building Windows 8 Metro-style applications, including having a few sessions on the subject on recent Microsoft's NT Konferenca.

SIUX

Our local UX community started great, we had a couple of really interesting talks. We're continuing right after the summer and if you are or know anyone that would want to share their experience from practicing in the field, contact me and we'll get you on stage. Speakers' efforts are thankfully rewarded. Still working on the web site, though K

What's next?

Well, expect a lot more content on Windows 8 and Windows Phone 7/8 on this blog in the future, and I may just throw in a bit of Web/MVC/other magic every now and then.

 

Oh, and this post was written using Word 2013 Preview. It's nice, but lacking features and friendliness. I'll definitely miss Windows Live Writer if they really are about to put it to sleep.