How can i scale a Form with font in WPF?
i.e. What is the WPF equivalent of
this.Font = SystemFonts.IconTitleFont;
In WinForms, if you're a good developer, you honor the user's font preferences. A WinForm that starts out as:
You then apply the user's font preferences:
this.Font = new Font("Segoe Print", 11, GraphicsUnit.Point);
and elements on the form scale to accommodate the new size:
Notice:
the form is wider and taller
the label is positioned further down, and to the right
the label is wider and taller
the text of the label is not cut off on the right or on the bottom edge
the button is wider and taller
but button is positioned further down, and to the right
Note: In WinForms you can also use the line:
this.Font = SystemFonts.IconTitleFont;
WPF doesn't support Font, which is why i provided the clearer alternative. For the example below.
A similar WPF form starts out as:
You then apply the user's font preferences with:
this.FontFamily = new FontFamily("Segoe Print");
this.FontSize = 14.666; //11pt = 14.66
and elements on the form don't scale to accommodate the new size:
Notice:
the label's position has not changed
the button's position has not changed
the form is not wider or taller (text is cut off)
the label is not any wider (text is cut off on the right)
the label is not any taller (cutting off text along the bottom edge)
the button is not any wider (text is cut off)
Here is another example of two buttons that are the same size:
WinForms:
Windows Presentation Foundation:
Bonus Reading
WPF: How to specify units in Dialog Units?
How to prevent WPF from scaling with the Windows font size options?
WPF version of .ScaleControl?
WPF doesn't do primitive font-based scaling because it's... well, primitive. You can see it in your own screenshots.
Here's your "WinForms, before changing font" screenshot. Take a look at how much space there is between "sat on a log." and the right edge of the form.
And here's your "WinForms, after changing font" screenshot. Notice how much less margin you have after "scaling".
If you hadn't left all that extra space, then your label would be cut off with the new font. And with some fonts, it would be cut off even though you did leave all that extra space. That's what I mean when I say WinForms' scaling is "primitive". WinForms picks a single scale to apply to everything, and that scale is not chosen with any awareness of your content; it's based on average statistics for the font, which can and will fall apart once you start talking about specifics.
WPF doesn't hobble you with something that primitive. It gives you an amazingly powerful layout system, where it would be trivial to make a window that scales beautifully. But instead, you're choosing to cripple that layout system by using hard-coded sizes. Stop it.
Hard-coded sizes have two huge problems:
They don't adapt to different fonts. You've noticed this already.
They don't adapt to different content. (What happens when you want to make a German version of your app, and the German text doesn't fit into your hard-coded button size?)
Hard-coded sizes just don't adapt. To anything. You had to use them in WinForms because that's all WinForms supported. But WPF gives you a proper layout system, so you don't have to (and shouldn't) use anything that crude.
All you need is this:
A Window with SizeToContent="WidthAndHeight". That way, the window will be exactly the right size to accommodate the text and button, no matter what font or language you use.
Since you only have two UI elements, and one is above the other, you would put a StackPanel inside your Window.
Inside the StackPanel, you need:
A Label or TextBlock to show your text, with the text in Content (Label) or Text (TextBlock); and
A Button with HorizontalAlignment="Right", and the text in Content.
Set some Margins on the StackPanel, TextBlock, and Button to space things out to your liking.
That's it. Don't set any other properties on anything -- especially not Width or Height.
Now, if you change your font, the window and the button will still be exactly the right size, and won't cut off your text. If you localize your app into a different language, the window and the button will be exactly the right size, and won't cut off your text. Stop fighting WPF, and it will give you great results.
If you later want to make your layout more advanced, you could consider things like:
If you want the button to be a little wider (to have more breathing room before and after the text), try playing with the Padding, or set a MinWidth and MinHeight. (Don't use Width or Height if your button contains text. You might consider using them if your button only contains an image, but maybe not even then.)
If you're worried that the font might make the window so large that it no longer fits on the user's screen, and want to enable word-wrapping, then play around with MaxWidth and TextWrapping.
WPF's layout system is amazingly powerful. Learn it. Don't fight it by using hard-coded layouts and then complaining that your hard-coded layouts suck.
Related
I have a ToolStrip control docked to the top of a Windows Form. Throughout the program, I have the font sizes on controls not specified so that they inherit from the base form. That way I can set the font size larger when the user selects "Large Font Mode" and it automatically changes throughout. The ToolStrip seems completely unaffected by this and sticks to the default size.
Is there a way have the ToolStrip inherit the base font size? Or do I need to write something to go through and find all the ToolStrips and update their .Font property?
Picture for reference:
Little update - what led me down this road is that sales people got touch-capable 1080p 10" tablets running Win8. Before making any adjustments to the display settings, the ToolStrip was an impressive 3mm tall, very difficult for anyone with large hands to hit with any accuracy. The rest of the form was difficult to interact with too. Apple has suggested 7mm for touch targets, and even Microsoft suggests 9mm. Changing the settings in Control Panel > Display up to 160% resulted in touch targets of about 6.5mm, good enough to hit without making the rest of the form too big.
When designing WPF dialog windows in the XAML designer (that are not manually resizeable by the user), the windows automatically resize to fit their content, and everything is fine. But when I run my app, the windows become huge and there's a lot of empty space.
I know this is a "feature" of WPF that can be "fixed" by setting the SizeToContent tag, but another issue arises when I do this: If the window contains a textbox, for instance, and the user enters data that overflows the visible area, the window will stretch to accommodate it. This happens with listboxes, treeviews, you name it.
All I want is for Visual Studio to figure out the ideal window size that it shows me at design time, then set the window to be that size at runtime, and don't change the size after that. It seems like this should be an easy thing to do.
Edit: Figured out part of the problem: I have controls set up in a grid, and the column's width is set to "Auto" which is why everything is resizing.
Use View Box
The ViewBox is a very useful control in WPF. If does nothing more than scale to fit the content to the available size. It does not resize the content, but it transforms it. This means that also all text sizes and line widths were scaled. Its about the same behavior as if you set the Stretch property on an Image or Path to Uniform.
Although it can be used to fit any type of control, it's often used for 2D graphics, or to fit a scalable part of a user interface into an screen area.
<Viewbox>
<Enter your code/>
</Viewbox>
Try setting the window's height and width to Auto. Also, remove the SizeToContent attribute. This should fix it.
I do not think that this is this is something which is commonly requested so it's probably not easy to do, one method i can think of would be starting with automatic SizeToContent and handling the Loaded event and setting:
Height = ActualHeight;
Width = ActualWidth;
SizeToContent = System.Windows.SizeToContent.Manual;
I'm sort-of just nit picking here, but maybe there's a simple solution which will save me some time.
When I'm drawing my Winforms GUI in the designer, controls snap to certain points. I can align the baseline of the text of one control to that of another, I can align the left and/or top of one control to another, etc. This is all great.
What's great too, is that the controls snap to other controls spaced with their margins. This means that if I'm making a vertical array of TextBoxes, then I can have them equidistant in my GUI - it looks less messy.
However not everything snaps correctly, or at all. Say I have put in my TextBoxes and now I wish to reduce the width of my form so that there is no white space between the edges of the TextBoxes and the edge of the form. Additionally, I want the distance between the edge of the TextBoxes and the edge of the Form to be the same on the left as it is on the right. If I drag the right edge of the form to the left, towards the TextBoxes it will not snap. I'm left with either calculations to work out what the width should be, or a juggling act to gradually reduce the width until the TextBox is snapping to both the left of the right.
I'm not saying this process is particularly difficult or time consuming. It's just that if it were to snap, the whole process would be infinitely easier.
Is there a built-in option in VS2010, or perhaps an extension? Or maybe I'm just doing it wrong in the first place?
The snap lines in the designer work perfectly when moving or resizing any of the built-in controls. The only time that they don't work is when you are resizing the form itself.
I agree that it would be extremely convenient to have snap lines here, as well. I wish I knew of a way to enable this. But unfortunately, I don't believe that there is one.
The workarounds are either to calculate the proper size mathematically, or guess at resizing the form then check your work by dragging one of the controls (and using the snap lines that appear). I go through the same "juggling act" that you describe on an unfortunately regular basis.
Whenever a control needs to be positioned so that it "snaps" to a form edge I usually move (or resize) the controls to the correct size first, and then change the controls "Anchor" property of those controls to be anchored to the corresponding form edge (even if the form itself won't be allowed to resize).
That way whenever I resize the form, the controls position relative to that form remains the same, simply resizing or moving the control as required (depending on the Anchor property chosen).
I completely agree that the ability to "snap" the form to controls when resizing the form would be extremely useful, but its normally possible to work-around using the anchor property in this way - the times when its doesn't work (such as when a form consists entirely of a column of text-boxes is a fixed height), I'm afraid you need to resort to calculations, but I find that most of my dialogs are resizable.
How should I develop a form that can resize nicely?
While that sounds like a simple question the problem I'm struggling with is the fact I'm reproducing an existing application I made in Swing several years back. Its built around a single form that hides/reveals panels as you select different options.
Its around 600 x 700 pixels wide say but its a fixed size window.
Is this good practice? The GUI works fine this way but if you look at other applications you can resize them easily. Granted some applications look stupid full size but should the option be there?
The main screen consists of about five buttons, when maximized this looks ridicilous, but at the same time if the form is resizable the moment you start resizing the form it becomes stupid.
I'm aware of layout managers and so forth so no need to tell me to check these out, my main problem is the fact I can produce an excellent fixed width application but that's about it.
Any advice/links for this?
Personally, I think fixed size forms are a horrible User Experience.
I always try to build mine so that they can be gracefully resized (even if they do look a little odd).
If you're using .NET for your WinForms development, you can easily use a table layout and then anchor your controls so that they resize politely.
A fixed size gui is generally a bad idea because most forms have a user interface element that can sensibly be resized.
First consider a form that only contains two buttons. (A silly form, yeah, but for the sake of discussion we'll assume that it's the right thing for the job) When sized initially in the right way (appropriately for localization, e.g.), there's no good reason to make the form resizable. If you enlarged or mazimized the form, you'd only make the area to click the button bigger, but you'd be clicking a smaller area than the button to resize it, so there's no reason. In this case, it doesn't make sense for the form to be resizable because there's no user-benefit for adding the extra control.
Now consider a form that contains a listview. There are clear usability benefits to making this form resizable in both dimensions. The listview may contain more items than can be shown in a smaller area, both horizontally and vertically, so it makes sense that this form be fully resizable to allow the user to display as much or as little of the data as they want.
Every form control implicitly has certain degrees of freedom either by constraint or by convention. Conventionally, buttons don't resize, so they have no degrees of freedom (even though they can resize). Listviews and listboxes have two degrees of freedom, horizontal to display more data per row and vertical to display more rows. Single line textboxes have one degree of freedom, horizontal. Because they're single line, they don't expand vertically, but they do expand horizontally.
These degrees of freedom help you determine the layout of your form. Form elements that have degrees of freedom should resize in the appropriate direction when the form is resized. I prefer to design my forms with only one control that has two degrees of freedom in an area where areas are typically separated via splitters. I prefer to avoid the explicit table layout panel unless there's a very specific need for it because it's easy to make a form overly complex when there's a table layout to work with. The anchors in WinForms provide an extremely powerful and flexible abstraction for control layout, however, so I strongly encourage their usage.
Aside from the layout panels (my favorite is the table layout), become familiar with the Anchor, Dock (more for the table layout), and MinimumSize properties. They do a lot of work for you when it comes to resizing forms.
Most of your forms will look goofy maximized but my general rules were these:
Buttons stay the same size
regardless of form size (no Top and
Bottom anchor; no Left and Right
anchor).
Buttons stay in the same place with
respect to a border (Anchor
combinations: {Left, Top}, {Left,
Bottom}, {Right, Top}, {Right,
Bottom})
Only the right-most textbox grows
when resizing (Anchor = Left and
Right).
Single multiline textboxes rule the form
(Anchor = Left, Right, Top, Bottom)
With multiple multiline textboxes, the lowest one rules the form.
MinimumSize is less that 640x480 whenever possible; 800x600 max.
The default size is the MinimumSize -- let the users make it bigger if they need to.
I have a custom canvas that I can drop controls on, move, and resize. I need to be able to at least start with a pre-determined size but then allow re-sizing.
My problem is that I have a user control that doesn't appear to resize. I set Height and Width on the user control (works on drop). But then as the control is resized on the canvas the visual size stays the same (the sizing handles are changing). I can see the Height property changing (usercontrol.height) as the control is resized. But again, the appearance of the control stays the same size.
I had a thought that the inner container on the user control should be bound to the usercontrol.height but that didn't seem to help. (or maybe I didn't have the binding right).
On the same canvas, if the dropped control is for example, an Image control, I can set an explicit height on the drop and everything resizes as it should. So it seems to be UserControl thing.
So is there something special I need to do with UserControls to get the visuals to resize? Should I be using explicit height and width to get it all started?
Thanks for any help.
The WPF layout system can be confusing, as you've discovered. There is no substitute for a solid understanding of the layout and measurement system. If you plan on doing much WPF development, it's worth taking 20 minutes to read this article on the layout system and then experimenting for a while in an iterative environment such as Kaxaml until you feel comfortable.
The system is very logical. It won't take long for the penny to drop. Sorry for the indirect answer, but I don't believe there's enough information in your question to really explain what's going on.
You might also look at the HorizontalAlignment and VerticalAlignment properties.
Not a WPF expert but I believe you need to enable auto-sizing in order to achieve the scenario you are looking for. This is done by setting the Height/Width of a control to Double.NaN which essentially says, "I have no specific size". Once you do that, the control should resize to occupy available space based on the need of the control.