Page.Loaded Fails to Fire

Yesterday, we installed windows 10.

We tried out our app BouncingBalls and was surprised that the balls didn’t start bouncing, when they did on Windows 8.1

Even more oddly, if you opened the settings page, they would suddenly start bouncing.

Firing up the debugger, we found that Page.Loaded was not firing when we navigated to the main page.  The code we use is similar across all of our apps, but for some reason this particular app was not behaving.

After quite a bit of code hacking, we found it came down to the handling of the splash screen.

We add a handler for Splashscreen.Dismissed, and handle navigation to the main page (or another page depending on trial mode) from there.

In our OnLaunched handler, we called

Window.Current.Content = _launchframe;
Window.Current.Activate();

but we hadn’t yet navigated to a page, or set any content for our frame _launchframe.

In the Dismissed handler, we did this:

var nowarn = _launchFrame.Dispatcher.RunAsync( CoreDispatcherPriority.Normal, () => ContinueAfterSplash1());

And in ContinueAfterSplash1() we eventually call after a few async calls.

_launchFrame.Navigate(typeof(BouncingBalls.MainPage), args)

MainPage received an OnNavigatedTo call, but never received the Loaded event we wired up.

The solution?

In the end, we changed the code not to call Window.Current.Content until after we successfully navigated to the MainPage.

For whatever reason, that caused the Loaded event to fire every time.

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.

Universal Apps: partial understanding

One of the ways to build a universal app is to use the partial keyword to allow you to split out functionality that must be different between platforms.

We tried this with our error reporting code, loosely based on LittleWatson.

There is good documentation here http://msdn.microsoft.com/en-us/library/wa80x488(v=vs.90).aspx on partial classes, but despite what it said we just couldn’t get it to work correctly.  So we concocted more and more bizarre ways to use partial, so that the program would compile, including partial methods (which unless implemented the compiler optimizes out).

In the end, it turned out to be nothing related to partial at all, that was preventing our methods from being called.  What had actually gone wrong was this:  We had inadvertently put half of the partial class in a different namespace, thereby making it invisible.  It’s no wonder we couldn’t find member fields in our main implementation.

Where’d my interface go?

One of the joys of modern development is that you get to work in pretty much any language there is.

I’ve been doing a lot of C# development lately (Phone, WinRT and WPF desktop), but occasionally have to drop back to some C++/MFC software.

Yesterday, I had to refactor some code, that made some glaring assumptions about it’s use (yes, I used reinterpret_cast to convert a CWnd derived object to a class derived from CPropertyPage so that I could call one of it’s public members).

So here’s what I did:

First, I declared an interface that represented exactly what I wanted to do:

interface IDoSomethingAwesome
{
  public:
    virtual void DoSomethingAwesome()=0;
};

Next, I modified my class, which needed to expose the interface

public class MyAwsomePropertyPage : 
  public CPropertyPage, IDoSomethingAwesome
{
  /// ... etc.
  virtual void DoSomethingAwesome() override;
}

and provided an implementation in the class.

Then in an unrelated class, I made a call like this

CChildOfAwsome::SomeEventHander()
{
   IDoSomethingAwesome *pInt = dynamic_cast<IDoSomethingAwesome>(GetParent());
   if (pInt != NULL)
   {
       pInt->DoSomethingAwesome();
   }
}

Only one problem:  pInt was always NULL!  That was odd, because looking at the pointer returned by GetParent() gave me an object that the debugger knew was of type MyAwesomePropertyPage, yet I couldn’t for the life of me figure out why this wasn’t working.

I started writing this up as a question on StackOverflow, but while doing so, ended up talking to the duck and discovered the error in my ways.

My C# had blinded me to the joys of C++ inheritance.

I had inadvertently declared my IDoSomethingAwesome interface not public.  As a result, asking for the interface dutifully returns null, as private inheritance is an implementation detail, and not visible in the inheritance tree.

So, the correct declaration is

public class MyAwsomePropertyPage : 
  public CPropertyPage, public IDoSomethingAwesome
{
  /// ... etc.
  virtual void DoSomethingAwesome() override;
}