Chapter 16 - Adding Graphics and Animation Effects

01
of 05

Introduction to GDI+

Graphic Animation

Our text, Microsoft Visual Basic .NET Step by Step starts chapter 16 this way:

In Visual Basic .NET, no drawing controls are provided ... instead, you're encouraged to use the GDI+ graphics services directly.

Well, Yah!! I guess if they don't give you a choice, that's a form of "encouragement". In any case, the subtitle of this chapter should be (and IS for this lesson), "Introduction to GDI+".

The book's Update Notes are a partial catalog of things in VB 6 that have been eliminated and the new GDI+ things in VB.NET that replace them. Two conclusions should be obvious:

  1. Virtually everything graphical that you used to be able to do in VB 6 has disappeared.
  2. The new graphical stuff in VB.NET is more powerful, flexible, and structured.

Microsoft's official documentation states that, "Microsoft Windows GDI+ is a class-based application programming interface (API) for C/C++ programmers." But it's not true! VB.NET is built on GDI+ as well. GDI+ can be used in all Windows-based applications including Microsoft's new Win64 platform.

But there's a significant learning curve if you've never used GDI+! Let's get started!

ps ... The illustration at the beginning of this article is slightly off topic because it's taken from an article about how to change the fundamental style of the forms in your system by adding your own update to the VB.NET Manifest. This is something that the book doesn't mention ... but you can read about it here in the article titled, Manifestly Xtra Pretty Forms.

02
of 05

Cooperating With GDI+

math coordinate
math coordinate.

Because this lesson makes frequent references to the examples in the book, please read chapter 16 and try the example programs before continuing.

The key to using GDI+ is cooperation. That is, learning to cooperate with GDI+. If you merge your programming smoothly into all the things that GDI+ can do for you, the results are wonderful! If you try to "fight the system" in your code, you'll have real difficulty.

I'm a canoeist and I'm reminded of a motto that I use when I'm shooting rapids in a river:

Ride the river. Don't let the river ride you!

When you're riding a river, that means using the currents and waves to move the canoe where you need it. When you're programming with GDI+, that means using software objects to do all the hard work. To make either of them work, the key is to anticipate what will happen. In programming with GDI+, a lot depends on picking the right event procedure for your graphics code. More on this later.

Or, to pick a different analogy, you might think of GDI+ as a whole factory full of robots, all pre-programmed to do graphical tasks for you. There are the

DrawLine robots and then there are the very specialized DrawBezier robots. Some robots need help from other robots to finish their work.

DrawPolygon can put a square on the screen. You want that square filled with color? You need the

Brush robot then!

03
of 05

The GDI+ Coordinate System

forms coordinate
forms coordinate.

Another thing that you need to get straight is the GDI+ coordinate system. If you have studied math and geometry, you may be used to a coordinate system that looks like this.

But GDI+ uses a forms based coordinate system where the "origin" is in a different corner. And, although you can assign negative numbers to the coordinates without generating an error, they're "off the form" and don't show up. While you're experimenting, you might want to try it.

04
of 05

Understanding the Flow of Events

Successful GDI+ programming requires a new style of thinking for some programmers due to the need for careful scheduling of events. For example, no directions are given for how to add the code into a program in the book's first example on page 425 (which simply draws a line). If you double click on a form to open a code window, the default event that is opened is the Form_Load event. If you then add that code to the Form1_Load event and run the program ... nothing happens. If you add a button to the form and move the same code to the Button1_Click event to try to get it to run, it works! But, as the book explains in the next paragraph, resizing the form erases the line. The book correctly points out that you must use the form's Paint event to get your line to be refreshed along with the form when necessary, but why is there no line at all when you use the Form1_Load event?

The answer is that the form is automatically repainted by the system AFTER the code to draw the line is executed - and your line doesn't get redrawn again. Gotcha's like this can be an unending source of confusion for GDI+ programmers.

To understand more about how Paint actually redraws a form, it's instructive to try another experiment. Instead of drawing a line or a shape, simply add a diagnostic Debug.Write statement to the form's Paint event. The code is on the next page.

05
of 05

The Code and Result of Monitoring the Paint Event

Paint

~~~~~~~~~~~~~~~~~~~~~~~~~
Dim paintcount As Integer = 0
Private Sub Form1_Paint( _
  ByVal sender As Object, _
  ByVal e As System.Windows.Forms.PaintEventArgs) _
  Handles MyBase.Paint
  paintcount += 1
  Debug.Write("Paint Event executed " _
    & CStr(paintcount) & vbCrLf)
End Sub
~~~~~~~~~~~~~~~~~~~~~~~~~

You will then see just when and how often the Paint event is called automatically as you resize, move, or minimize the window. In the My Moving Icon example in the book, because the timer is enabled from the first button click and never disabled, the form is repainted every 75 milliseconds no matter what else the program is doing. (This is why the example doesn't use a Paint event.)

Considerations like these can seriously impact the performance of your program ... or explain why it's not working the way you expect!