Is it possible to set the textbox text to align at the center while using auto size property to false.I tried with Text align property, but it does't work.Here is my code.
textBox1.AutoSize = false;
textBox1.Size = new Size(100,35);
textBox1.TextAlign = HorizontalAlignment.Center;
Below is a screen sample :
I want the result to be as show in figure.
TextBox is one of the grand-daddy controls in the toolbox. Goes back all the way to 1987 and Windows version 2.0. Back when it was still a 16-bit real-mode operating system and had to run in 640 kilobytes of memory. It is also notorious for breaking the rules, painting itself without using WM_PAINT. The kind of thing Microsoft had to do to get acceptable perf from a 386SUX processor. The dearth of memory was a major reason to cut down on its features.
They did not do much to improve the control, although it certainly looks a heckofalot better than it did 28 years ago. Changing it behavior is very risky, TextBox is a major app-compat nightmare with 28 years of programmers trying to hack it to do more.
But there is no way to hack it to look the way you want it, it always renders the text top-aligned. You must have noticed the fight that it put up to stop you from writing that code. It is also very, very wrong code, hard-coding the size produces very undesirable accidents when it runs on a high DPI machine, displaying text with the descenders sheared-off. AutoSize should always be set to True for a single-line TextBox to prevent such accidents.
You can otherwise emulate it pretty easily, just embed it in a panel that is as tall as you want it and set its BorderStyle property to None. Use its Resize event to center it in the panel. Easy peasy.
As the question is about vertical arrangement and also for single mode there is a method but it would be working around with panels.
Place textbox inside a panel with paddings there you go :
Related
I'm trying to do some automatic tests if the strings of a translated Application still fits the existing UI. The translation process just takes an existing resource assembly translates the contained resources and creates a new resources assembly for the new language. Easy but that way there is no garantee that the translations still fits into the UI (the UI is not involved in the translation process) and might get truncated all over the place. So for an automatic check i would need an idea on how to find truncated Text on the UI.
I tried so far:
Measuring the client size of a control, measuring the text length and
compare them. Doesn't work since there seem to be no way to find out
the ~real~ client size of a control that is used for putting text on
it (For a Button its not just Size minus Padding for example)
Setting AutoSize to true and checking if the control grows. That
would only work for non-wordwrapping controls and there seem to be
no sharp limit here. A control might grow to fit the Text on its
surface when setting autosize but the Text was fitting before
also. The margins might have been pretty narrow but the Text where
fitting.
Are there more idea that might work? Or are there some tweeks that might make the above mentioned ways work? Would be great if there where a simple Win API method i could call that would just give me the actual shown text of a control not the text a programmer/programm whishes to be shown on a control.
Get the amount of the characters from the non translated version and differentiate them against the length of the translated version then multiply the current controls width by the difference. It could look something like this.
float scalingAmount = 0.1 //This is just an example value, you'd probably want to adjust this yourself
float difference = oldLabel.Text.Length - label.Text.Length;
label.Width = oldLabel.Width * (difference/scalingAmmount)
I have a WinForms application that allows you to edit documents. Each document is made of chapters and each chapter holds a collection of RTF blocks. The RTF blocks are loaded in a PanelControl using Dock = DockStyle.Top.
The problem is that when the total height of a chapter gets too large (estimating > 32768 pixels) the lower blocks are not properly docked: they appear behind one another. When trying to isolate the problem I noticed that this also happens with simpler controls like a LabelControl.
Things I tried are methods like Refresh(), Invalidate() and PerformLayout: they will not resolve the issue.
What does help is resizing the form. After that all controls are laid out correctly.
Can anyone help on how to solve this without resizing the form?
Attached a simple demo-project that illustrates the problem.
From my comment above (seems really to be the problem here):
WinForms (and the GDI in general) is often behaving unpredictably if one tries to use coordinates outside a 16 bit range. Try to avoid that. In the range of possible problems are things just not getting drawn at all, OverflowExceptions at unexpected code positions etc.
If it's possible to you take decision to change this layout, I suggest you to take another approach on showing/editing the documents chapters with some kind of pagination or collapsing RTF blocks into a menu and showing only current.
You see.. it makes a sense the height value be a integer 16-bit value.
A screen is way more tiny than this.
As panel height increases to such a high size. You see that using scroll bar will become very very sensible.. and it's not a good thing.
Content with size 2x, 3x, 5x being scrolled is usable to user. But scrolling a content with height (~32768) of at least (using good resolution monitor w/ window maximized) in optimal case 32x the size of window is very uncomfortable.
Plus, I believe that the productivity of user will decrease due to brain difficulty in locate "things" in a increasing collection of "things".
I wanted to show some mathematical expressions in a winforms textbox. So I thought the "Cambria Math" font would be a good choice but the text looked strange due the high top and bottom margin of the font. First I thought I made a mistake but according to this question, it's the correct behavior of the font.
Why does Cambria Math have these big margin values and how can I display my string correctly in the textbox like Word 2010?
(Note that I know only a little bit about typography ;)
Edit: I had to make the textbox that tall otherwise the caret would be invisible. The font size of the textbox is set to 8.25pt
Cambria Math uses Microsoft's mathematical OpenType extensions.
Word 2007 and later understand these and display the text with reasonable spacing.
However, notepad and Word 2000 display the text with enormous spacing, just like winforms. I guess the font has this much space by default because some characters (like U+2320, top half integral) are much larger than the alphanumerics.
If you use Cambria Math with a font engine (such as the one used by winforms) that doesn't understand the math extensions, you're going to get the big spacing.
If you're displaying simple expressions you might as well use Cambria.
In VS2008 I designed a form for a C# dll. The dll is a plugin for a somewhat older app (ca. 2005): let's call it "OldApp". In VS form designer, the text in Label controls on my form is nicely rendered: antialiased and properly kerned. But when I bring up this form within OldApp (where the C# dll runs as a plugin), the text in Label controls looks ugly. It's legible, but the kerning is poor: the letters are spaced further apart and at seemingly random offsets. Anything I can do to make the text labels from within OldApp look as good as they do in VS's form designer? I doubt the specific font matters, but it's Arial, 7.2 pt (VS2008 default). I tried playing with the two relevant lines in Program.cs (see below), to no effect.
Application.EnableVisualStyles(); // tried using it and commenting it out
Application.SetCompatibleTextRenderingDefault(true); // tried true and false
I found a similar problem on MSDN forums that mentions adding the following line after the EnableVisualStyles() method.
Application.DoEvents()
Seems to be a bug in older .NET versions...which version are you using?
After an investigation I have some findings, so I'll just answer my own question:
The bad news: the old-style text rendering used by OldApp is what's causing the problem. I verified it by toggling the UseCompatibleTextRendering property for the label control in VS. The font distortion I see is the same one I see in OldApp. Which means that the Application.SetCompatibleTextRenderingDefault(false) line in my code has no effect. OldApp will ignore it and do old-style rendering anyway.
As suggested by DeviantSeev using a bigger font helps a bit. It doesn't get rid of the bad kerning, it just makes it less noticeable. I increased the font from 7.2pt to 8pt only (not 12pt), because the dialog box becomes too big otherwise. The way to do this is in the form's Font property (not the control's). This way, you'll change all controls uniformly (if their Font property is set to default).
The font sizes in VS appear to be discrete rather than continuous, or maybe there's an int() rounding off involved. Increasing the font from 7.2pt to 7.4pt results in very little change, while at 7.5pt the font makes a sudden jump in size.
Forms have an AutoScaleMode property. If it's set to Font and the form is resizeable, the form will resize in VS in proportion to the change in font size. This way, in VS you can find an acceptable middle ground between a (legible) font size and a bloated dialog. However, be careful: the auto-scale operation can suddenly go awry, for example if you change the Font units from points to pixels, inches, etc. You may suddenly end up with microscopic controls or a form bigger than your screen and hitting undo won't fix it. You really don't want to re-design your form again, so save it before any font unit change and then again when you're happy with what you see.
I have seen many other samples out there that draw smooth text on glass. But I can't use them. I need every single label that gets added at runtime to be smooth. I can't just "draw" text onto the screen.
Is this at all possible, and are there and sources around?
Thank you
Take a long at this article http://msdn.microsoft.com/en-us/magazine/cc163435.aspx#S6
It's a bit long but it answers alot of your question and alore more in regards to glass.
but the relevant part for you directly is
One particular gotcha is that
rendering a GDI item in black uses the
bit pattern 0x00000000-which also
happens to be a completely transparent
black if you are using an alpha
channel. This means that if you draw
with a black GDI brush or pen you'll
get a transparent color, not a black
one. The biggest problem this presents
is when you try to use the default
text color in a control of a text
label that sits on the glass area.
Since the default text color is
usually black, the DWM will consider
this to be transparent and the text
will be written in the glass
incorrectly. An example can be seen in
Figure 10. The first line is written
with GDI+, the second is a text label
control using the default color. As
you can see, it's nearly illegible
because it's actually incorrectly
rendered text that shows up as gray,
not black.
Happily, there are a number of ways
around this problem. Using owner-draw
controls is one. Rendering to a bitmap
that has an alpha channel is another.
Fortunately, the easiest way to get
text on controls is to let the .NET
Framework 2.0 use GDI+ for you. This
is easily accomplished by setting the
UseCompatibleTextRendering property on
your controls. By default, this
property is set to false so that
controls written for previous versions
of the .NET Framework will render the
same. But if you set it to true, your
text will come out looking correct.
You can set the property globally with
the
Application.SetUseCompatibleTextRenderingDefault
method.
He also provides example code you can place in your Main()
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(true);
Application.Run(new GlassForm());
}
But I recommend reading the article, It'll clear up alot of what's going on with Aero/Glass
Cheers,
Phyx