Webocreation

Monday, November 23, 2009

Outputting Text and Graphics

Chapter 7: Outputting Text and Graphics

In Windows 95 and Windows NT, text and graphics output is handled by the graphics device interface (GDI) dynamic-link library. The GDI ensures that Windows-based applications work with a wide variety of different printers, plotters, and displays.

This capability to work with a wide variety of output devices, often referred to as device independence, means that the developer does not have to deal with the differences between the types of output devices. Access to the GDI is provided primarily through the CDC class and its derivatives.

This chapter introduces you to some of the fundamental concepts of the GDI. You will learn how to output text and graphics to a device context (DC) as well as use a variety of drawing objects and drawing primitives that are provided by MFC.

Objectives

After completing this chapter, you will be able to:

® Describe a device context (DC).

® Explain the purpose of CDC, CPaintDC, and CClientDC.

® Output text to the view window.

® List and describe standard graphics device interface (GDI) objects.

® Output simple graphics objects, such as lines and rectangles.

® Use stock objects effectively in an application.

® Describe mapping modes.

® Describe ROP2 codes.

® Use the BitBlt function.

In order to ease the burden of outputting text and graphics to a large variety of different devices, Windows uses a construct called a device context. A device context is an abstract layer that your application writes to when generating graphics and text. Device contexts relieve you of the burden of having to write code for every output device available in the marketplace.

This section describes device contexts and how they work, and the MFC classes that you can use to draw to an output device.

This section includes the following topics:

Introducing Device Contexts

A device context (DC) is a data structure containing fields that describe the information that the GDI needs to know about the display surface as well as the context in which it is being used. In Windows, a DC does the following:

® Gives permission to an application to use an output device.

® Provides a link between a Windows-based application, a device driver, and an output device, such as a monitor or printer.

® Maintains current information about how to draw or paint to a window, such as the colors, brush or pen patterns, pen widths, and so on.

® Maintains a clipping region for a window, which limits the program output to the areas of the output device covered by the window.

Once you have a DC, you can use a variety of GDI objects to draw lines, geometric shapes, and text to a view in your application.

Device Contexts and MFC:
MFC encapsulates device context capabilities through the CDC class. The core of this class is the data member m_hDC, which represents a handle to a Windows DC.

The CDC class is a large one. It contains creation and initialization functions for a device context, as well as many general GDI operations, including drawing simple graphic objects such as lines, rectangles, and ellipses, as well as more sophisticated functions that operate on regions, bitmaps, and clipping areas.

To see an illustration that shows the object hierarchy for the CDC base class and its four derived classes, click this icon.




The OnDraw Function

The first place that a developer typically uses a device context is within the view's OnDraw function. AppWizard includes the OnDraw function when it creates the application. The OnDraw function looks similar to the following:

void CMyView::OnDraw(CDC* pDC)
{
CMyDoc* pDoc = GetDocument();
ASSERT_VALID(pDoc);

// TODO: add draw code for native data here

}

The OnDraw function is called when the view becomes stale and needs to be refreshed. Whenever a window or portion of a window needs to be repainted, the operating system sends it a WM_PAINT message with information on what portion of the window needs to be repainted. In the MFC framework, this information is given to CWnd::OnPaint, which creates a DC of the appropriate type and calls the OnDraw function for the view.

To see an illustration that shows how OnDraw represents a factoring of the common code that is used in the display (paint) operation (CWnd::OnPaint) and the print and print-preview operations (CView::OnPrint), click this icon.




Using OnDraw for the bulk of output coding ensures a high degree of consistency across print and display operations. A close similarity between what users see on the screen and what they get when printing is referred to as “what you see is what you get,” or WYSIWYG.

Accessing a DC in MFC


Two common methods are used to access a device context (DC) in an MFC application:

® Receiving a pointer to a CDC object as a function parameter.

® Creating a temporary, local CDC object.



Some message handlers receive a pointer to a CDC object that is used to perform display operations. If the handler receives just a pointer to a CDC object, then the handler does not have to release the DC or clean up the object.

For example, the following example code illustrates using only a pointer to a CDC object:

void CMyView::OnDraw(CDC* pDC)

{

// ...

// Draw a black dot at location 10,10

pDC->SetPixel(CPoint(10,10), RGB(0,0,0));



}



You can create a local DC object by using any of the CDC-derived classes. In the following example code, the handler draws a black dot at the location of a left-mouse-button-down event in the view:

void CMyView::OnLButtonDown(UINT nFlags, CPoint point)

{
CClientDC dc(this);
dc.SetPixel(point, RGB(0,0,0));
CView::OnLButtonDown(nFlags, point);
}

Note Because the DC was created on the stack, it is released by the DC-object destructor when the local object dc goes out of scope. This returns the resource and memory to the system.

No comments:

Post a Comment