This is a small update to Wallpaper Changer which adds an extra option. You can now tell it to not re-calculate the desktop size every time it changes the wallpaper.

The problem I was having is that I'll sometimes remote-desktop into my machine, and if it happens to change the wallpaper when I do, it'll pick up the wrong size (it'll be the size of the remote desktop window). So I made this option to disable the desktop-size recalculation.

My settings are stored in a simple binary serialization of my "settings" class, so this means that and old settings won't be remembered when you start up the new version. I guess this is something I should work on, but it's not a priority for now :)

Anyway, you can download version 1.2 here. Enjoy!

I just installed Office 2003 at work, and it's got this rather nice "Reading Layout View" for reading documents in Word. Reading Layout View makes much better use of screen real estate by displaying two pages next to each other, supposedly like a real-life book.

For some reason, though, it enables ClearType on the text in Reading Layout View whether you have an LCD monitor or not. It seems strange, but some people apparently find ClearType is easier to read on a CRT -- not me, however, and that's why I have it turned off in the rest of the Operating System. So why doesn't Word respect that fact? Fair enough if I have it turned on in the rest of the OS (a quick investigation on my laptop shows that it does indeed use ClearType in the rest of Word when it's enabled in the OS), but why override my settings in Reading Layout View?

A quick search for "reading layout ClearType" in the help turned up the following:

Reading layout view uses ClearType even if it is not enabled in Windows. To turn it off, do the following:

• In your system registry, set the following key to zero (0):
  
  HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Word\Options\UseClearType

(See the online version of the page if you don't believe me)

Of course, this is of little use, since first of all it's calling "UseClearType" a key when I assume they mean value, and second of all they don't say whether it's supposed to be a DWORD, string, or even binary value. Needless to say though, I tried every possible combination and couldn't work out how to fix it.

Then I happened to stumble upon this knowledge base article which gives the proper value: NoClearTypeNW (whatever "NW" means) and it's a DWORD. I put that value in, and it turned off ClearType.

Anyway, I submitted a comment to the incorrect page and hopefully they'll fix the registry key reference there, but there's a bigger problem here, so I say to Microsoft:

Always respect the user's preferences!

I think the reason they turn ClearType on in Reading Layout View is because not a lot of people know about the ClearType setting to begin with. But that doesn't really matter, since my laptop (which came with Windows XP pre-installed) had ClearType turned on by default, and I assume mine is not the only one. The other reason that doesn't matter is because turning ClearType on in Reading Layout View is fixing the symptom, not the problem. The problem is that the UI to set the "ClearType" setting in the OS is buried so deep in the Display Options that most people aren't going to just "stumble" on it.

Anyway, Office 2003 is pretty darn cool (though I wish they used my Visual Styles to render the toolbars and menus, because the one they use really looks bad combined with the Visual Style I use, but that's a story for another day...), so I'll just leave my rant at that :)

This is a fairly minor update to my Wallpaper Changer app. See my first post on Wallpaper Changer for a description of the features. The only real thing that's changed here is that I've added a hidden window to act as the main window, rather than the main "Wallpaper Changer" window. The advantage is that you never see the "Wallpaper Changer" app in the Alt-Tab list (unless it's actually visible) unlike before.

There were some other minor bug fixes, but I won't bore you with details. Just download it now :)

I needed a tool that allows me to convert times between different timezones. There are plenty of programs that tell you the "current time" in a given timezone, but it's not much good for converting.

Anyway, this little app just sits in your tray and when you double-click the icon, it pops up a window for you to enter the date. Then just select the source/destination timezones and it'll show what time it is in that timezone.

You can download it here.

It's been a while since I last posted, sorry, it's hard to find time to post all the time. Seriously, I don't know how people like Scoble do it!

Anyway, I've had a bit more fun with using CDO from .NET. I was having problems when trying to load an email message that contained body-parts encoded with the "unicode-1-1-utf-7" encoding. This encoding seems to be most popular with DSN (delivery status notification) messages, but theoretically any mail client should be able to encode with that encoding.

Checking the documentation for the GetDecodedContentStream method on MSDN had some rather obtuse text about how UTF-7, UTF-8 and few other encodings get set to some generic Unicode encoding and some sample code for copying it to a temporary stream. Unfortunately, it didn't really explain the problem very well (I mean, why does it use this generic Unicode thing?) and the sample code was for the opposite of what I was doing (i.e. adding body-parts in UTF-7/UTF-8, not decoding an email). Finally, it doesn't really explain the error I got, which was something like "A disk error occurred during a write operation" -- write operation? First of all, I wasn't even doing a write, and second of all, once I'd loaded the message there was no disk involved!

So anyway, after a bunch of messing around, I finally came up with some code that works. Say you have some MIME-encoded text like this:

MIME-Version: 1.0
Content-Type: text/plain; charset=unicode-1-1-utf-7

Here's a unicode character "+ANw-" it doesn't work.

If you just take the the body-part of the CDO.Message object, and called GetDecodedContentStream on it, when you try to call ReadText it'd return that error.

Anyway, my solution is below. Basically, I had to call CopyTo to copy the stream to another stream with an Encoding of "UTF-7", and everything worked perfectly then.

private string GetBodyPartText(CDO.IBodyPart bodyPart)
{
    ADODB.Stream stream = bodyPart.GetDecodedContentStream();
    try
    {
        if (stream.Type != ADODB.StreamTypeEnum.adTypeText)
        {
            // This is an error,  assume a content-type of text/*
        }

        // Special-case for unicode-1-1-utf-7
        if (bodyPart.Charset.ToLower() == "unicode-1-1-utf-7")
        {
            ADODB.Stream tempStream = new ADODB.StreamClass();
            tempStream.Open(Missing.Value,
                ADODB.ConnectModeEnum.adModeUnknown,
                ADODB.StreamOpenOptionsEnum.adOpenStreamUnspecified,
                null, null);
            tempStream.Charset = "utf-7";
            tempStream.Type = ADODB.StreamTypeEnum.adTypeText;
            stream.CopyTo(tempStream, -1);
            tempStream.Position = 0;

            stream = tempStream;
        }

        return stream.ReadText((int) ADODB.StreamReadEnum.adReadAll);
    }
    finally
    {
        stream.Close();
    }
}

Let's just hope this is useful to someone else in the future!