# ControlzEx: the shared WPF window chrome, glow and focus helpers

> ControlzEx is a MIT licensed library of WPF controls and behaviours that other desktop toolkits build on, covering custom window chrome, glow borders, focus visuals, input masks and tooltips that follow the mouse. It suits WPF developers who need those details instead of a ready made theme, and it targets .NET Framework 4.6.2 and .NET 6 and later.

**ControlzEx/ControlzEx** — Shared Controlz for WPF and ... more

- Repository: https://github.com/ControlzEx/ControlzEx
- Stars: 1,076 · Forks: 134
- Language: C#
- License: MIT
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/controlzex-controlzex

## A behaviour library for WPF, not a theme

ControlzEx describes itself as shared controls for WPF, with the header line Shared Controlz for WPF. The word shared does the work here. This is not a look and feel package, it is the layer of window chrome, focus handling and small interactive behaviours that a styling library sits on top of.

The README says it plainly at the end of the features list: most of the fixes and improvements are from MahApps.Metro and Fluent.Ribbon, and the repository topics carry mahapps and fluentribbon alongside wpf, xaml, windowchrome, tooltips, shell and icon-pack. The most substantial piece, the window chrome, came out of a real toolkit and was extracted, which tells you the code has been exercised by two shipping UI libraries rather than written for demonstration.

The target frameworks are stated in the header: .NET Framework 4.6.2 and greater, and .NET 6 and greater. The development requirements are heavier, since contributing needs the .NET SDK 10.0.100 or later and an IDE that supports it.

The project is MIT licensed, the default branch is develop, and the released versions are 7.0.4 from 2026-04-26 and 7.0.3 and 7.0.2 from 2026-01-18. The last push to the repository was on 2026-09-15, so the work on develop is ahead of the latest tag.

## WindowChromeBehavior: what the custom chrome actually does

ControlzEx provides a custom chrome for WPF windows and some deeper fixes for it. The feature list is specific enough to be useful when you are deciding whether to adopt it.

It lets you draw anywhere inside the window, including the titlebar, and it supports every WindowStyle: None, SingleBorderWindow, ThreeDBorderWindow and ToolWindow. That last point is the one that matters in practice, because a custom chrome that only works with WindowStyle None forces you to give up the native resize borders and the system behaviour that goes with them.

The chrome also supports jitter free window resizes, allows you to ignore the taskbar when the window is maximized, and provides an IsNCActive property. It mitigates a bug in Windows that causes newly shown windows to briefly be shown with a pure white background, which is the kind of detail that only shows up in an application with many windows opening at once.

Taken together, these are the parts of a window that an application author would otherwise have to reimplement, and reimplement badly. That is the case for the library: not that any single item is hard, but that there are a dozen of them and they interact with native window behaviour in ways that are easy to get subtly wrong.

## Windows 11 support: rounded corners, snap menu and the DWM border

The Windows 11 additions are the part of the library that has to be rewritten every time the operating system changes, and it is the part most likely to make you upgrade.

The chrome allows you to control rounded corners through CornerPreference, and it supports the snap menu on window buttons through attached properties such as NonClientControlProperties.HitTestResult and NonClientControlProperties.ClickStrategy. Snap layouts are a Windows 11 feature where hovering a maximize button offers a set of layouts, and without the attached properties the custom chrome either swallows the hover or passes it through to a window that no longer exists.

The GlowWindowBehavior adds a glow around your window, and on Windows 11 the behaviour can be used to control the colour of the native window border, and does so automatically when Windows 11 is detected. The switch to turn that off is PreferDWMBorder set to false.

That conditional is worth understanding. On Windows 11 the border is a native, compositor drawn element, so the library sets its colour to match the theme rather than drawing its own. On older systems the glow is drawn by the library. The two paths look the same to the user and are implemented completely differently.

For a team shipping a WPF client to Windows 11 users, this is the section that decides whether the library is worth taking.

## KeyboardNavigationEx: the focus visual on a mouse click

KeyboardNavigationEx is described as a helper class for a common focusing problem, and the problem is stated precisely.

The focus of a UI element itself is not the issue. When you use the common focusing methods, the control gets the focus, but it does not get the focus visual style, so there is no visible rectangle around it.

The reason is in the original KeyboardNavigation class, which handles the visual style only if the control gets the focus from a keyboard device, or if SystemParameters.KeyboardCues is true. A user who clicked with the mouse gets a focused control with no visible indication.

KeyboardNavigationEx fixes this in two ways. In code behind, you call the helper on the element that should get the focus, typically in the window's Loaded handler.

```csharp
public partial class MainWindow : Window
{
    public MainWindow()
    {
        InitializeComponent();
        this.Loaded += (s, e) => { KeyboardNavigationEx.Focus(this.TheElementWhichShouldGetTheFocus); };
    }
}
```

Or in XAML, with an attached property on the control that always shows the focus visual, which is the approach for a control that can be reached by a mouse click.

```xml
<Button controlzex:KeyboardNavigationEx.AlwaysShowFocusVisual="True">Hey, I get the focus visual style on mouse click!</Button>
```

This is a small feature and it is the kind of small feature that separates a desktop application that feels native from one that does not.

## TextBoxInputMaskBehavior is a mask, not a validator

The TextBoxInputMaskBehavior shows a mask inside a TextBox, and the README attaches a warning that matters more than the feature description: it is only a mask and does not validate your text.

The usage is a behaviour attached to a TextBox through the interaction behaviours collection, with an InputMask string and an optional PromptChar.

```xml
<TextBox Grid.Row="0"
         Grid.Column="1"
         Margin="4">
    <behaviors:Interaction.Behaviors>
        <controlzEx:TextBoxInputMaskBehavior InputMask="00/00/0000" />
    </behaviors:Interaction.Behaviors>
</TextBox>
```

A second example shows the phone number mask with a prompt character, where the mask reads ( 999 ) 000 000 - 00 and PromptChar is set to underscore, so unfilled positions show a placeholder rather than a space.

The distinction between masking and validating is the part to hold on to. A mask shapes what the user types as they type it, and a validator decides whether the final value is acceptable. A masked field can still contain text that does not correspond to a real date or a real phone number, so a form that needs real validation has to do that separately. The behaviour is credited to a blog series by Blindmeis, and the original posts are linked from the README.

The other small behaviour in the library is ToolTipAssist.AutoMove, which makes a tooltip follow the mouse, with a custom template in the example so the tooltip is a designed surface rather than the default rectangle.

## The build machinery: Cake, GitVersion and AppVeyor

The repository layout shows how a library with this many supported frameworks is put together.

There is a build.cake file with cake.config, a Build.ps1 script for running the build on Windows, GitVersion.yml for version calculation and GitReleaseManager.yaml for driving releases, a global.json pinning the SDK, NuGet.Config for package sources, and appveyor.yml for continuous integration. The Changelog.md is the history of changes that the README points to, and the roadmap is tracked through GitHub milestones.

The build is driven by Cake, which is why a PowerShell script and a cake script both exist: the PowerShell entry point is the local convenience, and the Cake script holds the actual logic so the same steps run locally and on the build server.

The XamlStyler directory is the other interesting entry. It is a formatting tool for XAML files, checked into the repository, which tells you that the project treats XAML formatting as part of the build rather than as a matter of each contributor's editor settings. For a repository where a large part of the code is markup, that is the difference between a consistent codebase and a diff full of whitespace.

The Wiki directory is where the longer documentation lives, since the README is deliberately a set of feature examples rather than a manual.

## Conclusion

Adopt ControlzEx if you build WPF applications and need a custom window chrome with Windows 11 aware rounded corners and snap layouts, or if you are writing a control toolkit of your own and want the behaviour layer that MahApps.Metro and Fluent.Ribbon already use. Do not adopt it as a styling library, because it ships behaviours and chrome rather than a visual theme. Before you upgrade, check the target frameworks against your own, since it supports .NET Framework 4.6.2 and later alongside .NET 6 and later, and note that building it from source needs the .NET SDK 10.0.100 or later.

## FAQ

### Which target frameworks does ControlzEx support?

The project header states that it supports .NET Framework 4.6.2 and greater and .NET 6 and greater. Building it from source has a higher requirement, the .NET SDK 10.0.100 or later, plus an IDE that supports that SDK.

### Does the ControlzEx window chrome work with every WindowStyle?

The README lists support for every WindowStyle, namely None, SingleBorderWindow, ThreeDBorderWindow and ToolWindow, along with jitter free window resizes, ignoring the taskbar when maximized, an IsNCActive property and a mitigation for the white background bug on newly shown windows.

### How do I get the focus visual when a WPF control is clicked with the mouse?

Use KeyboardNavigationEx. In code behind, call KeyboardNavigationEx.Focus on the element in the window's Loaded handler, or in XAML set the attached property AlwaysShowFocusVisual to True on the control, since the original KeyboardNavigation class only shows the focus visual for keyboard focus or when SystemParameters.KeyboardCues is true.

### Does TextBoxInputMaskBehavior validate the entered text?

No. The README states that it is only a mask and does not validate your text. The behaviour shapes the input while it is typed, using an InputMask string and an optional PromptChar, and validation remains a separate concern.

## Sources

- [ControlzEx/ControlzEx on GitHub](https://github.com/ControlzEx/ControlzEx)
- [Issues](https://github.com/ControlzEx/ControlzEx/issues)
- [License: MIT](https://github.com/ControlzEx/ControlzEx/blob/develop/LICENSE)
- [README](https://github.com/ControlzEx/ControlzEx/blob/develop/README.md)
- [Releases](https://github.com/ControlzEx/ControlzEx/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/controlzex-controlzex