Develop Reference

Top-docking controls more than 32768 pixels

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

Text using Cambria Math font in Windows forms gets shifted vertically [duplicate]

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.

make Label control text look as good as it does in VS form designer

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.

SetCompatibleTextRenderingDefault(true) and Graphics.DrawString() text rendering

I'm writing a C# (ActiveX) plugin for an application that uses SetCompatibleTextRenderingDefault(true) (forces .net 1.1 text rendering style) This setting mangles some of the text I output with Graphics.DrawString() causing it to look slightly smudged and bolded. Unlike individual controls neither the Graphics class nor the BitMap have UseCompatibleTextRendering properties that can be used to override the individual behavior. Short of fiddling around to try and figure out what's special about the places where I'm drawing text that doesn't get mangled is there anything I can do about this?
The app my plugin is for belongs to a third party so simply changing the SetCompatibleTextRenderingDefault call it inflicts on me is not an option.
Edit: The 'special' thing appears to be the color of the background and how it's affecting the anti-aliasing used; so fiddling to fix it by how I setup the rectangles doesn't seem to be an option.

I'd advise using TextRenderer.DrawText instead of Graphics.DrawString - even with compatible text rendering disabled, it seems to produce crisper, more consistent results.

I found a fix for my problem by changing the TextRenderingHint to SingleBitPerPixelGridFit which is the default when not using compatible text rendering. When it's instead set to true it uses a the ClearType enumeration except that for whatever reason unlike normal cleartype text the results are ugly and extremely hard to read.
textGraphics.TextRenderingHint =
System.Drawing.Text.TextRenderingHint.SingleBitPerPixelGridFit;

GraphicsUnit.Point, isn't converting well to PDF... GraphicsUnit.World is, but how can I convert it to Point?

I have some code in .Net to draw some text content using GDI+. I used GraphicsUnit.Point to size the text. It's working wonderfully on-screen, and even if Print it.
I've been asked to make a system that generates a PDF, and I got ComponentOne's PDF control. It has got similar interface to GDI+.
The problem is: Font sizes are not working. If I use GraphicsUnit.Point, the text is much smaller, and I am getting empty space below the text. When I use GraphicsUnit.World, the text is still small, but there's no extra empty space below the text.
I want to understand how to convert GraphicsUnit.World to GraphicsUnit.Point.
All help will be appreciated.
Thanks

After some Googeling and from what I know from personal experience with GDI+ and String drawing it comes down to DPI (Dots per Inch). Basically the different devices (and as far as GDI+ is concerned, PDF is probably a device) have different DPI values. Displays usually have something like 70 DPI. Printers use 72. I don't know what PDFs use, but it might be 100 (as this is a common value for device independence and would explain the smaller text).
Now, Points are defined as being 72 DPI. This is always true. What GDI+ should do, when drawing to a PDF with a different DPI is, to transform the string drawing accordingly. But this does not always work, especially with text.
The GraphicsUnit.World should (according to some googeling) be device independent and should look the same on all devices.

You're right, GraphicsUnit.World looks the same on print, and also on screen. My final solution was to use GraphicsUnit.World as the unit of measure, and shun points. I still don't know the conversion ratio, but I approximated the value till the look was okay.
For my purpose this was enough.