I Got Rhythm

C# Partial Specialization With Extension Methods

One of the things C# generics lacks (compared to C++ templates) is specialization (neither explicit nor partial). This can be very useful in some cases where you want to perform something differently for a specific T in a Class<T>.

With C# 3.0, there is a relatively easy way to achieve this, albeit not optimal, for reasons I'll specify later on. Take a look at the following piece of code:

    public class SomeClass<T>

    {

        private readonly List<T> items = new List<T>();

        internal void AddInternal(T item)

        {

            items.Add(item);

        }

    }

    [EditorBrowsable(EditorBrowsableState.Never)]

    public static class SomeClassExtensions

    {

        public static void Add<T>(this SomeClass<T> c, T item)

        {

            c.AddInternal(item);

        }

        public static void Add(this SomeClass<int> c, int item)

        {

            if (item <= 0)

            {

                throw new ArgumentOutOfRangeException("item", "Value must be a positive integer.");

            }

            Add<int>(c, item);

        }

    }

Instead of placing the Add method in SomeClass<T>, we put it in a static class that has extension methods. This allows the compiler to select the appropriate method according to the type parameter. (Side note: I've specified the EditorBrowsable attribute so that the class with the extensions would not appear in VS intellisense.)

The biggest caveat about this is that extension methods do no have access to private members, so the only option is to make the members internal, which, in many cases, leads to a bad design. If only extension method classes could be written as inner classes...

Also, extension methods, being static, could not be virtualized. You can, however, make the internal method "protected internal virtual".

Vista Fish

About a month ago I went on a trip to London. I just got to uploading the photo album.

One of the places we visited there was the London Aquarium. I took a photo of some glass catfish, which reminded me of Windows Vista:

The WPF Contrib Project

I've been quiet for a while. Working a lot, and also burning the midnight oil, trying to bring life into this project I call... the WPF Contrib.

Set up at CodePlex, WPF Contrib is mainly a library of reusable components. My goal is for it to become a true community project. Meanwhile, I invite everyone to review the code, play with the demos and send me feedback! If you want to join, the doors are open. You only need to be a WPF expert :P and have motivation to innovate and share.

I'd also love to hear about what you would like to see in this library. You can use the CodePlex Issue Tracker to request features (or just email me).

The latest addition to the library (and one of my favorites) is the TaskDialog control. I've been wanting to write it for some time now. Using it, you can create Task Dialogs in every WPF-supported platform. They help make a very good UX.

Ælij.

Yet Another Upgrade

I've upgraded to Community Server 2007. Unfortunately, the entire theme model is changed, though for the better, I don't have the time to update my Aero theme, so I chose Kid Congo right now. The main reason for upgrading is the built-in FeedBurner support. It's an excellent service that gives you a bit more information about your readers.

I love getting responses, so don't be afraid to drop me a line if you got the time. :-) BTW, it seems there was some problem with the mail settings on the server, so if you did try the contact form and never got a reply, I'm sorry. You can also reach me at aelija via gmail.

New York, New York!

I've recently visited New York City for the first time. I had an awesome trip; strolling around in the streets, visiting museums and checking out the gay scene. I did not get to see Lady Liberty, because as it turned out, you have to pre-register to get inside her.

I took a few photos. The worst thing about traveling alone is that you're dependent on strangers' graces to get yourself photographed. :) But it wasn't that bad, and people have been very nice. I uploaded the entire album:

http://picasaweb.google.com/aelija/NewYorkCity/

The trip was my "between-jobs-vacation". I don't think I ever mentioned it on the blog, but I used to work for Amdocs. After almost three good years, I've decided a change pace was in order, and so I moved to a startup company named Varonis.

Lastly, I know I don't normally write about personal stuff on the blog. That's mostly because I don't have anything interesting to report, and also because this blog has a more technological nature. I'll consider opening a second blog, should the situation merit it. The inspiration for this came from Kevin Moore, when I recently saw his "2006 Year in Review". He sure got a lot done that year. :-) Kevin is a program manager on the WPF team (and if you're a WPF developer you should subscribe to his work blog.) For the time being I'll just add the tag "personal" to posts of this nature.

Trace (route) that call!

Have you ever used EventManager.RegisterClassHandler()? If so, make sure you know what you're doing. This method allows you to listen to events passing through (as I like to put it) an element (i.e. bubbling or tunneling), regardless of the class that invoked the call. Most of the times you would call it in a static constructor, and pass it a typeof of that class, but that is only a recommendation. The documentation is a bit weak on this point.

This can be a very powerful tool if you use it right. Let me demonstrate. Say you want to listen to all button clicks in your app. Normally you would put this in your main Window (by calling the above method or UIElement.AddHandler() instance method) so all the ButtonBase.Click event would bubble up to the Window and get caught.

But what you can actually do is call the RegisterClassHandler from anywhere you like (it doesn't have to be a static constructor or even a DependencyObject. But remember that every call would add a handler, so beware of multiple registrations!):

EventManager.RegisterClassHandler(typeof(ButtonBase), ButtonBase.ClickEvent, new RoutedEventHandler(SomeMethod), true);

This method has no idea from where it's called, nor does it care. All that matters is that the bubbling or tunneling passes through an element of the type you specified.

Since the Click event would always pass through a ButtonBase (well, actually originate from one. That is, unless you invoke it from some custom class, which doesn't make too much sense most of the time. But I'm going off on a tangent here.) the method would be invoke for every button click. The last parameter makes sure it's invoked even if you marked the event as handled somewhere along the way (albeit redundant in this case, since we handle it right at the root of the bubble.)

[This post was brought to you by Marjorie Dawes. Dust, anybody, no? :-]

i'm (making a difference)

Microsoft has started a new program to donate some of Messenger's ad revenue to various organizations dedicated to social causes. Join by clicking the banner on the left. You don't have to do a lot to make a difference. :-)

 (I chose UNICEF.)

Dispatch It

In WPF, like most UI frameworks, UI elements can only be updated from the thread they were created on. If you do background work, and want to affect the UI from a different thread, you'll have to dispatch it. The Dispatcher class has a CheckAccess() method (which is marked as EditorBrowsableState.Never, making it invisible to intellisense for some reason.)

Here's how you would normally use it:

delegate void CallMeDelegate(Button b);

void CallMe(Button b)
{
    if (!Dispatcher.CheckAccess())
    {
        Dispatcher.Invoke(DispatcherPriority.Normal, new CallMeDelegate(CallMe), b);
        return;
    }

    b.Foreground = Brushes.Red;
}

You have to create a delegate, check for access and dispach if necessary. However, there's a smarter way, if you allow for a bit of Reflection:

void CallMe(Button b)
{
    if (UIHelper.EnsureAccess(MethodBase.GetCurrentMethod(), this, b))
    {
        b.Foreground = Brushes.Red;
    }
}

What MethodBase.GetCurrentMethod() does is actually give you a method descriptor of the calling method (quite useful for a few scenarios! Too bad they don't have a GetCallerMethod() as well...) The EnsureAccess() method then checks with the dispatcher if we're on the right thread, and if not, dynamically dispatches it.

Last note: Dispatchers run a prioritized queue, so it can be handy to set the DispatcherPriority to something other than Normal. For example, if you set a Dependency Property's value, and want to do something after the UI was updated, try dispatching it with ContextIdle priority.

For more information about Dispatchers, you should read Nick Kramer's whitepaper.

Update: I also discovered the existence of the DispatcherSynchronizationContext, which inherits from the good old SynchronizationContext of .NET 2.0. The original one uses ThreadPool to queue items, while the WPF one uses the Dispatcher mechanism, which is more suitable for WPF. Note that this way you cannot specify a priority. I still believe the way I described above is slightly better.

Another Update: I've changed a few things in the implementation. Now it checks whether the object it receives is a DispatcherObject, and if so, uses its Dispatcher instead of the Application's. This is good for (the rare) cases where your UI itself runs in more than one thread.

BitmapEffect Begone

You can do really neat things with Bitmap Effects in WPF. Shadow, Bevel, Outer Glow can all have a great impact on how your application looks. But you should be aware that they don't come cheap. They are rendered in software, which yields very poor performance. Also, ClearType is turned off on elements that have them applied, so your text becomes blurry.

So, what to do?

• Abstinence. Now, I'm not really a prude, but in this case, minimizing the use of bitmap effects can significantly improve performance.
• Apply only on simple Visuals. Probably the most important advice here. If you want to apply an effect on a complex Visual, use layers! Apply the BitmapEffect on a simple Shape (e.g. Rectangle, Path), and use a Grid, for example, to position it below your complex Visual. Do not apply the effect on a Decorator (such as a Border) that contains your Visual, since that will cause the entire visual tree to suffer from the effect.
• Avoid Animations. Especially on large Visuals, avoid animating the BitmapEffect's properties, and animating elements that have effects applied on them. TextBoxes, for example, animate the cursor frequently when they are focused, so if an element that has an effect contains a TextBox, it is forced to render itself entirely every blink.
• Use Bitmaps. Yes, it's true bitmaps don't scale like vectors, but in some places they are a very viable alternative.
• 
  How nine-grid images work
  Use Nine-Grid Images. Have you ever wondered how the themes on XP and Vista work? You can stretch a button as much as you like and it still looks good. They use nine grid images. The idea is very simple: divide the image to nine areas and stretch it as shown in the illustration. The effect is that the proportions of the corners and borders are always maintained. I've attached a project with a NineGridBorder class that can be used to draw these images. After I wrote it, I discovered another implementation, so I took the best of both of them. 
• Vectorize. When exporting from Expression Design to XAML, you have the option to either rasterize (i.e. create a bitmap) or vectorize some of the effects. For example, when applying soft edges to a vector drawing, ED exporter will create a Canvas that contains a few layers with different opacities, which will simulate the effect.
• Use WpfPerf. This is a great tool that comes with the Windows SDK. You can use Perforator to detect whether your careless colleagues used BitmapEffects or other ill-advised features that may hinder your application's performance. Check "Draw software rendering with purple tint" to immediately view what causes problems. Try to resize the window or run animations while this is checked.

Give me back my ClearType

WPF has a separate ClearType rendering system, which is better than GDI's (mostly because it also does y-direction antialiasing; read more here and in the WPF Text Blog.)

However, there are some situations in which WPF cannot use ClearType, and has to resort to grayscale antialiasing (it cannot render aliased text because of its pixel independent architecture) which comes out pretty blurry for small text sizes, in my opinion.

Here's when WPF can't use ClearType:

• Window/Popup AllowsTransparency = true. This creates an HwndSource with UsesPerPixelOpacity = true (i.e. a layered window.) All context menus and tooltips in WPF have this turned on with no trivial way of turning it off. More on this later on.
• Visual (or some ancestor) has a Bitmap Effect. (Sidebar: You should really avoid using those on any complex Visual. They yield the worse performance. If you want a shadow under something, take an empty Rectangle or some other Shape, apply the effect on it and put it under the more complex Visual.)
• Text from another Visual appearing in a VisualBrush.
• Rendering a Visual using RenderTargetBitmap.
• Setting the HwndTarget.BackgroundColor to Transparent (needed for extending DWM glass to client area.)

Also, there are registry settings that can enable, disable or configure ClearType, both system-wide and WPF-specific.

In Vista, ClearType is turned on by default, so WPF also uses it. In XP, however, it is not. And so by default WPF is rendering grayscaled text. From my experience, ClearType is better even on CRT monitors, so when I write WPF applications, if ClearType is off, I display a message recommending to turn it on, and make the WPF-specific registry changes.

Now, for my woes. Take a look at these screenshots:

The left one is with ClearType, the right one without. I hope the difference is clear. As I mentioned earlier, context menus, tooltips and combo box use the Popup class, which has the AllowsTransparancy set to true. This is hardcoded. The reason for this is obvious: the designers of WPF wanted you to be able to customize these windows as you saw fit. And it can truly be used to do wonderful things (see this styled tooltips example. Quite effortless, if you consider what you had to do to get this done in Win32.) But I think readability is more important in these cases. At any rate, this should be configurable.

Aside from the text issues, layered windows' performance is much worse than normal windows. Even under Vista, where they are hardware-accelerated, the menu highlight is lagging after the mouse sometimes.

Frustrated a bit, I came up with a somewhat dubious solution to these issues.

For ComboBoxes and MenuItems, I created an attached Dependency Property, which, when attached to a control, attempts to find the "PART_Popup" in its template and set its AllowsTransparency property to false. Caveats:

• You lose the animation when opening a combo box (slide) or a menu (fade).
• You lose the shadow.
• If you apply a transform, the popup will not match it (Then again, who would want a skewed combo box? But a rotated menu might be useful.)

For ContextMenus and ToolTips, I create subclasses, overrode IsOpenProperty metadata and added an additional changed handler. The Framework Property Metadata documentation states that:

The actual property system behavior for PropertyChangedCallback is that implementations for all metadata owners in the hierarchy are retained and added to a table, with order of execution by the property system being that the most derived class's callbacks are invoked first. Inherited callbacks run only once, counting as being owned by the class that placed them in metadata.

Either I don't understand it well or the documentation is wrong, since the method I specified ran after the original method. To solve that, I wrote a class that inherits FrameworkPropertyMetadata and reverses the execution order, so I could create the Popup myself without setting the AllowsTransparency to true. Caveats:

• I use reflection to get to private fields. Yes, I know it's bad... :P
• Again, you lose shadows and animations.
• Tooltips have rounded corners by default (at least on Vista) so you'll see gray 1-pixel dots on the corners. But you can change the tooltip's default style to get rid of this.

I tried to regain the shadows using cheaper means (CS_DROPSHADOW window class style) but it's difficult to reach.

You may think I'm crazy to go through all of that just for a few blurry texts, but I think this really impacts the overall readability of my applications.

Anonymous Comments Enabled

I didn't notice that when I set up the blog, anonymous comments were disabled!

I just enabled them, and I hope this won't lead to a spam attack. Maybe I should add a captcha, though I don't care much for that method.

Anyway, now you can feel free to comment on my posts. :P

Update: Comment spam was unbearable... Added this captcha. Still have hundreds of junk comments to delete :-|

I Got Rhythm Now Available in XBAP!

This is not quite ready, but I just had to give you a sneak peek:

http://arbel.net/blogx/blog.xbap

I believe this is the first blog presented in XBAP. The possibilities are endless... The tag cloud uses Kevin Moore's Bag-O-Tricks. The HTML is being rendered by a modified version of the Windows SDK Team's HTML to Flow Document converter.

I've written a Community Server web service that allows me to pull all the data and bind to it.

Note that this was compiled in RC1 (waiting for Vista RTM in MSDN) but it seems to work on .NET 3.0 RTM.

Monopolij: Avalon* Edition

First - great news. .NET Framework 3.0 has finally been released. Get it now!

Monopolij was an app I wrote trying to win a free ticket to PDC'05 (you can download it at that post.) It had a special theme, as you can see in the screenshot... I thought it was a lot of fun to play as Bill. :-)

So, I've decided to migrate this game to .NET 3.0. It's proving to be quite interesting. I'm going to use WCF for communication (the original version used TcpClient, so there's much work to be done.) This will also enable me to try the peer to peer binding for the first time. Automatic peer discovery is kinda cool.

I'll also add different themes, animations and all sorts of WPF pyrotechnics we all love so much.

If anyone has any feature requests, I'll be happy to hear them.

* Avalon was WPF's codename. I'm just being nostalgic... And you have to admit it's a cooler name.

Revamped Style Snooper

Update: This utility has become a bit irrelevant since Reflector now has a BAML Viewer add-in. You can use it to view any assembly containing BAML resources, which it will automatically decompile into XAML.

Style Snooper (or StyleSnooper?), originally posted by Lester, is a tool that can extract control styles from a compiled assembly. Quite useful to take a peek at someone else's work. :-)

I added a couple of features:

• Switch to a FlowDocumentScrollViewer to view the style (much handier than a plain old TextBox; just try hitting Ctrl+F.)
• Primitive syntax-coloring.
• A bit of glass.
• And the feature that made me start tinkering with this tool to begin with – load other assemblies.
• I also fixed the TargetType property to use the proper Type MarkupExtension ({x:Type …}) and removed the IsPublic restriction from the type list.

P.S. If you're wondering about my wallpaper, it's "Song of the Sky" from Digital Blasphemy. It used to be in the free gallery, but isn't anymore. It's very reminiscent of Vista's Aurora.

Forcing WPF to use a specific Windows theme

WPF comes with a few theme assemblies, one for each Windows theme (Luna, Royale and Aero and the fallback theme, Classic.) Usually the theme is loaded according to your current system theme, but if you want to create a consistent look for your application, you may want to force-load a specific one.

To accomplish that, simply add the following code in your Application Startup event (this example shows how to use the Aero theme):

Uri uri = new Uri("PresentationFramework.Aero;V3.0.0.0;31bf3856ad364e35;component\\themes/aero.normalcolor.xaml", UriKind.Relative);

Resources.MergedDictionaries.Add(Application.LoadComponent(uri) as ResourceDictionary);

It's important to specify the version and the public key token. Otherwise you'll have to copy the theme assembly to the folder of your executable. The reason I'm adding it to the merged dictionaries collection is that I don't want to lose other resources I added to the App.xaml file.

I usually put this code in a try…catch block (with an empty catch) since it doesn't really impair the application's functionality if it fails to execute.

Last note: From my experience, Windows Server 2003 always shows the Classic theme in WPF (even if you activate the Windows Themes service), so if you're deploying applications for that platform, you may want to use this trick (you will also want to turn on your display adapter's hardware acceleration and the DirectX accelerations, as they are disabled by default in 2003.)

Edit: Robby Ingebretsen (notstatic.com) also blogged about this because the new Zune theme, which caused WPF to fallback to the Classic theme. However, he placed the code in XAML. Here is a version of that using merged dictionaries (which will allow you to add other resources to App.xaml):