Here's a frustrating WPF scenario — you use the ApplicationCommands class to add Cut, Copy and Paste commands to toolbar and then put a TextBox on another toolbar. Click in the TextBox and the commands remain disabled. WTF, WPF?

The problem is with focus scopes. Your window is a focus scope and so are any menus or toolbars. This has the desirable property of allowing commands to target the control you were in immediately before invoking the command. You want paste to target the text box you're editing, not the menu item or button you clicked to request the paste.

So far so good. The problem is that the commanding system isn't smart enough to target the control with keyboard focus if it's in a nested focus scope. Remember that the window itself is a focus scope so our TextBox in a ToolBar (also a focus scope) is nested and immune to commands from our menu or toolbar.

Here's a simple window that demonstrates the problem:

More...

I'm slowly converting a number of blogs from Blogger to BlogEngine.NET. The least fun part is dealing with the Blogger export file. For this blog I used a Powershell script but had problems with comments not exporting correctly and it was quite painful to fix everything up. Blogger allows you to export a copy of your blog using ATOM, however BlogEngine.NET (and other tools) speak BlogML.

I've just released a command line tool that takes the ATOM format Blogger export and converts it to BlogML. You can download Blogger2BlogML from Codeplex. The tool uses .NET 4.0 (client profile) so you'll need to install this if you don't already have it. If you give Blogger2BlogML a try let me know how you get on. 

I've just released a small update for my ESRI Shapefile Reader project on Codeplex. The only change is a patch from SolutionMania that fixes a problem when the shapefile name is also a reserved name in the metadata database. The patch escapes the name preventing an exception from being thrown.

Catfood.Shapefile.dll is a .NET 2.0 forward only parser for reading an ESRI Shapefile. Download 1.20 from Codeplex.

I've been going nuts trying to scan from the document feeder on my Canon imageClass MF4150. Everything worked as expected from the flatbed, no dice trying to persuade the ADF to kick in. I found some sample code but it was oriented towards devices that can detect when a document is available in the feeder. Evidently my Canon doesn't expose this and so needs to be told the source to use.

The way to do this is to set the WIA_DPS_DOCUMENT_HANDLING_SELECT property to FEEDER. You then read WIA_DPS_DOCUMENT_HANDLING_STATUS to check that it's in the right mode and initiate the scan. This did not work for toffee.

After much experimentation I discovered a solution. I had been setting device properties and then setting item properties before requesting the scan. Switching the order - item then device - made everything work.

Here's the function to scan one page:

More...

After floundering a bit with the WPF Dispatcher I've come up with a simple way to make sure an event handler executes on the UI thread without paying the overhead of always invoking a delegate.

void someEvent_Handler(object sender, SomeEventEventArgs e)
{
    if (this.Dispatcher.CheckAccess())
    {
        // do work on UI thread
    }
    else
    {
        // or BeginInvoke()
        this.Dispatcher.Invoke(new Action<object, SomeEventEventArgs>(someEvent_Handler), 
            sender, e);
    }
}

This has the benefit (for me at least) of being very easy to remember. Hook up the event handler and then if there's a chance it could be called from a different thread wrap it using the pattern above. It's easier to read than an anonymous delegate and much faster than defining a specific delegate for the event in question.

I haven't tested the various methods to see which is the fastest yet… will get round to this at some point.

The Spire by Richard North Patterson

3/5

A good enough holiday read and nice to see Patterson return to a straight psychological thriller rather than the last few OpEds loosely wrapped with some plot.

 

More...

When testing out a WPF app on XP I got an unhelpful XamlParseException error report. 

I was a little puzzled because I was hooking up error reporting in App.xaml.cs:

App.Current.DispatcherUnhandledException += 
    new DispatcherUnhandledExceptionEventHandler(Current_DispatcherUnhandledException);
AppDomain.CurrentDomain.UnhandledException += 
    new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);

My error handler was attempting to create a XAML window to report the error, and evidently this was bombing out as well triggering the good doctor Watson. I added a MessageBox call instead and discovered that the XamlParseException was wrapping a FileFormatException and the stack trace indicated that the problem was with setting the icon for the window. After removing the icon the app started up fine. Weird.

It turns out that WPF chokes on a compressed 256x256 icon on XP and Vista (Windows 7 seems to cope fine). Saving the icon without compression fixes the problem. I use IcoFX and you can set this at Options -> Preferences -> Options -> Compress 256x256 images for Windows Vista. Of course the consequence is that the icon is a couple of hundred kilobytes larger.

I've spent the last day learning how to use OAuth and XAuth to post to Twitter. There are rumblings that Twitter will start to phase out basic authentication later this year, and more importantly you can only get the nice “via...” attribution if you use OAuth (for new apps, old ones are grandfathered in).

I coded up my own OAuth implementation, referring to Twitter Development: The OAuth Specification on Wrox and the OAuthBase.cs class from the oauth project on Google Code. Both are great references, but both fail with multibyte characters. The problem is that each byte needs to be separately escaped. OAuthBase.cs encodes characters as ints rather than breaking out the bytes and the Wrox article incorrectly suggests using Uri.EscapeDataString(). 

Here's a method to correctly encode parameters for OAuth:

public static string OAuthUrlEncode(string s)
{
    if (string.IsNullOrEmpty(s))
    {
        return string.Empty;
    }
    else
    {
        StringBuilder sb = new StringBuilder(s.Length);

        for (int i = 0; i < s.Length; i++)
        {
            if (NoEncodeChars.IndexOf(s[i]) == -1)
            {
                // character needs encoding
                byte[] characterBytes = Encoding.UTF8.GetBytes(s[i].ToString());
                for (int b = 0; b < characterBytes.Length; b++)
                {
                    sb.AppendFormat(CultureInfo.InvariantCulture,
                    "%{0:X2}",
                    characterBytes[b]);
                }
            }
            else
            {
                // character is allowed
                sb.Append(s[i]);
            }
        }

        return sb.ToString();
    }
}

NoEncode chars is a list of the permitted characters:

An impact of this encoding is that spaces must be encoded as %20 rather than plus. I was worried that each space would end up counting as three characters towards the 140 character limit. I tested this and it isn't true, so use HttpUtility.UrlEncode() to calculate the number of characters in the post OAuthUrlEncode() or similar to actually encode post parameter.

I finished off my BlogEngine.NET migration yesterday missing a couple of useful sections from the previous incarnation of this blog. The first is a list of the most popular posts based on Google Analytics data. I've just finished porting this from a UserControl to a widget for BlogEngine.NET. To use this just download and extract this zip file to your widgets directory:

MostPopularFromGA.zip (5.22 kb)

You can see the widget in action under the Most Popular heading to the left if you're reading this post on the blog.

More...

(Update June 22, 2010: I've released a tool, Blogger2BlogML, that converts Blogger's ATOM export file to BlogML. I ended up doing this because of problems with comments when I migrated this blog — I had to fix these up manually which was painful. I'm now working on some larger blogs where this would be impossible…)

In January I got an email from Blogger announcing that they're killing FTP support. Apparently only 0.5% of Blogger blogs are published using FTP and it's a huge pain to support, mainly because many hosting providers restrict FTP access to certain IP addresses and if the Google servers running Blogger that moment aren't listed it's technical support time. 

Fair enough, but a bit painful for me as I have five blogs running on top of Blogger. I need FTP publishing as the templates I use end up running as ASP or ASP.NET pages. I Thought He Came With You is the first to move - if you're reading this post then it's up and running on BlogEngine.NET. This is an open source ASP.NET blogging platform. If it works out for this blog over the next month I'll start migrating the others. 

Getting up and running with BlogEngine.NET is easy enough - download the latest release and follow the getting started guide. I added the default install to a new Visual Studio web site project and was able to run it fine in the development server, no need to configure IIS. 

The challenge was moving posts and comments from Blogger into BlogEngine.NET. BlogEngine.NET happily imports and exports BlogML, Blogger spits out it's own Atom export format. 

More...