« December 2009 | Main | February 2010 »

January 30, 2010

It had better be the most nutrition-packed mouse in the whole world ever

The cats have spent the last three days and nights in a frenzy of mouse-hunting excitement.

This would not be so bad, except I think it is still the same mouse.

Just one of the many places they like to lose their quarry

January 30, 2010 | Permalink | Comments (0) | TrackBack

January 29, 2010

History by implication

“Browsing the OED is a tantalising experience because it provides windows into so many obscure corners of history. But since the citations are small and fragmentary, they invite the imagination to fill in the blank spaces.”

Thus the Bygone Bureau, presenting a secret history of typography in the Oxford English Dictionary.

(Via Morgue.)

January 29, 2010 in History | Permalink | Comments (0) | TrackBack

January 22, 2010

Designed by programmers

Resharper: no, thanks.

(Via Nathan Li.)

January 22, 2010 in Usability | Permalink | Comments (2) | TrackBack

January 20, 2010

Wellington .NET User Group – Dive into LINQ

Thanks to everyone who came along to tonight’s LINQ refresher session.  Nice to see the interest in the Reactive Extensions – maybe a future topic once I’ve got my head around them a bit more.  (A lot more.)

In the meantime, here are the slides and demos.  The zip file for the demos includes the Rx libraries, so the sample should run standalone; if not, or if you just want to learn more, you can get the Rx download from here.

Dive into LINQ - slides

Dive into LINQ - demos

January 20, 2010 in Software | Permalink | Comments (0) | TrackBack

January 12, 2010

XamlParseException debugging tips

Debugging declarative languages is a pain in the backside, but tools are beginning to emerge.  Regular expression visualisers are becoming the new blogging engines (which were, in their time, the new e-commerce stores).  CSS, once my bete noire, now has thingies that tell me exactly which style is causing my finely crufted werds to be squeezed into a column two pixels wide and displayed so far outside the page boundary that they need their own postcode, and can finally be downgraded to a bete grise.  And WPF has… the XamlParseException.

Here, then, are a few basic tips for debugging XamlParseExceptions.

0. Don’t just dismiss the exception notification.  It contains vital clues.

This may seem obvious.  But a lot of developers have been trained by procedural exceptions to get the exception assistant out of the way pronto and start waggling their mice over every variable in sight like a cat owner desperately trying to coax signs of enthusiasm from their frankly contemptuous pet.

Don’t do it.  The debugger can’t help you here; the exception info is your lifeline.  A XamlParseException usually contains three useful pieces of information: an inner exception (or lack of one), a location (which may be wrong, but can still provide clues) and a message.  These will usually be enough to diagnose and fix the problem, if you take the time to read them.

1. Look at the inner exception.  A XamlParseException does not necessarily mean there is anything wrong with your XAML.

This may seem counterintuitive.  Heck, it is counterintuitive.  But any unhandled exception in your window (or control) constructor will result in a XamlParseException.

How will you know whether it’s a XAML error or a constructor exception?  Look at the inner exception.  If there is one, and it’s a TargetInvocationException, then your constructor threw an exception.  The TargetInvocationException has its own inner exception, which tells you the real underlying exception.  Once you’ve got this, you’re back into the familiar realms of procedural debugging.

Here’s an unlucky fellow on Stack Overflow, getting a XamlParseException from some perfectly unexceptionable XAML.  Take a look at that monster exception dump.  There are two things right at the top of the message that indicate that this is a constructor exception rather than anything wrong with his XAML.  First, the message is “Exception has been thrown by the target of an invocation.”  That’s the spoor of TargetInvocationException.  Start drilling.  Second, the position is “LineNumber=1 LinePosition=9.”  That’s right on the x:Class attribute.  This means there’s a problem hooking the XAML up to the class: unless the class is complete garbage, that again suggests a constructor problem.  Sure enough, wading through the trail of inner exceptions we find a configuration exception with a nice simple stack trace pointing very clearly to the culprit.  Problem solved.

2. Beware of loose content.  Sometimes the exception points to the element after the error.

XML is a finicky language, and combined with the strict content models of WPF this makes it easy to introduce errors through simple typos.  One error I’ve run into a fair few times is when you accidentally leave a bit of loose content lying around:

<StackPanel Margin="20">>
  <TextBlock Text="One" />
  <TextBlock Text="Two" />
</StackPanel>

This compiles, but blows up at runtime.  The exception assistant confidently locates the error on the first TextBlock element.  You might be tempted to roll up your sleeves and start hacking on that TextBlock until it jolly well parses.  But remember: stop, wait, look at the exception:

'String' object cannot be added to 'StackPanel'.

Well, hang on.  A TextBlock isn’t a string.  Can we see any direct descendants of the StackPanel that are strings?

On closer examination, a bit of sloppy editing – assisted by Intellisense, the world’s leading producer of loose content – has left a stray > after the StackPanel declaration – and immediately before the TextBlock that the exception message was directing us to.

Loose content can be a bit hard to spot, and the bad location pointer doesn’t help.  If you’ve got an exception message complaining about strings but pointing to an element, try looking backward from the exception location and see if you can spy a spurious character or two.

3. Check your spelling… and capitalisation.

XAML is case-sensitive and, in a shock new development for programming languages, typo-sensitive.  If you create a resource with the key “MyResource” and then refer to it using “{StaticResource myresource}” or “{StaticResource MyResuorce},” then the compiler will cheerfully assume that these res0urces will be delivered by magic pixies at some later stage.  Needless to say, come runtime, the magic pixies are still down the pub, and you’re left with the inevitable XamlParseException.

Once again, the clue is in the exception message.  The exception will tell you which resource reference it couldn’t resolve, and where to find that resource reference.  (For once, the location is generally both accurate and useful.)  If you read the exception message, all that remains is to curse your semi-literate and case-insensitive co-workers, and go figure out what the resource is meant to be called.  This will involve trawling through 60000 lines of XAML spread across 48 merged resource dictionaries, trying to guess how your outsourced development team have managed to misspell “burhs.”  Simple solutions to this one are left as an exercise for the reader.

This isn’t by any means a comprehensive guide to the wonderful world of the XamlParseException.  In particular, Silverlight programmers can expect to enjoy numerous other adventures in— no, only kidding.  Silverlight programmers will continue to get AG_E_UNKNOWN_ERROR for any and every problem.  And if anyone knows how to debug that, I’d love to know the secret.

January 12, 2010 in Software | Permalink | Comments (4) | TrackBack