'T' Is For "Too Cool"

I've mentioned here before that I was part of the original team that wrote MSDN2. I guess that's why I get occasional questions about the website. Of course, I was involved in writing the Microsoft/TechNet Publishing System (MTPS), the system behind the web pages, and not in the actual rendering stuff, but I try to help when I can. So the other day when someone asked me a question, I shot off an email to someone on the team to see if I could get him an answer. The response I got taught me something cool I didn't know about the website, so I thought I would share (with permission).

 

There are three new features to the MSDN2 website - two you may have noticed and one you probably haven't. The first one that's a bit more obvious is that the nav tree recently started loading asynchronously in its own iframe. What this means is that you no longer have to wait for the tree to load before you can view the content. As "I don't want to wait for the tree" is easily the number one complaint I have personally heard about the site - woohoo! Further changes are planned to make this even better.

 

Another one you might have picked up on is that the "trail of bread crumbs" navigation control along the top of the content (the internal MSDN term for it is "the eyebrow") has some added functionality. It now sports an AJAXy dropdown feature that makes it easy to navigate to siblings of the current node or any of the current node's ancestors. Go try it (for example, here) - you'll see what I mean.

 

The final, more subtle feature is that you can hit the 't' key to toggle visibility of the nav tree. I love this feature because I often just type in a URL to jump directly to a piece of documentation, so I don't need the tree at all. But whether I do or not, toggling the tree lets me use the full width of the screen for the content…very nice.

 

So kudos to the rendering team for making the MSDN2 site nicer to use!

Avalon (WPF) Application Not Closing

I've had a problem for the last few days that has been driving me nuts. I'm writing an Avalon (WPF) application, and the damn thing wouldn't shut down. Even though I was calling this.Close() in my File->Exit handler, the process would stick around. It was particularly insidious because the main window would close, making it look like the application had exited. Even though I knew it had this problem, I would still forget until the next time I would compile, when I'd get the error, "The compiler can't overwrite the file (dumbass)."

 

Mike Woodring and I spent what must have been close to an hour reviewing all my threading code to make sure it was correct. It wasn't, of course (it never is), but after we'd tried everything I ripped all that code out and it still wouldn't close.

 

It bugged me enough that it was the last thing I was thinking of as I fell asleep last night. And then - and I'm sure this has happened to most people reading this - I solved the problem in my sleep.

 

Here's the deal. I had a class that looks more or less like this:

 

public partial class MyWindow : Window {

  private readonly MyDialog _myDialog = new MyDialog();

 

  protected void OnFileExit(...) {

    this.Close();

  }

}

 

Where MyDialog is another Window. I like to use this pattern for dialogs that I'm going to pop up and down a lot: create it once during the constructor. That way they keep all their settings and whatnot when they're not visible. And in WinForms, this works great. However, in Avalon I needed to do this:

 

public partial class MyWindow : Window {

  private readonly MyDialog _myDialog = new MyDialog();

 

  protected void OnFileExit(...) {

    this.Close();

    _myDialog.Close();

  }

}

 

even if you never displayed the dialog! Because otherwise, you apparently still have a top-level window hanging out, and Avalon won't let you exit the process.

 

I haven't looked to see if there's some magic property that says "OK to nuke the process if this window is still around". You may want to check the comments on this post - given my level of knowledge of Avalon at this point, it's likely that someone out there knows better how to address this. Certainly, having to remember to Close all your subordinate Windows can't be the best way. But it beats having to run Process Explorer to kill the process every time.

Your Code May Be Suboptimal, But This T-Shirt Is Perfect

A few weeks ago, Eric Sink of SourceGear posted this article. I try to read everything Eric writes - he's one of the few guys on the business side with a background in the pointy end of the business he's managing, so he's got an interesting perspective. Plus, he seems damn smart.

 

Anyway, if you scroll down to the end of his article, you'll see a picture of the rockin' t-shirts they were giving away at SD West. I don't much make it to conferences any more, but I wanted a shirt. So, because Eric also seems like a nice guy, I emailed him to ask for one. I thought I'd offer to pump up the free advertising factor a bit by agreeing to post a picture of me wearing the shirt here. Nothing ventured, nothing gained.

 

Well, I ventured an email and gained a t-shirt. Here's my end of the bargain:

 

 

I'm not sure you can read it at this size (click the picture to jump to Flickr, where you can get the full-size version), but the evil mastermind robot dude is saying, "Your code is suboptimal".

 

My daughter wanted in on the act as well:

 

 

Thanks Eric!

 

InlineUIContainer and BlockUIContainer

I've been doing a project using Avalon (WPF, if you insist on using the sucky name), and have been learning a lot. I think it's the coolest of the .NET 3.0 family of technologies. Although I'm going to be attending Pluralsight's upcoming Workflow & WCF Double Feature in Waltham, so maybe more exposure will change my mind. I doubt it, though. :)

 

One of the areas that really interests me in Avalon is System.Windows.Documents. It interests me because it looks like it could make the next version of FlexWikiPad really easy to write - a well-thought-out model for text presentation that doesn't require messing around with a WebBrowser control. I'd even gone so far as to start writing a text editor control using .NET 1.1-era technologies. So I was happy when my current project gave me a chance to start dabbling in FlowDocument and friends.

 

One of the questions I ran across pretty quickly was "How do I include an image in a FlowDocument?" There's no Image element in System.Windows.Documents - just stuff like Paragraph, List, Bold, Span, etc. A quick question fired of to Ian (tired of my questions yet, dude?) revealed InlineUIContainer and BlockUIContainer, two wonderful classes that let you embed arbitrary Avalon controls inside a FlowDocument. All I had to do was wrap one of them around a System.Windows.Controls.Image control and I was off to the races.

 

Definitely a nice pair of bullets for the Avalon gun.

Outlook Feed Bug?

I ran into this today when I was fixing up FlexWiki 2.0's RSS mechanism to work with the new security provider. I finally got the page with the links to the RSS feeds to render, and I was a bit surprised when Outlook popped up showing what was obviously an ASP.NET error message. I was even more surprised that the same URL worked just fine in IE (I'd been testing with Firefox).

 

A little debugging and I think I figured out what's happening. Firefox appears to be launching Outlook as the registered application for RSS documents (presumably based on the ContentType, which is text/xml). Anyway, that's fine - I use Outlook to read RSS feeds, so great. What's not great is that Outlook decided to lowercase the URL.

 

Hello?! URLs are case-sensitive! Who thought it was a good idea to screw with the case of URL? I mean, it's fine to write a web application that accepts either case on the server side, but you can't just send either case as a client - you have to assume case sensitivity.

 

FlexWiki is highly case-sensitive as part of its design. So the lowercased namespace in the URL results in a failure to look up the right information. I'd write a fix for this into FlexWiki, but frankly I'm not sure that's a good idea. Outlook seems (to me) to be pretty clearly broken on this one.

 

I googled (lowercase intentional) for info on this but wasn't able to turn up much. Anyone know anything?