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...

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

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

At some PDC Microsoft showed (in Vista) Notepad rotating and jumping around
the desktop. Is this still possible? If yes, how?


"Nick Kramer [MSFT]" <nkramer@ms.spam> schrieb im Newsbeitrag
news:eRv7XijFGHA.1032@TK2MSFTNGP11.phx.gbl...
> 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
>>
>
>

But is it still possible? Is there API (not WPF)?

"Drew Marsh" <drub0y@hotmail.no.spamming.com> schrieb im Newsbeitrag
news:f01844f1e73578c7e4d9a58ea34e@msnews.microsoft.com...
> Daniel Danilin wrote:
>
>> At some PDC Microsoft showed (in Vista) Notepad rotating and jumping
>> around the desktop. Is this still possible? If yes, how?
>
> That's not possible through WPF, no. That was the desktop window manager
> which sits at a lower level and does all sorts of neat tricks. AFAIK this
> is not extensible in any way today.
>
> HTH,
> Drew
>
>

Drew Marsh wrote:
> 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/
>
>


Still hacking away at this one... I understand that the window borders,
title bar, etc. are still drawn by Win32 so there really isn't anything
in the WPF API that I could use to accomplish this. I can live with
that. I'll actually be fine turning off the borders for the windows
(Setting the WindowStyle to "None"). But I still need the window
"insides" to scale down. Like I said, I can actually get the content to
scale down nicely, but then I'm left with black space blanking out the
remaining area where the window was (do I somehow need to kick Windows
to tell it to redraw the desktop or something?).

Anyway, trying to dig a little deeper, I wrote a program to print out
the visual tree of a window and have noticed that every WPF window has
the following hierarchy created by the framework before it starts
inserting your own layout controls, etc... (it prints the type of each
element in the tree plus the name if one exists) :

<whatever your window class is>, Name:
Visual Type: System.Windows.Controls.Border, Name:
Visual Type: System.Windows.Controls.Grid, Name:
Visual Type: System.Windows.Documents.AdornerDecorator, Name:
Visual Type: System.Windows.Controls.ContentPresenter, Name:
*** user defined layout and controls start here... ***

So I also tried playing around with everything i could possibly think
of, applying to ScaleTransform to each of this subelement rather than
the Window (no luck there), and then trying to bind the Height and Width
of the Window to the ActualHeight and ActualWidth of each of these
elements in turn (and then tried changing their ActualHeights and
Widths). I noticed a few things during this testing:

- Height and Width of each of these elements is always NaN. This could
be because these are the suggested values and I haven't defined any.
- ActualHeight and ActualWidth of each of these elements NEVER changes.
I'd have thought that when I applied my scale transform to the
window, that SOMETHING would change. I thought for sure that at least
the ContentPresenter (the last level of framework defined visual in the
tree before inserting the user defined content) ActualWidth and
ActualHeight would be changing, to provide a bounds on the actual window
content that was scaling. Then it would only be a matter of binding the
window's height and width to these values. But no dice, they never
change.

Is it possible that I'm having problems because there is a Grid in that
hierachy, and the system automatically handles the layout? Should I
override that portion of the visual tree with a canvas (if that is
possible). I feel like there must be some magic combination of setting
Height and Width properties at the correct visual tree level that will
fix my problem. Should I be looking at using the ClipToBounds method to
cutoff all extra content except for my scaled window content? Should I
give up!???

Thanks for any help, it's always appreciated!

Jason

> I am unaware of any API for DWM. Perhaps someone from Microsoft knows
> different though.

DWM does not provide any kind of rotate window API. Only API DWM provides
is the "client glass" API which lets you extend the glass look into the
client portion of your application. (Just don't ask me for the API name, I
can never remember

-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


"Drew Marsh" <drub0y@hotmail.no.spamming.com> wrote in message
news:f01844f1e78088c7e50b61dd19c8@msnews.microsoft.com...
> Daniel Danilin wrote:
>
>> But is it still possible? Is there API (not WPF)?
>
> I am unaware of any API for DWM. Perhaps someone from Microsoft knows
> different though.
>
> Later,
> Drew
>
>

The trick they used at the PDC is quite easy... (sort of...)

Download my tutorials and open the FullScreenSize project...

http://blogs.infosupport.com/ernow/articles/1878.aspx

Cheers,

Erno

"Jason Dolinger" <jdolinger@lab49.com> wrote in message
news:%23VgzGAuEGHA.3100@tk2msftngp13.phx.gbl...
> 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