About the Author
Read an Excerpt
21: Graphics with GDI+This is the second of the two chapters in this book that covers the elements of interacting directly with the user, that is displaying information on the screen and accepting user input via the mouse or keyboard. In Chapter 9 we focused on Windows Forms, where we learnt how to display a dialog box or SDI or MDI window, and how to place various controls on it such as buttons, text boxes, and list boxes. In that chapter, the emphasis was very much on using the familiar predefined controls at a high level and relying on the fact that these controls are able to take full responsibility for getting themselves drawn on the display device. Basically, all you need to do is set the controls' properties and add event handlers for those user input events that are relevant to your application. The standard controls are powerful, and you can achieve a very sophisticated user interface entirely by using them. Indeed, they are by themselves quite adequate for the complete user interface for many applications, most notably dialog-type applications, and those with explorer style user interfaces.
However there are situations in which simply using controls doesn't give you the flexibility you need in your user interface. For example, you may want to draw text in a given font in a precise position in a window, or you may want to display images without using a picture box control, simple shapes or other graphics. A good example, is the Word for Windows program that I am using to write this chapter. At the top of the screen are various menus and toolbars that I can use to access different features of Word. Some of these menus and buttons bring up dialog boxes or even property sheets. That part of the user interface is what we covered in Chapter 9. However, the main part of the screen in Word for Windows is very different. It's an SDI window, which displays a representation of the document. It has text carefully laid out in the right place and displayed with a variety of sizes and fonts. Any diagrams in the document must be displayed, and if you're looking at the document in Print Layout view, the borders of the actual pages need to be drawn in too. None of this can be done with the controls from Chapter 9. To display that kind of output, Word for Windows must take direct responsibility for telling the operating system precisely what needs to be displayed where in its SDI window. How to do this kind of thing is subject matter for this chapter.
We're going to show you how to draw a variety of items including:
- Lines, simple shapes.
- Images from bitmap and other image files.
In the process, we'll also need to use a variety of helper objects including pens (used to define the characteristics of lines), brushes (used to define how areas are filled in – for example, what color the area is and whether it is solid, hatched, or filled according to some other pattern), and fonts (used to define the shape of characters of text). We'll also go into some detail on how devices interpret and display different colors.
The code needed to actually draw to the screen is often quite simple, and it relies on a technology called GDI+. GDI+ consists of the set of .NET base classes that are available for the purpose of carrying out custom drawing on the screen. These classes are able to arrange for the appropriate instructions to be sent to the graphics device drivers to ensure the correct output is placed on the monitor screen (or printed to a hard copy). Just as for the rest of the .NET base classes, the GDI+ classes are based on a very intuitive and easy to use object model.
Although the GDI+ object model is conceptually fairly simple we still need a good understanding of the underlying principles behind how Windows arranges for items to be drawn on the screen in order to draw effectively and efficiently using GDI+.
This chapter is broadly divided into two main sections. In the first two-thirds of the chapter we will
explore the concepts behind GDI+ and examine how drawing takes place, which means that this part of
the chapter will be quite theoretical, with the emphasis on understanding the concepts. There will be
quite a few samples, almost all of them very small applications that display specific hard-coded items
(mostly simple shapes such as rectangles and ellipses). Then for the last third of the chapter we change
tack and concentrate on working through a much longer sample, called CapsEditor, which displays
the contents of a text file and allows the user to make some modifications to the displayed data. The
purpose of this sample, is to show how the principles of drawing should be put into practice in a real
application. The actual drawing itself usually requires little code – the GDI+ classes work at quite a high
level, so in most cases only a couple of lines of code are required to draw a single item (for example, an
image or a piece of text). However, a well designed application that uses GDI+ will need to do a lot of
additional work behind the scenes, that is it must ensure that the drawing takes place efficiently, and
that the screen is updated when required, without any unnecessary drawing taking place. (This is
important because most drawing work carries a very big performance hit for applications.) The
CapsEditor sample shows how you'll typically need to do much of this background management.
The GDI+ base class library is huge, and we will scarcely scratch the surface of its features in this
chapter. That's a deliberate decision, because trying to cover more than a tiny fraction of the classes,
methods and properties available would have effectively turned this chapter into a reference guide that
simply listed classes and so on. We believe it's more important to understand the fundamental principles
involved in drawing; then you will be in a good position to explore the classes available yourself. (Full
lists of all the classes and methods available in GDI+ are of course available in the MSDN
documentation.) Developers coming from a VB background, in particular, are likely to find the concepts
involved in drawing quite unfamiliar, since VB's focus lies so strongly in controls that handle their own
painting. Those coming from a C++/MFC background are likely to be in more comfortable territory
since MFC does require developers to take control of more of the drawing process, using GDI+'s
predecessor, GDI. However, even if you have a good background in GDI, you'll find a lot of the
material is new. GDI+ does actually sit as a wrapper around GDI, but nevertheless GDI+ has an object
model which hides many of the workings of GDI very effectively. In particular, GDI+ replaces GDI's
largely stateful model in which items were selected into a device context with a more stateless one, in
which each drawing operation takes place independently. A
Graphics object (representing the device
context) is the only object that persists between drawing operations.
By the way, in this chapter we'll use the terms drawing and painting interchangeably to describe the process of displaying some item on the screen or other display device.
Before we get started we will quickly list the main namespaces you'll find in the GDI+ base classes. They are...
...Almost all the classes, structs and so on. we use in this chapter will be taken from the
Understanding Drawing PrinciplesIn this section, we'll examine the basic principles that we need to understand in order to start drawing to the screen. We'll start by giving an overview of GDI, the underlying technology on which GDI+ is based, and see how it and GDI+ are related. Then we'll move on to a couple of simple samples.
GDI and GDI+In general, one of the strengths of Windows – and indeed of modern operating systems in general – lies in their ability to abstract the details of particular devices away from the developer. For example, you don't need to understand anything about your hard drive device driver in order to programmatically read and write files to disk; you simply call the appropriate methods in the relevant .NET classes (or in pre-.NET days, the equivalent Windows API functions). This principle is also very true when it comes to drawing. When the computer draws anything to the screen, it does so by sending instructions to the video card telling it what to draw and where. The trouble is that there are many hundreds of different video cards on the market, many of them made by different manufacturers, and most of which have different instruction sets and capabilities. The way you tell one video card to draw, for example a simple line or a character string may involve different instructions from how you would tell a different video card to draw exactly the same thing. If you had to take that into account, and write specific code for each video driver in an application that drew something to the screen, writing the application would be an almost impossible task. Which is why the Windows Graphical Device Interface (GDI) has always been around since the earliest versions of Windows....
Table of Contents
- Chapter 1: .NET Architecture
- Chapter 2: Introduction to C#
- Chapter 3: C# Basics
- Chapter 4: Classes and Inheritance
- Chapter 5: Object Oriented C#
- Chapter 6: Advanced C# Topics
- Chapter 7: C# and the Base Classes
- Chapter 8: Programming in the .NET Environment
- Chapter 9: Windows Applications
- Chapter 10: Assemblies
- Chapter 11: Data Access with .NET
- Chapter 12: Viewing .NET Data
- Chapter 13: XML
- Chapter 14: File and Registry Operations
- Chapter 15: Working with the Active Directory
- Chapter 16: ASP.NET Pages
- Chapter 17: Web Services
- Chapter 18: Custom Controls
- Chapter 19: COM Interoperability
- Chapter 20: COM+ Services
- Chapter 21: Graphics with GDI+
- Chapter 22: Accessing the Internet
- Chapter 23: Distributed Applications with .NET Remoting
- Chapter 24: Windows Services
- Chapter 25: NET Security
- Appendix A: C# for C++ Developers
- Appendix B: C# for Java Developers
- Appendix C: C# for VB6 Developers
- Appendix D: C# Compilation Options
- Chapter 1: .NET Architecture