WPF Design Diary: Keeping the Native Window “Chrome” out of the Content
My first exercise is translating the “biggest box” CSS strategy into WPF. For seasoned Expression designers this effort must be “crazy”—because XAML can do so much more than XHTML. So, the first thing is to get my “biggest box” to be exactly 1024×600 (my WSVGA standard). Just make the Window.Height="600" and Window.Width="1024", right? Well, what happens is that, by default, WPF will ‘share’ OS “chrome” with your Window dimensions. This means that the child element of Window (usually Grid or StackPanel) will have an ‘unknown’ width and height (this is not unknown, actually, because we have FrameworkElement.ActualWidth and FrameworkElement.ActualHeight to consult).
So what I’m saying (because I am too lazy to provide this Blog post with screenshots) is that my “biggest box” element for WPF is the first child element of Window. This means that my WPF must ‘push’ window “chrome” (all that Aero Glass) out of the space reserved for the “biggest box.” As usual, WPF provides for this with Window.SizeToContent``="``WidthAndHeight``".
The next level beyond this is the question, “Does the Window need to be resizable?” When the answer is “no” then just set ResizeMode="NoResize" (my preference: ResizeMode="``CanMinimize``"). When the answer is “yes” then you have quite an elegant solution to grasp. I can only hope the hope of the captive that I’ll find it one day… By the way, before I reminded myself about the ResizeMode="NoResize" property and setting I wrote this for Application.OnStartup:client.Loaded += new RoutedEventHandler(
(s, args) =>
{
if(s is Client)
{
var c = (Client)s;
c.MaxHeight = c.MinHeight = c.ActualHeight;
c.MaxWidth = c.MinWidth = c.ActualWidth;
}
});
I was tempted for a spell to let the vertical height of the WPF be variable (like in a Web browser). Soon came some over-engineering ideas instead of design ideas. The first design principle in this context: a Web browser Document is not an application Window. It follows that a WPF Window should not recognize the existence of, say, ‘infinite’ vertical scroll. There are child WPF layout elements (wrapped with ScrollViewer) that can be used in various scenarios that facilitate scrolling. There are many valuable design ideas from the Web world that are valuable and they have to be recognized and coherently integrated—not confused. More on this later…