TextBox seems to work differently from others...
Say you want a different font, rounded corners, different colors, a tiled image for the background, reduced padding above/below the text (when I change the font on an individual TextBox they get a little too tall but there's a lot of wasted space), etc. How do you do this in Blend 4?
I'd like it to be in App.xaml so that it's used by default for all TextBox controls in the app.
I think everything you mentioned can be done using controltemplates.What is not working ?
Check this link
http://msdn.microsoft.com/en-us/library/ms752068%28v=vs.85%29.aspx
It will get you started for sure
Related
I'm using a shared code to produce documents in Silverlight and WPF. But the output is different for the TextBlock alignment.
For example for a TextBlock of height 100, displaying a text in Arial with a FontSize of 100 :
In WPF the BaselineOffset is 92.16333
In Silverlight the BaselineOffset is 90.52667
This difference depends on the font family, for example if I replace Arial by Times New Roman :
In WPF the BaselineOffset is 91.23666
In Silverlight the BaselineOffset is 89,11
Is there a way to correct this behaviour and have the same alignment in WPF and Silverlight ?
Thanks for your help
Having worked in both WPF and Silverlight, I can confirm the rendering output of the same fonts at the same font size the output looks significantly different on screen.
In WPF you have a bit more control using RenderOptions i.e.:
RenderOptions.SetBitmapScalingMode(tb, BitmapScalingMode.NearestNeighbor);
RenderOptions.SetClearTypeHint(tb, ClearTypeHint.Auto);
RenderOptions.SetEdgeMode(tb, EdgeMode.Aliased);
You may need to play with values above to get as close as possible. Also as the renderoptions API is WPF only, if you're in a shared codebase you'd need to wrap it in a #if WPF directive..
I'm working on a wpf project that uses the Mahapps NumericUpDown.
In order to make it more touch friendly, I'ld like to make the up and downbuttons a bit bigger.
I've tried setting the height and width bigger of the whole numericUpDown control, but this only makes the buttons height bigger (the width seems to be fixed)
I also tried wrapping the NumericUpDown in a viewbox. This makes everything bigger. The problem is that the numbers in the textbox are also bigger, making it look very alien to the rest of the controls on the screen.
Any ideas on any better solutions?
I don't know when it was added, but the NumericUpDown Control has a UpDownButtonsWidth Property:
<mah:NumericUpDown
UpDownButtonsWidth="60"/>
The + and - buttons get wider accordingly.
I am the developer of NumericUpDown in MahApps.
A solution is to change in NumericUpDown.xaml the Path.Data in PolygonUp and PolygonDown or to change the Contentent of PART_NumericUp and PART_NumericDown.
Alright, try as I might, I cannot for the life of me get rid of this tiny little border around my buttons.
Edit: I should mention, in case I didn't make it clear, these are buttons with an image on them, set to flat with the button sized to the image.
Images below:
Number one, I can't for the life of me get these borders to GO AWAY. I've checked everything I can think of. They're:
flat
border 0
no margins
no padding
manually sized to the size of the image (75px)
in a table layout where the columns are all:
manually sized to the width of the image (75px)
borderless
Nothing seems to really "work" to get rid of these. If I size the columns down to be 74px instead of 75px, most of them go away, but a few remain. I've triple and quadruple checked the images, and they don't have anything that I can pick up on that should be causing this... no transparency around the borders, definitely no border that looks like that.
Which leads me to the second problem:
Settings button when dialog is small...
Settings button when dialog is stretched out.
Settings button is also in the same table layout panel.
I've checked all the settings on the table layout panel as well.. I can't find any padding or margin or anything settings that suggest this should be happening.
Does anyone have any experience with this? What am I missing..?
Simple solution: using directly a PictureBox as if it was a button. You can change your image on mouse over or mouse click.
Have you tried a Toolbar/strip/whatever it's called these days? Probably not going to help as I believe it pads on your behalf, but worth a shot.
In the end you can toss the buttons in the trash and write your own control. A single control that manages N buttons will work well here.
I don't understand your second problem. What's the problem? It'll be fixed if you roll your own control anyhow.
While not a fix for the spacing issue, as a workaround you can make that gray gradient currently "behind" the "tabs" and control panel image into a BackgroundImage for the TableLayoutPanel using BackgroundImageLayout of Stretch. While not fixing the spacing issue, it would make it unnoticeable.
Writing a winforms control has its challenges (experience speaking here). I would agree that that is whats needed however. Depending on your project you may consider using XAML and WPF. It provides that fine detail you seem to be looking for in you application.
There are ways to host XAML controls in a winform app, but if you went this route it would be best to create a native WPF application. The reverse is also true (winform controls in a WPF app).
Did you check if the image has transparent pixels around the graphic pixels you want?
May be a simple crop solution.
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.
We have quite a complex WPF application (that I cannot show here) that somehow has the tiled background misaligned of one of its user controls. I was unable to reproduce this problem in a "clean" WPF project but will try to illustrate the problem in this picture:
(source: kintespace.com)
The gray area represents the user control and the black and red checks represents the tiled background inside the user control. The white background represents the window hosting the control. The VisualBrush is used here but the same problem comes with the DrawingBrush. I would prefer not to use the ImageBrush.
Can you open a "clean" WPF project and build something that will cause a tiled background to be misaligned like this?
You can do this if the layout root of the user control has a -10 left margin and a -10 top margin. the tiled backgoround in on the layout root of the usercontrol so, it looks like a alignment problem not a brush problem.
This problem is related to the tiled background cramming itself into the calculated height of the UserControl instance in the hosting Window. I am still unable to replicate this problem in a new project but it is "solved" (by stacking panels in the user control horizontally instead of vertically).
Here are two diagnostic techniques that can be useful in situations like yours:
Take your complex project, make a copy, and start tearing out large sections of code and XAML until the problem disappears. Then put the last section back and tear things out more gently. Repeat until you find the change that makes the difference.
Run the application, break where a local variable references your UserControl, then explore the visual tree just above and below your UserControl in the Locals or Watch window. Look at each Visual's internal properties VisualOffset, VisualTransform, and VisualContentBounds. These properties will usually clue you in to what property is being set incorrectly, and from there you can figure out why.