.NETpad 2025: Preventing Custom Dialog Resizing (Premium)

Preventing custom dialog resizing

Taking another break from the multiple tabs support, here’s a quick and dirty fix for a problem with the current .NETpad version: You can resize the custom dialog boxes.

When I created the new custom dialogs for this version of the app, I was really happy with them. They look and feel native. And, as importantly, they closely emulate how similar dialogs look in Notepad. I later implemented a custom MessageBox using the same code.

xThe problem is that they’re resizable. That’s not on me: This is a problem with WPF and its buggy and incomplete support for Windows 11 theming. You can, of course, specify that any window be non-resizable, in WPF, you do so setting the Resize property on the window to NoResize. So why don’t I just do that?

Remember that I’m matching the look and feel of the similar dialogs used by Notepad. Those dialogs are modern, so they don’t display an old-school title bar with the associated buttons. If I leave off the WindowStyle change noted below, those controls are all visible (and usable).

To prevent this, I customize these dialogs just like I customize the main app window. But to get the look I need, I have to set Resize to CanResize and I have to set WindowStyle property to None. It’s the combination of these two things and WPF’s inelegant support for Windows 11 styling issues that makes this is a non-starter.

This kind of problem comes up a lot, but WPF was created in a different era and much of it hasn’t been updated to account for modern Windows and app behaviors. In this case, Microsoft updated WPF for Windows 11 theming, but not completely. A non-resizable window should simply be non-resizable. Making this one change shouldn’t impact the window border, corners, or its ability to display a drop shadow. If anything, those properties should all be individually configurable.

Well, they’re not. So the custom dialogs in the current version of the app (.NETpad 3.0 for Windows 11) look right. But they are resizable. If the user moves the mouse cursor over a window edge, it changes into the resize cursor.

And you can literally resize that window in any direction (including diagonally). No bueno.

This is one of those issues I know is fixable: WPF supports low-level integration with Win32 APIs related to windows and mouse cursors, and I’ve seen inelegant, code-heavy solutions to the problem online. Which is, in a way, two problems: The mouse cursor changes when it’s over a window edge and then the window is literally resizable.

In time, I may fully solve this problem using Win32 interoperability code. But I would like to avoid that, in part because I have a vague hope, probably unfounded, that this and other WPF/Windows 11 theming issues will be solved in time, perhaps in .NET 10 this year. So I have instead come up with an interim solution that partially solves the problem.

Preventing a window from being resized is simple: All you have to do (in WPF) is set the minimum and maximum widths and heights of the window to the current width and height using the MinWidth, MinHeight, MaxWidth, and MaxHeight properties, respectively. If this was a static window, I could do that in XAML. But because the width and height are dynamic, and each is based on the document name that’s passed to it when it’s created, I have to do this in C# code at runtime. Every custom dialog is, well, custom. And among the ways each is unique is its width and height.

The obvious place for this code is in the body of the Window_Loaded event handler. In the app version that’s now published to GitHub, this method currently does one thing: It makes sure the default button is focused when the window loads. Here’s the version in ConfirmationDialog.xaml.cs.

To prevent this window from being resized, all I had to do was added four lines of code.

this.MinWidth = this.Width;
this.MinHeight = this.Height;
this.MaxWidth = this.Width;
this.MaxHeight = this.Height;

And now it looks like so.

I had to make the same change in the Window_Loaded for each custom dialog, so AutoSaveDialog.xaml.cs, GoToLineDialog.xaml.cs, and MessageBoxDialog.xaml.cs in addition to ConfirmationDialog.xaml.cs.

Now, when I run the app, these dialogs are no longer resizable, which is ideal. The problem–and it’s a minor one, though still a problem–is that the mouse cursor changes to the resize cursor when you mouse over a window edge, just like before. The difference is that resizing does not work. You can’t resize them.

It’s not ideal, but I can live with this. That said, I will reexamine this in the future–I often need breaks from the more difficult work around implementing tabs, multiple documents, and session state–and see whether it makes sense to address the mouse cursor issue too.

For now, I’m moving on. I’ll update the version of the app on GitHub soon.

Gain unlimited access to Premium articles.

With technology shaping our everyday lives, how could we not dig deeper?

Thurrott Premium delivers an honest and thorough perspective about the technologies we use and rely on everyday. Discover deeper content as a Premium member.

Tagged with

Share post

Thurrott