The first one I figured out by looking at some C# code here. The idea is to use a FormatConvertedBitmap to convert the original image to grayscale. This works, but then kills the alpha channel so your transparent PNGs aren’t transparent anymore. Thus, I also use the OpaqueMask property of Image set to an ImageBrush based on the original image. It’s nasty, complicated, and (probably, in a real app) slow. Here’s the markup:

<TextBlock>
    This is a grayed Image loaded from a BitmapImage, with an opacity mask :
    <Button IsEnabled="false">
    <Image Height="16">
        <Image.Source>
            <FormatConvertedBitmap DestinationFormat="Gray32Float">
                <FormatConvertedBitmap.Source>
                    <BitmapImage UriSource="Images\OutdentHS.png" />
                </FormatConvertedBitmap.Source>
            </FormatConvertedBitmap>
        </Image.Source>
        <Image.OpacityMask>
            <ImageBrush>
                <ImageBrush.ImageSource>
                    <BitmapImage UriSource="Images\OutdentHS.png" />
                </ImageBrush.ImageSource>
            </ImageBrush>
        </Image.OpacityMask>
    </Image>
    </Button>
</TextBlock>

As you can see, the original image is read into FormatConvertedBitmap, which is used to convert to Gray32Float (Gray8 is probably better), and used as the Source of an Image. The Image‘s OpaqueMask is set to the original image via an ImageBrush. As you test this out, don’t use Expression Blend; the designer view renders the grayscale Image elements as blank, even though in IE or a desktop XAML app it looks fine.

I also have NFI how this solution could be generalized into a style so you don’t have to repeat this for every button. Obviously the original image and grayscale version could be expressed as resources (I did it my way for clarity), but it’s a long way from there to a trigger based on IsEnabled that replaces an image with a grayscale version of itself.

That leads me to the other solution, which blows but is workable. I found that here. The idea is that you don’t grayscale the image at all; you lower its opacity so it looks more faded, and in the case of a gray control background, grayed out. This happens to be easily expressed as a style, like so:

<Window.Resources>
    <!-- El Cheapo hack to make images within disabled toolbar buttons appear 'grayed out'.  This doesn't
    gray them at all, but lowers their opacity so the (usually gray) background of the button shows through.
    If WPF had a built-in facility for grayscaling images in disabled buttons, this kind of icky kludgery wouldn't
    be necessary -->
    <Style TargetType="{x:Type Image}" x:Key="toolbarImageStyle">
        <Style.Triggers>
            <DataTrigger Binding="{Binding RelativeSource={RelativeSource AncestorType={x:Type Button}, AncestorLevel=1}, Path=IsEnabled}" Value="False">
                <Setter Property="Opacity" Value="0.50"></Setter>
            </DataTrigger>
        </Style.Triggers>
    </Style>
</Window.Resources>

Any Images contained within a button and with Style set to toolbarImageStyle will have their opacity adjusted to 50% when the button is disabled. The original post called for an opacity of 25%, but that was too faded in my opinion. Adjust the value to taste, but don’t expect to exactly duplicate the true grayscale effect; colors are still visible in the buttons, they just look a bit faded.

So, there you have it. I’m going with the latter solution since it’s easily workable and almost right, but I’m still fuming over WPF’s inability to handle a feature that MFC has had for the duration of my programming career. Pretty soon I’ll be like those old mainframe curmudgeons who bitch about C++ and insist C and 64K of RAM is all anyone ever needed. Then I’ll know it’s time to quit the software industry and go into yoga instruction full time.

Anyway, I wanted to get a quick hit this weekend to keep momentum going, so I thought I’d put together the rich text interface of the project first. This should be stupid-easy, since WPF contains a RichTextBox class that does everything you could ask for with rich text, and the underlying content model is itself a XAML document, a FlowDocument. Too easy.

Unfortunately, RichTextBox doesn’t ship with the standard rich text toolbar, for doing things like bold, italics, etc. No problem; WPF has a toolbar element too. I wired up a bunch of buttons, each using the standard icon for its corresponding function, and set the buttons to invoke WPF commands like EditingCommands.ToggleBold, which the rich text box knows how to handle. “Wow”, I thought to myself, “this WPF thing isn’t half bad!”.

Then I noticed something. When commands are disabled (for example, the ‘Cut’ command is disabled when there’s nothing to cut), the toolbar button doesn’t respond to mouseovers or clicks just like a disabled button wouldn’t, but the icon on the button isn’t grayed out like one would expect. Then I tried something simpler; I created a Button with an Image in it, and explicitly set the Button‘s IsEnabled property to false. Sure enough, the image was still not grayed out.

Then I used Microsoft Expression Blend (a tool about which I could write a whole stream of angry rants) to show me the built-in XAML template for the Button control. Imagine my surprise when I discovered the only logic in the template that deals with rendering the disabled button is setting the foreground color to gray. That’s _it_. No wonder, then, that my images weren’t rendering differently; the foreground color has no effect on images.

You can see for yourself. Type this XAML code into XamlPad and see what happens:

<Page xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <StackPanel HorizontalAlignment="Left">
        <Button>
            <TextBlock>This button is enabled
                <Image Source="http://apocryph.org/themes/apocryph/logo.png" Width="32" />
            </TextBlock>
        </Button>
        <Button IsEnabled="false">
            <TextBlock>This button is disabled
                <Image Source="http://apocryph.org/themes/apocryph/logo.png" Width="32" />
            </TextBlock>
        </Button>
    </StackPanel>
</Page>

You’ll see two buttons, one with grayed-out text, but both with the same fucking image.

So let’s ponder this a moment. Back in 1995, I got my first copy of Visual C++ for free from a guy named Mike Strock (this was back when companies sold compilers for an outrageous sum, and thus I couldn’t afford them). One of the kickass features that blew me away was the MFC document/view model, where toolbar buttons mapped to commands, and would automatically disable themselves if the commands were disabled. Somehow, MFC automatically grayed out the toolbar button icons as well. It was incredible. “Surely”, I thought, “programming can’t get any easier than this”.

Apparently, I was right, coz here we are, 12 long years later, and we’ve taken a huge fucking step backwards. Now, don’t get me wrong. Using WPF I can easily make a button which contains a spinning 3D cube playing videos on each face that turns green when the mouse goes over it, all without any C# code. Unfortunately, no one would ever want to do that, while it’s easy to imagine a situation wherein you’d want toolbar icons to gray themselves (like, I dunno, every Windows application ever made).

This gives me a great startup idea. I’ll found a company in some tort-free jurisdiction like Costa Rica, called “FuckIt, Inc”. We’d offer an exclusive “Fuck This Shit(tm)” package, wherein programmers who can no longer bear the absurdity and kludge which is modern software engineering would be cryogenically frozen in a bunker on a secret island off the coast, to be revived 100 years hence or when the software industry gets its head out of its ass, whichever comes first. One of the test cases used to determine if the industry has its head out of its ass yet would be this one:

Using the latest development tools from the vendor of the most popular desktop operating system on the planet, is it easier to create toolbar buttons with icons that automatically disable themselves when the action they correspond to is disable, or to create a huge button containing a spinning 3D cube with video playing on each face? If the answer is the latter, as it is today, then the programmers stay frozen.

UPDATE: I’ve got a couple of solutions, here. Neither of them are optimal, but then, neither is life itself.