Complete scaling of a WPF window

Has anyone managed to completely scale a window up and down? I've found
that the LayoutTransform works quite well when using Controls but I'm
having problems with applying this to an actual window.

All Windows and controls has a property called LayoutTransform,
inherited from FrameworkElement:

public Transform LayoutTransform { get; set; }


Transform is an abstract call with a number of derived classes including
ScaleTransform and MatrixTransform. At runtime, it appears that the
window's LayoutTransform is of type MatrixTransform. What properties
can I use to scale the window up and down (with equivalent scaling in
both x and y dimensions?). I'm trying to study up on affine
transformation and the 3x3 matrix that you work with to accomplish it,
but, but I'm not yet accomplished enough in this area.

As a shortcut, I tried using ScaleTransform by replacing the window's
Layout transform like so (this is connected to a slider control):

w.LayoutTransform = new ScaleTransform(mySlider.value, mySlider.value);

What this accomplishes is to scale the contents of the window up and
down brilliantly, but the actual window itself remains the same (with
the leftover area being taken over by black space). What I need is for
the actual window boundary to go with the content.

Thanks, any information would be appreciated, as always!

Jason

You might want to try playing with different values for the SizeToContent
property of the System.Windows.Window class. Setting that property to the
enum value "SizeToContent.WidthAndHeight" might just do the trick. (Its
default value is "Manual" which means
the window does not auto-adjust to the size of its content.)

Warning: I have NOT tried this. I took a quick look at the SDK doc and
thought this property might be relevant. I.e. this is pure conjecture. Let
us know your results, please...

Windows themselves are not handled by WPF, they are still drawn by Win32, so
I don't think you can scale them as far as I know. The members you are
talking about will probably influence the content of the Window, not the
Window itself.

Etienne Boucher

You might want to try playing with different values for the
SizeToContent property of the System.Windows.Window class. Setting
that property to the enum value "SizeToContent.WidthAndHeight" might
just do the trick.

Warning: I have NOT tried this. I took a quick look at the SDK doc
and thought this property might be relevant. I.e. this is pure
conjecture. Do please let us know if it works out...

-- David Sklar

You might want to try playing with different values for the
SizeToContent property of the System.Windows.Window class. Setting
that property to the enum value "SizeToContent.WidthAndHeight" might
just do the trick.

Warning: I have NOT tried this. I took a quick look at the SDK doc
and thought this property might be relevant. I.e. this is pure
conjecture. Do please let us know if it works out...

-- David Sklar

sorry about the multiple redundant postings... I was using Google Groups to
post messages,

and now I know why it's still in beta. It's a great reader... but don't use
it post... yet...

D. F. Sklar wrote:
> sorry about the multiple redundant postings... I was using Google Groups to
> post messages,
>
> and now I know why it's still in beta. It's a great reader... but don't use
> it post... yet...
>
>
>
>
Ouch, and I got all excited that there were some more replies! The
SizeToContent still doesn't do it unfortunately, I'll need to keep
looking. Thanks though!

Jason

Exactly, this is one of those accidents of class hierarchy -- as much as
possible we want Window to look like any other Control, but there's a few
aspects of Control we can't support. And a class hierarchy that split this
functionality out would be way more complexity that seems justified...

HwndHost has the same issue, by the way.

--
-Nick Kramer [MSFT]
http://blogs.msdn.com/nickkramer

---
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Etienne Boucher" <etienne@novat.qc.ca> wrote in message
news:Os$AJaJFGHA.1032@TK2MSFTNGP11.phx.gbl...
> Windows themselves are not handled by WPF, they are still drawn by Win32,
> so I don't think you can scale them as far as I know. The members you are
> talking about will probably influence the content of the Window, not the
> Window itself.
>
> Etienne Boucher
>

Nick Kramer [MSFT] wrote:
> Exactly, this is one of those accidents of class hierarchy -- as much as
> possible we want Window to look like any other Control, but there's a few
> aspects of Control we can't support. And a class hierarchy that split this
> functionality out would be way more complexity that seems justified...
>
> HwndHost has the same issue, by the way.
>

So how is this done in Sparkle? When you use the workspace zoom slider
in Sparkle, all of the child windows scale up or down. Isn't Sparkle a
100% WPF application?

Thanks!
Jason

Jason Dolinger wrote:

> So how is this done in Sparkle? When you use the workspace zoom
> slider in Sparkle, all of the child windows scale up or down. Isn't
> Sparkle a 100% WPF application?

Just going from memory since I don't have time to load it up right now, there
are no "real" windows inside of Sparkle. It's not a true MDI interface, it's
all custom UI elements. So when they scale they're scaling 100% pure WPF
content.

HTH,
Drew
___________________________________
Drew Marsh
Chief Software Architect
Mimeo.com, Inc. - http://www.mimeo.com
Weblog - http://blog.hackedbrain.com/