StackOverflow DevDays

Updated on Saturday, July 18, 2020

Fort Mason, San Francisco

Just got back from the StackOverflow DevDays event in San Francisco. I was a bit worried that this would be overly focused on marketing FogBugz and StackOverflow. There were brief pitches on each (and I learned that FogCreek is launching hosted source control and code reviews called Kiln, now in beta and looking pretty nifty with tight integration with FogBugz) but this wasn't the focus.

I was also a little concerned that I'd be the only one there without a StackOverflow profile t-shirt. Luckily I didn't see any reputation toting pod people at the conference.

Happily the day was very code oriented, and very diverse. Spell checking in Python, smartphone development for iPhone, Nokia (via Qt) and Android, ASP.NET MVC and jQuery. I spend most of my time at the moment in C#/.NET and it was really valuable to spend a day briefly diving into different stacks and platforms.

Joel said that they'd be back next year and I'm hoping that it offers a similar diverse range of topics.

Blogger Classic Templates Bugs and XHTML

Updated on Sunday, May 3, 2020
I've just migrated this blog from catfood.net to its own domain. In the process I needed to port the template from classic ASP to ASP.NET and I also wanted to end up with valid XHTML.

If you're using blogger on your own domain then you're using the classic templates. There is a known issue with the template tag that causes Blogger to emit unwanted JavaScript - this causes havoc, especially if you're using the tag in the section of a page.

Google recommends using the <$BlogPageTitle$> tag in the page title. This works, but it's not great from a usability or SEO perspective. For item pages you get the post title after the blog name and you probably want to put the post title first - the earlier that keywords appear in the title the better for search engine ranking.

Luckily there's an easy fix - just comment out the closing Blogger tag:

This doesn't interfere with the template rendering correctly and the JavaScript is then commented out on the rendered page. It's still an unpleasant bug, so if you use the classic templates please report it here and also star or comment on this forum topic to encourage Google to fix it.

If you use labels then Blogger includes them in a paragraph rendered with <$BlogItemBody$>. This means that wrapping <$BlogItemBody$> in a paragraph will cause XHTML validation errors for posts with labels because you can't nest another block element inside the paragraph.

The other XHMTL nasty I fixed was the post comments link. My template used the recommended Blogger code:
<p><a href="<$BlogItemCommentCreate$>"
<$BlogItemCommentFormOnClick$>>Post a Commenta>p>

This renders as:
<p><a href="https://www.blogger.com/comment.g?blogID=12345678&postID=1234567890123456789"
location.href=https://www.blogger.com/comment.g?blogID=12345678&postID=1234567890123456789;>
Post a Commenta>p>
And you end up with a gazillion cascading XHTML errors, all caused by the illegal ampersand. I fixed this by constructing my own comment URL using the <$BlogItemNumber$> tag (this emits the unique Post ID):
<p><a href="https://www.blogger.com/comment.g?blogID=12345678&postID=<$BlogItemNumber$>">
Post a Commenta>p>

Fastest image merge (alpha blend) in GDI+

Updated on Tuesday, April 27, 2021

Blended image from Catfood Earth

I've been experimenting with the best way to merge two images in C#. That is, paint one image on top of another with some level of transparency as opposed to using one color as a transparency mask. I tried three candidates, all included below:

SimpleBlend is the naive approach using GetPixel and SetPixel to add the desired alpha value to the second image before painting it on top of the first.

MatrixBlend configures a ColorMatrix to specify the desired alpha and then paints the second image on to the first using the matrix.

ManualBlend locks and directly manipulates the image data. This uses pointers and so introduces unsafe code (it's possible to marshal the image data into a managed array but I wanted to look at the performance with raw access).

I tested each approach ten times with a couple of large JPEG images. The results are:

SimpleBlend: 17.69 seconds
MatrixBlend: 0.74 seconds
ManualBlend: 1.13 seconds

I expect ManualBlend could be optimized further but both this and MatrixBlend are an order of magnitude faster than the naive approach. I'll be using MatrixBlend as no unsafe code is required.

MessageInterceptor doesn't always...

Updated on Sunday, May 3, 2020

I've been writing a play by text message version of battleships for Windows Mobile 6 using the MessageInterceptor class to receive messages. This works great on my AT&T Tilt but completely fails on my wife's Pantech device. The MessageInterceptor hooks up fine but never fires.

The 2.0 compact framework SmsAccount lets you send messages but unaccountably doesn't let you read them.

I avoided some unpleasant interop by grabbing the MAPIdotnet library. This implements a NewMessage event for MAPI stores, however as with MessageInterceptor the event hooks up OK but never fires on the damned Pantech.

MAPIdotnet does allow you to read the SMS inbox though, so the final answer is to fall back to looking for, processing and then deleting game related text messages on a timer. This is far from ideal as the game messages arrive and vibrate the phone before getting processed but at least it's now possible to play without buying a new phone.

To add to the frustration during development the Visual Studio 2005 toolbox lost all icons except for the pointer and a custom control that was part of the project. Resetting the toolbox didn't help, nor did restarting VS and the computer. The fix was to exit VS and then delete all the .tbd files from Microsoft\VisualStudio\8.0 in local application data. Sigh.

Launching a URL in the user's default browser

Updated on Sunday, May 3, 2020

This has bitten me a few times. If you use Process.Start("url") it will work some of the time but you'll see a "The system cannot find the file specified" Win32Exception on some systems. Bummer.

Lots of people suggest looking up the HTTP handler in HKEY_CLASSES_ROOT but this is flawed as well - on my system for instance HTTP is registered to Firefox even though I'm actually using Chrome and I'd be unhappy waiting half an hour for Firefox to wake up and show the requested web page.

From XP there are a couple of registry settings tied to the current user's preferred browser.

First check HKEY_CURRENT_USER\Software\Clients\StartMenuInternet. This key will only exist if the user has overridden the system default browser - the default value is used to access the details (for me, it's chrome.exe).

If the user hasn't set a default then check HKEY_LOCAL_MACHINE\Software\Clients\StartMenuInternet. The default value here is the system default browser (on my system it's FIREFOX.EXE).

There is a set of subkeys under HKEY_LOCAL_MACHINE\Software\Clients\StartMenuInternet that contain details about each registered browser. The default value from StartMenuInternet (either HKCU or HKLM) is the subkey to look for. The path to my default browser is in this key:

HKEY_LOCAL_MACHINE\Software\Clients\StartMenuInternet\chrome.exe\shell\open\command

Now I can Process.Start(path, url) to safely launch the default browser. You can fall back to Process.Start(url) if registry access fails for some reason, but be prepared for that Win32 exception.

WiX Tricks for Screen Savers

Updated on Wednesday, May 5, 2021

I've been migrating my installers over to WiX. My only complaint with the WiX toolkit is that there's no bootstrapper included. This is important for installing any pre-requisites before passing control over to Windows Installer. Hopefully this will come after WiX 3.0 is released. For now, I've rolled my own bootstrapper to install .NET 2.0 if needed.

A couple of tips for screen savers. You can bring up the Windows screen saver settings using the following custom action. This is the same command that is launched when you right-click a screen saver (.scr) file and pick Install:

<CustomAction Id='InstallSS' Directory='SystemFolder' ExeCommand='rundll32.exe desk.cpl,InstallScreenSaver the.scr' Return='asyncNoWait'/>

Sequence this in InstallExecuteSequence after InstallFinalize:

You can also add a shortcut to your Program Files folder to configure the screen saver. This is really helpful for people who aren't sure how to get to the screen saver dialog from Control Panel or right-clicking the Desktop:

Unlike a shortcut to a file that you install you need to specify the Target. The example above assumes that ProgramMenuDir is the Id of your Start Menu folder. The shortcut should be in a Directory but not as a child of a File node.

Updated 2020-05-26 20:22:

It looks like something changed in Windows 10, around build 1903, that stops this from working on 64-bit systems. The screensaver will preview OK but does not start as expected (system screensavers start OK, so it's not some sort of power management problem). I could reproduce this on one box running 1909 but not another so maybe there is something else going on. The snippets above will run rundll32.exe from the SysWOW64 folder and at some point this seems to have stopped working. Changing to [System64Folder]rundll32.exe launches the System32 version which then causes the screensaver to load normally. If your screensaver is 32-bit and installed to SysWOW64 then you need a command that looks like this on a 64-bit system: [System64Folder]rundll32.exe desk.cpl,InstallScreenSaver [SystemFolder]the.scr

code, c#

Video timeout on XP and Vista (power management)

Updated on Sunday, May 3, 2020

I'm updating a screensaver so that it stops work once the monitor switches off. This seemed like a really simple requirement but it took some time to find an API that works on both XP and Vista.

My first attempt was ReadPwrScheme(). The documentation suggests using a different method on Vista - it should say so more strongly because on Vista you get back some default information that bears no relationship to reality.

Next I tried CallNtPowerInformation(). This doesn't mention any alternatives but also doesn't work on Vista. I've added comments on both MSDN pages pointing to the answer.

GetCurrentPowerPolicies() is just the ticket - it returns a wealth of information including the video timeout on AC and battery power and works on both XP and Vista.

Pinvoke.net has all the structures required but not the actual function. I've just added the C# interop signature for GetCurrentPowerPolicies().

I can't believe how frustrating finding this information has been. If you've found this post I hope it saves you a couple of hours :).