Strange behavior in FormBorderStyle between Fixed and Sizable

[ProclaimDragon]

I have created a simple test form with FormBorderStyle = FixedToolWindow by default and added a piece of code to the form DoubleClick event that will switch between FixedToolWindow and SizableToolWindow.

Switching the FormBorderStyle between these two seems to produce a weird effect that's causing a lot of issues on my application. The problem is that the window seems to change size and I can't have that. I just want to change the border, I need the form size to remain the same.

For instance, here's the event code:

private void Settings_DoubleClick(object sender, System.EventArgs e) {
	if(FormBorderStyle == FormBorderStyle.FixedToolWindow) {
		System.Diagnostics.Debug.WriteLine("SWITCHINGED -> SIZABLE");
		FormBorderStyle = FormBorderStyle.SizableToolWindow;
	} else {
		System.Diagnostics.Debug.WriteLine("SWITCHINGABLE -> FIXED");
		FormBorderStyle = FormBorderStyle.FixedToolWindow;
	}
}

And to debug I use this:

private void Settings_SizeChanged(object sender, System.EventArgs e) {
	System.Diagnostics.Debug.WriteLine(this.Size);
}

And here's the output when I double click:

SWITCHING: FIXED -> SIZABLE
{Width=373, Height=169}
{Width=383, Height=179}
SWITCHING: SIZABLE -> FIXED
{Width=383, Height=179}
{Width=373, Height=169}

How can I fix this behavior? And by "fix", I mean, prevent this from happening if possible. I want to be able to specify my form size and to remain like that, no matter the type of border style.

Also, a solution by subclassing the Form class would be the perfect solution for me in case anyone as any ideas to solve this problem with such a method.

[Antaris Veteran]

Could you maintain the size property before and after the border-style change? What could be happening is that the Window size is being modified due to the change in border size for resizeable windows.

private void Settings_DoubleClick(object sender, System.EventArgs e) {
	Size size = this.Size;
	if(FormBorderStyle == FormBorderStyle.FixedToolWindow) {
		System.Diagnostics.Debug.WriteLine("SWITCHINGED -> SIZABLE");
		FormBorderStyle = FormBorderStyle.SizableToolWindow;
	} else {
		System.Diagnostics.Debug.WriteLine("SWITCHINGABLE -> FIXED");
		FormBorderStyle = FormBorderStyle.FixedToolWindow;
	}
	this.Size = size;
}

[ProclaimDragon]

I tried that before, it doesn't work...

[ProclaimDragon]

I made a little video to demonstrate the problem. The first test shows that the form size doesn't actually change (visually), only the location of the form changes a little bit; but the values for the Size property do change, as you can see on the debug output. The second test you will see on the debug output that the form Size property values change and the window size itself will also change.

Please look here:

http://screencast.com/t/0vT1vCoyx2u

[azcodemonkey]

I switched to the classic theme to get an idea of what was happening. It appears that when switching, the thickness of the border changes probably due to the style being set to thick frame for resizing. My guess is that you're seeing that a little more dramatically with the Aero theme as the frames are thicker. I don't know that you'll be able to get around it unless you subclass and set the window to not have a WS_THICKFRAME when the form border style is sizable, but then you're modifying OS behavior to accommodate resizing with a thicker frame.

Your actual client rectangle isn't being resized at all. It's the non-client areas that are changing.

Don't ask me why fixed is larger than sizable... I couldn't say. You may want to hit the forums on MSDN.

Edited May 14, 2009 by azcodemonkey

[ProclaimDragon]

The border is thicker on Classic and on XP but not on Vista. On Vista, if you look closely, the border has the same size or so it looks like.

Is there anything wrong in "modifying OS behavior to accommodate resizing with a thicker frame"?

I'll put this on the MSDN forums them...

In the meantime I realized something else:

The problem lies on all types of fixed border styles like FixedDialog, Fixed3D, FixedSingle and FixedToolWindow. It does not happen on the sizable ones. This problem, like I said, it also happens only on Vista.

Let's say you have a form with any of the fixed border styles and set the starting location to 0,0. What you want here is for the form to be snapped to the top left corner of the screen. This works just fine if the form border style is one of the sizable options, if it's fixed, well, the form will be a little bit outside of the screen working area both to the left and top.

What's more strange about this is that the form location does not change, it sill is 0,0, but a few pixels of the form are still drawn outside of the working screen area.

I tested this on XP and it didn't happen, the problem is Vista specific. On XP, the only difference was the border size that change a bit between any of the styles. But the form was always perfectly snapped to position 0,0.

[azcodemonkey]

It's pretty bizarre behavior, for sure. I did notice that the frame still looks the same in Vista.

I've used Spy++ to verify what I'm seeing, and the frame is indeed set to WS_THICKFRAME when sizable and in Aero. Also, I'm seeing that TOP, LEFT, BOTTOM, an RIGHT of the client rectangle are what is changing, along with the overall window rectangle size to accommodate the thicker frame. I'm guessing that MS changed how frames are rendered with Aero.

Sizable:

Fixed:

What it means, I'm still fuzzy on. This could be a bug in DWM.

[ProclaimDragon]

Some people have been helping me over at the MSDN forums and one of them provided a solution that would solve the problem. The catch was that the app would no longer work on XP...

Anyway, the reason I want to do this is to allow my application, which has a skin applied, to enable or disable that skin. The whole application is working fine with the skin and I was trying to implement a property to enable and disable the skin. The issue on this topic was one of the problems I'm having when the skin is disabled. I then realized that I also have a lot of other annoying problems to deal with if the skin is disabled. Which means I'll just forget about this feature for now and leave the skin always on in the time being. I just don't have the time to handle so many issues right now...

Thanks for all your help though :)