GDI+ Graphics in Visual Basic .NET

Reflection of female hacker coding working hackathon at laptop
(Hero Images/Getty Images)

GDI+ is the way to draw shapes, fonts, images or generally anything graphic in Visual Basic .NET.

This article is the first part of a complete introduction to using GDI+ in Visual Basic .NET.

GDI+ is an unusual part of .NET. It was here before .NET (GDI+ was released with Windows XP) and it doesn't share the same update cycles as the .NET Framework. Microsoft's documentation usually states that Microsoft Windows GDI+ is an API for C/C++ programmers into the Windows OS.

But GDI+ also includes the namespaces used in VB.NET for software-based graphics programming.


But it's not the only graphics software provided by Microsoft, especially since Framework 3.0. When Vista and 3.0 were introduced, the totally new WPF was introduced with it. WPF is a high-level, hardware accelerated approach to graphics. As Tim Cahill, Microsoft WPF software team member, puts it, with WPF "you describe your scene using high-level constructs, and we’ll worry about the rest." And the fact that it's hardware accelerated means that you don't have to drag down the operation of your PC processor drawing shapes on the screen. Much of the real work is done by your graphics card.

We've been here before, however. Every "great leap forward" is usually accompanied by a few stumbles backward, and besides, it will take years for WPF to work its way through the zillions of bytes of GDI+ code.

That's especially true since WPF just about assumes that you're working with a high-powered system with lots of memory and a hot graphics card. That's why many PCs couldn't run Vista (or at least, use the Vista "Aero" graphics) when it was first introduced. So this series continues to be available on the site for any and all who continue to need to use it.

Good Ol' Code

GDI+ isn't something that you can drag onto a form like other components in VB.NET. Instead, GDI+ objects generally have to be added the old way -- by coding them from scratch! (Although, VB .NET does include a number of very handy code snippets that can really help you.)

To code GDI+, you use objects and their members from a number of .NET namespaces. (At the present time, these are actually just wrapper code for Windows OS objects which actually do the work.)


The namespaces in GDI+ are:


This is the core GDI+ namespace. It defines objects for basic rendering (fonts, pens, basic brushes, etc.) and the most important object: Graphics. We'll see more of this in just a few paragraphs.


This gives you objects for more advanced two-dimensional vector graphics. Some of them are gradient brushes, pen caps, and geometric transforms.


If you want to change graphical images - that is, change the palette, extract image metadata, manipulate metafiles, and so forth - this is the one you need.


To render images to the printed page, interact with the printer itself, and format the overall appearance of a print job, use the objects here.


You can use collections of fonts with this namespace.

Graphics Object

The place to start with GDI+ is the Graphics object. Although the things you draw show up on your monitor or a printer, the Graphics object is the "canvas" that you draw on.

But the Graphics object is also one of the first sources of confusion when using GDI+. The Graphics object is always associated with a particular device context. So the first problem that virtually every new student of GDI+ confronts is, "How do I get a Graphics object?"

There are basically two ways:

  1. You can use the e event parameter that is passed to the OnPaint event with the PaintEventArgs object. Several events pass the PaintEventArgs and you can use the to refer to the Graphics object that is already being used by the device context.
  1. You can use the CreateGraphics method for a device context to create a Graphics object.

Here's an example of the first method:

Protected Overrides Sub OnPaint( _

   ByVal e As System.Windows.Forms.PaintEventArgs)

   Dim g As Graphics = e.Graphics

   g.DrawString("About Visual Basic" & vbCrLf _

   & "and GDI+" & vbCrLf & "A Great Team", _

   New Font("Times New Roman", 20), _

   Brushes.Firebrick, 0, 0)


End Sub

Click Here to display the illustration

Add this into the Form1 class for a standard Windows Application to code it yourself.

In this example, a Graphics object is already created for the form Form1. All your code has to do is create a local instance of that object and use it to draw on the same form. Notice that your code Overrides the OnPaint method. That's why MyBase.OnPaint(e) is executed at the end. You need to make sure that if the base object (the one you're overriding) is doing something else, it gets a chance to do it. Often, your code works without this, but it's a good idea.


You can also get a Graphics object using the PaintEventArgs object handed to your code in the OnPaint and OnPaintBackground methods of a Form. The PrintPageEventArgs passed in a PrintPage event will contain a Graphics object for printing. It's even possible to get a Graphics object for some images. This can let you paint right on the image the same way you would paint on a Form or component.

Event Handler

Another variation of method one is to add an event handler for the Paint event for the form. Here's what that code looks like:

Private Sub Form1_Paint( _

   ByVal sender As Object, _

   ByVal e As System.Windows.Forms.PaintEventArgs) _

   Handles Me.Paint

   Dim g As Graphics = e.Graphics

   g.DrawString("About Visual Basic" & vbCrLf _

   & "and GDI+" & vbCrLf & "A Great Team", _

   New Font("Times New Roman", 20), _

   Brushes.Firebrick, 0, 0)

End Sub


The second method to get a Graphics object for your code uses a CreateGraphics method that is available with many components.

The code looks like this:

Private Sub Button1_Click( _

   ByVal sender As System.Object, _

   ByVal e As System.EventArgs) _

   Handles Button1.Click

   Dim g = Me.CreateGraphics

   g.DrawString("About Visual Basic" & vbCrLf _

   & "and GDI+" & vbCrLf & "A Great Team", _

   New Font("Times New Roman", 20), _

   Brushes.Firebrick, 0, 0)

End Sub

There are a couple of differences here. This is in the Button1.Click event because when Form1 repaints itself in the Load event, our graphics are lost. So we have to add them in a later event. If you code this, you'll notice that the graphics are lost when Form1 has to be redrawn. (Mimimize and maximize again to see this.) That's a big advantage to using the first method.

Most references recommend using the first method since your graphics will be repainted automatically. GDI+ can be tricky!