What Broke My App This Time? The XAML Editor

In one of my base classes, I implement a handler for a particular event.

The idea was that I have have a certain set of things I always want to do in my framework when the bottom appbar opens.

So I took one of the classes, typed Opened=”BottomAppBarOpened” into the xaml editor on the BottomAppBar, and then right clicked and chose Goto Definition.

That opens the code behind and implements the method.

I then cut the method from there, and pasted into the base class, changed it to a protected virtual, and thought “Bob’s my uncle” (he is, actually)

So, that was weeks ago.  Today, I was looking for that code, and clicked Goto Definition.

This time, I got a new private implementation (just like the first time, naturally), that hid the virtual function.

As a result, I’ve now changed my code so each class that has this, implements the method and calls the base class implementation.  It’s a shame the editor can’t see the inherited signatures, and jump to that instead.

It’s the Templates Stupid! (The joys of XAML)

I’ve been trying to solve some usability problems with text being too small to read on a 7 inch tablet for people who are ageing, and tried to increase the font size in my app.

Much to my dismay, that caused RadioButtons and CheckBoxes to align badly.

Eventually I tracked down the alignment problem to the alignment of the button or checkbox always being top in the template, while the content inherited it from the control.

 

I’ve published my updated templates as a Gist.

In addition, on 8.1 you may also want to set the content to be a TextBlock with TextLineBounds=Tight to get the best results.

Most of my Windows 8 apps are broken. Yours probably are too.

Tonight, after a day of user testing an upcoming app, we ran into some crashes, and some undesirable behavior.

So, we set about trying to fix the problems.  So far so good.

One of the problems was the app needed to keep the display from timing out while running.

Enter DisplayRequest and it’s RequestActive and RequestRelease methods.  On a particular page in my app, I called RequestActive during OnNavigatedTo and RequestRelease during OnNavigatedFrom.

Unfortunately, we ran into trouble when we started playing with our suspend/resume handling.  They started throwing ArithmeticExceptions!

So, a quick check of the DisplayRequest Documentation shows some sample code with it catching exceptions.  As a result, I eventually decided to write a wrapper class to handle the outstanding requests, and follow he advice on that page.

• Release all display requests when the app is suspended. If the display is still required to remain on, the app can create a new display request when it is reactivated.

To support this, we called RequestRelease for each time it had been requested active, and in the restore code, we call request active again.  Unfortunately that still didn’t work, as it turned out that OnNavigatedFrom was being called after we’d released everything in the Suspending call.  So, I went looking for trouble.

Usually when you look for trouble you can find it

Turns out, I wasn’t the only one with problems.

This discussion on the Suspension Manager points out the issue of things not being called in matching pairs.

And this advice about Saving and Restoring State in a Windows 8 XAML App shows that you only call SuspensionManager.RestoreAsync() in certain cases.  I expect that’s derived from the advice on this page about Application Lifecycle where they explicitly state “most apps don’t need to do anything when they are resumed”  The advice from Patterns and Practices is similarly broken.

And that combination is the cause of the bug.

Naturally, after 3 hours of research, I now no longer need my global class that manages the count of the number of DisplayRequest.ReleaseRequest and RequestActive calls I’ve made.

 

TL;DR

On a suspend your OnNavigatedFrom handler may be called, but on resume, OnNavigatedTo isn’t.  All sorts of paired handlers may not work as you expected.

You might want to look at OnNavigatingFrom instead but I’m still not convinced that’s correct either.

When Bindings Fail, and text blocks show double quote greater than

Today I was tracking down a bug where my text block was showing “> (quote greater than) when the data context was null.

I’d run into this problem once before in a WPF application, but couldn’t remember what the resolution was. 

After playing around for awhile, with various things fixing the problem, but for no apparently good reason, I had another look at the XAML.  A really close look.

Here was the XAML:

<TextBlock Style="{StaticResource StrokeSummaryBigValue}" 

                          Text="{Binding Rating, Converter={StaticResource rating}}">"></TextBlock>

It looks like while typing, intellisense had entered an extra “> into the code, so that when the binding failed, it showed the text contained in the text block.

So there you have it, if you see this behavior, search your code for “>”>