A recent project has me using the excellent MahApps.Metro control library to give my app a Metro (or is that Modern?) look and feel.

Since the Metro library pushes WPF a little hard, there are inevitably going to be some problems that will occur when you’re trying to make field-expedient tactical modifications (see also “hacks”). Here are some of the problems I’ve encountered, and some fixes for them where possible.

I’ll edit this article as new things are discovered, so check back for updates.

##Applying behaviors to a window breaks the window chrome Since MahApps.Metro implements its window chrome with BorderlessWindowBehavior, changing the Behaviors collection in XAML will overwrite the existing behaviors in use and put the system chrome around the Metro style chrome.

To work around this, just re-add the BorderlessWindowBehavior:

xmlns:MetroBehaviors="clr-namespace:MahApps.Metro.Behaviours;assembly=MahApps.Metro"
...
<i:Interaction.Behaviors>
    <MetroBehaviors:BorderlessWindowBehavior/>
    <me:MyAwesomeCustomWindowBehavior Awesomeness="True"/>
</i:Interaction.Behaviors>

If you are using shadows, you should also add the GlowWindowBehavior. The WindowsSettingBehavior is also nice (for saving window positions between sessions). I’m not sure if there’s a better way to just ‘append’ to the Behaviors collection instead of overwriting it in the XAML.

##Flyouts interfere with Windows Forms controls This is a well known issue with WPF, known as the “Airspace” problem. MahApps documents it in their FAQ.

The first piece of advice, regarding AllowsTransparency, is no longer possible in later versions of MahApps.Metro. A reading of the MahApps code reveals that this workaround is already present on my version of the code, but does not appear to function.

I’ve had some success working around it using Dwayne Need’s Airspace decorator, found on his Codeplex page. Simply wrap your Windows Forms controls in it, and the Flyouts will no longer interfere.

The Airspace decorator has some issues when redirecting Windows Forms controls on high-DPI monitors, which I am having limited success fixing in my fork of his libraries.

##Changing styles of elements generated by Templates is impossible This isn’t a MahApps.Metro specific issue by any means, but it seems poorly understood in the WPF community.

Most of the MahApps styles employ heavy use of templates, and you may find it difficult or impossible to change these values unless they are exposed via dependency properties, which can’t possibly accommodate all possible situations.

For now, I have been copying the files defining those styles out of the MahApps github repository, making the necessary alterations, and using those styles rather than the stock ones.

If you’re doing this on a long term project and wish to keep up with changes as MahApps.Metro is updated, this is not a great choice. You may wish to only override some portions of the templates, or (ideally) contribute patches to MahApps.Metro that expose the properties you desire.