An Empirical Approach to Data Binding in Universal Windows Applications

Introduction

I was quite excited when I first heard about the new x:Bind. Dumping "magic strings" used in WPF Binding and getting rid of Angela Bennett-ish reading of the output window should make one happy, furthermore, gaining performance enhancements makes it a clear winner. The first letdown comes when I learned that WPF doesn't benefit from this, one must stick with the old Binding. MS probably still wants to kill desktop, but I can't regard UWA as a real desktop program replacement (IMHO, the aging Live Mail is still MUCH better then the new Windows 10 mail client), the main advantage in my eyes is that an app written for phone works on PC as well.

Details

Surprises keep coming while I'm trying to port a Windows 8(.1) app to the new platform. There are a number of password and text boxes that require validation, to offer a visual clue to the user validation should occur on every keypress. That worked just fine for a password:

<PasswordBox PasswordRevealMode="Peek" Password="{x:Bind ViewModel.Password, Mode=TwoWay}" />

but no way for:

<TextBox Text="{x:Bind ViewModel.Name, Mode=TwoWay}" />

property gets updated only on losing focus and there is no UpdateSourceTrigger here. Let's set page DataContext to the ViewModel and switch back to the old way (as I didn't want to bother with keypress events):

<TextBox Text="{Binding ViewModel.Name, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}" />

I don't like it but it seemed to work.

Other binding that worked while debugging:

<PasswordBox ... PasswordRevealMode="{x:Bind ShowPasswordToggle.IsChecked, Converter=...}"/>

When everything is OK in debug, let's see how the native compilation works. At first, I recalled the times when I compiled TurboC projects on a 286 (and getting angry a bit after the n^th recompilation) than I was quickly faced with a suddenly (and randomly) disappearing main window (aaaa.., page, sorry, too many years opening and closing windows not navigating pages). S..t happens, I thought, let's see the native debugging.

My first reward was a very “helpful” exception, and a more elaborate, but equally useless error message I received after disabling the optimizations for the release build.

Exception thrown: 'System.Runtime.InteropServices.InvalidComObjectException' in System.Private.Interop.dll
An unhandled exception of type 
'System.Runtime.InteropServices.InvalidComObjectException' occurred in System.Private.Interop.dll
Additional information: COM object that has been separated from its underlying RCW cannot be used.

With not much help from Bing/Google, I reverted to the oldest debugging method, let's delete chunks of code till it remains alive. I will skip talking about the number of rebuilds, let's jump to the results:

1. Binding using the DataContext of the page leads to sudden death:

   <TextBox Text="{Binding ViewModel.Name, ...

   so, do not set the DataContext, name the page and use:

   <TextBox Text="{Binding ElementName=crtPage, Path=ViewModel.Name, ...

2. If a property of a control is x:Bind-ed to another control as in:

   <PasswordBox ... PasswordRevealMode="{x:Bind ShowPasswordToggle.IsChecked...

   it dies, one must use Binding for this:

   ... PasswordRevealMode="{Binding ElementName=ShowPasswordToggle, Path=IsChecked, ...

These might be logical and explained in some docs, but I didn't have the luck to find those in time. But even if it's my fault not getting these right, I believe it should not work in debug if it won't in release (and vice versa). I tend to add this to an ever growing list of strange (to use a mild term) things from MS.