Full Width Toolbar

As I ventured into WPF world, some things annoyed me more than others. One of those things was inability of toolbar to have no grip and to be full width.

After some time I found solution for grip problem. Just put toolbar in toolbar tray and set IsLocked attribute to true.

<ToolBarTray IsLocked="True">
    <ToolBar>
        ...
    </ToolBar>
</ToolBarTray>

Extending it’s width proved to be little bit more engaging. It took me a while to notice ActualWidth property of ToolbarTray control. As name says, it will return you actual width of ToolbarTray.

Since we want toolbar to span whole window, it should be inside DockPanel (and docked to top). Synchronizing ActualWidth of ToolbarTray and our Toolbar is then solved by simple data binding:

<DockPanel?
    <ToolBarTray IsLocked="True" DockPanel.Dock="Top">
        <ToolBar MinWidth="{Binding RelativeSource={RelativeSource AncestorType={x:Type ToolBarTray}}, Path=ActualWidth}">
            ...
        </ToolBar>
    </ToolBarTray>

    <Grid>
    </Grid>
</DockPanel>

Sample with everything done (and few things more) is here.

Got a Key?

Starcraft II has it’s release date confirmed. It will be available for general public on 27th July. Of course that probably means that I (a resident of Croatia) will not get it until some time later.

Detecting 64-Bit in .NET 4.0

In previous versions of .NET we could check whether process is 64-bit or not. It is not obvious solution - we check length of pointers.

With .NET 4.0 there are two new properties in Environment class. Is64BitProcess returns true if we are currently running in 32-bit mode. It is equivalent to our old-style check of IntPtr.Size == 4.

Is64BitOperatingSystem is something completely new. It will return true if operating system is capable of running 64-bit programs. This opens possibility of detecting 64-bit environment even if we run in 32-bits ourself. It will not be used often but it is good thing to have when e.g. running other processes.

Windows Phone Developer Tools

Some time ago Microsoft gave us CTP version (you might call it alpha) of Windows Phone development environment. Unfortunately, that version of Visual Studio 2010 Express for Windows Phone was not compatible with Visual Studio 2010 RTM.

Last days of April finally brought refreshed CTP with that particular problem solved.

Happy development.

SQL Server 2008 R2

A lot of stuff has been released this month from Microsoft. There was Visual Studio 2010, Office 2010, and now, SQL Server 2008 R2.

It is just evolution. Most of changes are directed toward big customers (e.g. support for up-to 256 logical processors) and there is little reason to upgrade if everything is working for you.

Will I upgrade? Of course I will! :)

96 DPI

Probably every programmer on this world has his image collection to use in toolbars. It is usually collected over years and gets reused quite a lot. I have collection of my own and it seemed like a natural solution to use it in WPF also.

As I am big fan of high DPI setting and I got used to expect little bit of blurriness in my toolbar as unfortunate result of scaling bitmap from 16x16 (at 96 DPI) to 20x20 (at 120 DPI). However, nothing could prepare me for amount of blur that WPF brought.

Quick search discovered a clue and look on my system confirmed it. Almost all images I had were 72 DPI. That meant WPF did scaling even on systems with “normal” DPI settings.

Scott gave easy fix in form of PNGOUT tool. I tried it out and checked results in Paint.NET. Unfortunately, instead of promised 96 DPI, I got 120 DPI images. Issue here is that PNGOUT uses DPI settings as defined on system. High-DPI setting on my system meant that PNGOUT will not work correctly without configuration change (and required logoff/logon).

Quite annoyed I made quick program in C# that just loads whatever image you give it on command line (e.g. “dpi96.exe *.png”) and changes it’s DPI setting. This finally worked as promised. This small utility is available for your use also.

P.S. Yes, I know that I should prepare separate bitmaps for all common DPI settings. I am lazy and artistically-challenged.

P.P.S. This utility was made in less than 10 minutes. Do not expect extra-quality code (or any exception handling).

The Devil Is In The Details

In quite few programs I see following pattern:

void OnMyEvent(EventArgs e) {
    if (this.MyEvent != null) {
        this.MyEvent(this, e);
    }
}

I must confess that I use same pattern in quite a few pieces of my own code. Nevertheless, this is wrong.

Issue here is that MyEvent can change between check and call statements. If change consists of adding one more delegate everything is fine. If change is removing all existing delegates you are in trouble.

Here is scenario. First line will check whether MyEvent is different than null (which it is at that point in time) and, exactly at that time, control switches to another thread and makes MyEvent null. Once our thread resumes it will use MyEvent which is now null. Exception!

This issue is highly timing sensitive and it is near impossible to reproduce it. You may have that bug for couple of years and never hit it. But it is there.

There are two distinct paths to remove this problem. One is just putting everything into lock statement. This will fix issue but it will also introduce overhead, performance problems and even potential deadlocks. It all depends on what exactly is done in called method. It is not a pattern I would be comfortable with.

Another path is to exploit fact that event delegates are immutable. Every instance has all data needed and if you copy it to local variable there is no need to worry about it changing value. With simple change we now have correct code:

void OnMyEvent(EventArgs e) {
    var ev = this.MyEvent;
    if (ev != null) {
        ev(this, e);
    }
}

10-4

Visual Studio 2010 is here!

MSDN subscribers can start download immediately while others will need to wait a little.

As soon as I download it, fate of Visual Studio 2008 is sealed. So long, and thanks for all the fish.

[2010-04-12: Express editions are available for download now.

[2010-04-12: Trial version of full Visual Studio is also available .

[2010-04-12: Unfortunately there is no Ribbon control for managed code. Big disappointment for me.

WPF in Story of Resources.

As I started to play with WPF and XAML one of first things was to get some free vector images. Those images came already formated as XAML resources:

<ResourceDictionary ...>
    <DrawingImage x:Key="Horizon_Image_Up1">
        ...
    </DrawingImage>
</ResourceDictionary>

All one needed to do was to include them as resource. I personally like to do that at application level:

<Application ...>
    <Application.Resources>
        <ResourceDictionary Source="Resources/Left1.xaml" />
        <ResourceDictionary Source="Resources/Down1.xaml" />
        <ResourceDictionary Source="Resources/Up1.xaml" />
    </Application.Resources>
</Application>

Once we do this there will be error message greeting: “Property ‘Resources’ accepts only one object.”

There are two solutions to this problem. First one is obvious - put all resources in same file. I personally tend to avoid it since I like to reuse resources in multiple projects and I hate carrying bunch of unused images.

Second solution is to merge all those dictionaries into one. Fortunately, there is simple way to do it:

<Application ...>
    <ResourceDictionary>
        <ResourceDictionary.MergedDictionaries>
            <Application.Resources>
                <ResourceDictionary Source="Resources/Left1.xaml" />
                <ResourceDictionary Source="Resources/Down1.xaml" />
                <ResourceDictionary Source="Resources/Up1.xaml" />
            </ResourceDictionary.MergedDictionaries>
        </ResourceDictionary>
    </Application.Resources>
</Application>

With that you have single dictionary consisting of all individual images. Do notice that, if there is same key defined in different files, only image that was defined last will be used.

Adventures From SVG to XAML

As huge fan of ribbon interface it was just a matter of time before I started playing with WPF flavored version. First thing that became obvious is that my standard toolbar bitmaps are not good anymore.

My default 16x16 icons looked slightly blurry on higher DPI settings when used in Windows Forms applications and I didn’t mind it much. Same icons in WPF looked just plain awful. I spent some time playing with various settings to get better results but even best settings could not hide fact that bitmaps were used. It was quite obvious that vector-based icons were what I needed.

There are some free XAML toolbar icons available but any meaningful project will have problems finding right (free) icon for the job. Since there is quite a selection of free SVG icons, thought came about converting one into another. How hard it can be to convert one vector drawing into another one.

I decided to test this on various media buttons since that was exactly what I needed for one project.

First thoughts went toward InkScape. This is great vector drawing tool with option to save files as XAML. Resulting file used canvas for positioning various elements and thus it was not possible to use it as ribbon image. Simplest solution failed me.

Another solution was exporting file in PDF and then importing that into Expression Design and exporting it as XAML. It worked. However, results were less than satisfactory. All gradients were rendered as image instead of vector. Scaling picture didn’t quite feel right.

I spent better part of night and nothing quite worked.

Best results that I got were with Svg2Xaml library. It is LGPL project in very early phase (version 0.2) of development but I do not see any alternative library that is half as good.

Examples included with that library are quite good but I decided to create another one just for fun. As always, result of that tinkering is available for download.