Does TextBox use GDI or GDI+

Question

Basically, I want to measure the text size in a TextBox, and I found out that TextRenderer gives me the correct values, while Graphics would give me wrong values. So that seems like TextBox should be using GDI to draw text, right?

However, wherever I read, I see that it's supposed to use GDI+. For example:

• Here http://microsoft.public.dotnet.framework.windowsforms.controls.narkive.com/yoHKjPut/text-rendering-accuracy-problem-in-textbox-richtextbox it says that TextBox and Buttons use GDI+.
• Here Why is Graphics.MeasureString() returning a higher than expected number? it says that default is "compatibility mode" that draws in GDI+

So why is it that I'm getting consistent results with TextRenderer and not with Graphics when it's supposed to be other way around?

Shaughnessy

How about you post some code that gives you the wrong values, and tell us what the right ones should be, and why? – Fetish

XY-Problem? Note that Graphics.MeasureString has various overloads,. If you use the right one it'll give you pretty good results. The simplest form is meant to bring back a box that is large enough per character and not meant to measure strings. Look it up! – Gadwall

Answer 1

All right, some more research have shown that there is a confusion of what is "Default".

When these sources talk about "Default", they talk about "Default(1)" as in "If no extra code is executed", not "Default(2)" as in "If no extra action is taken".

Because by "Default(2)", "Application.SetCompatibleTextRenderingDefault(false)" is added to the Program.cs file of a new proiject, which makes TextBox class use GDI for rendering, which is not the "Default(1)" for it, but in fact this is what happens if you, as a programmer, take no additional action.

This is basically what got me.

PS: I'm basing the assumtion that it's true by "Default(1)" on the accepted answer from this question UseCompatibleTextRendering property not created by designer when it is set to false

Shaughnessy

I have no idea what this means, even after reading it a couple of times. As the docs say, SetCompatibleTextRenderingDefault has a default value of false. If you call the method and explicitly set it to false, it will be false. If you do not call the method, it will be false. The only way it will be true is if you explicitly call the method and set it to true. Don't do that, leave it at the default. – Swanson

@CodyGray That's what I've read here #1297451 in the accepted answer. If that's false (that it is true by default) then I'm even more confused now – Shaughnessy

Answer 2

The .NET Framework uses GDI+ in most places. The Graphics class is a wrapper around GDI+.

However, WinForms also wraps native Win32 controls, which do not use GDI+. They use GDI. TextBox and RichTextBox are examples of this. They draw their text using GDI.

To measure GDI+ text, you will use Graphics.MeasureString (note the Graphics class there). To measure GDI text, you will use TextRenderer.MeasureText (note how it is not provided by the Graphics class).

Things do get slightly more complicated: some controls do use GDI+ for drawing purposes. The Button control is an example of this. Unless you have its FlatStyle set to System, it is owner-drawn by the .NET Framework, and that owner drawing is done using GDI+ (the graphics subsystem used by .NET). However, if you set the FlatStyle to System, the rendering is delegated to the native Win32 Button control, which uses GDI (like all native Win32 controls).

My suggestion is to use GDI (TextRenderer) whenever possible to draw text. If you use a control that implements the FlatStyle property, set it to System. Text drawn with GDI+ just looks lousy by comparison. As a bonus, you'll get controls that actually look native and blend in with the system. FlatStyle.System is the only way to get a button control that actually pulses and glows. The WinForms renderer doesn't implement this.

Swanson

And then it says "TextBox and Button both use GDI+ whereas RichTextBox uses GDI". You cannot state two opposite things in the same article and call it "containing correct answer", do you? It's like, a test asks you "Is statement X true, yes or no" and you answer "yes/no" and argue that you provided the right answer. – Shaughnessy

Hmm yeah, so it does. That is wrong. Maybe it was true before .NET 2.0, I can't remember that far back. Forget quoting it, then. I'll just answer the question. – Swanson

Yeah I guess something changed sometime ago and wasn't documented or announced properly and now this confusion happens – Shaughnessy

BTW, Wow, that button style is cool. Why isn't it default? I mean, it looks better! However, it seems to not display an image... is it a limitation of this kind of button (GDI can't draw images?) – Shaughnessy

@Shaughnessy The native Win32 button control does not have built-in support for images. Well, it does, but you can either have a button with an image OR a button with text—not both. In order to get an image AND text, you have to create an owner-draw button and draw the image yourself. The WinForms folks decided to take all drawing into their own hands, which makes the button even more customizable (e.g., custom foreground/background colors), but also makes it look ugly and non-native. – Swanson

You see the same problem with them MenuStrip/ToolStrip classes. They're drawn entirely in C# code and do not use the system renderer (even when you set the render style to "System" or whatever they call it). Thus, the drawing is forever frozen in time. The WinForms team tried to simulate the Office XP menus, which were new at the time, but those became obsolete with Vista. You'll never get Aero-style menus with the MenuStrip control, though. The workaround is to use the MainMenu and ToolBar controls, which actually wrap the Win32 menus/toolbars. You have to add them to the toolbox yourself. – Swanson

Answer 3

GDI+ error comes usually when we giving path for storing something in folder and that path is incorrect, meaning folder can not access or not able to find that path. So, just correct the path or allow folder security accessible.

Brittain