لطفا منتظر باشید ...
Painting Basics
Historically, Windows has been subdivided into three main components: the kernel, which handles the process and memory management; User, which handles the windowing interface and controls; and the Graphics Device Interface, or GDI, which performs the low-level drawing. In Windows CE, User and GDI are combined into the Graphics Windowing and Event handler, or GWE. At times, you might hear a Windows CE programmer talk about the GWE. The GWE is nothing really new—just a different packaging of standard Windows parts. In this book, I usually refer to the graphics portion of the GWE under its old name, GDI, to be consistent with standard Windows programming terminology.But whether you're programming for Windows CE, Windows 2000, or Windows XP, there's more to drawing than simply handling the WM_PAINT message. It's helpful to understand just when and why a WM_PAINT message is sent to a window.
Valid and Invalid Regions
Chapter 1, any drawing performed in response to a WM_PAINT message is couched in calls to BeginPaint and EndPaint. BeginPaint actually performs a number of actions. It marks the invalid region as valid, and it computes the clipping region. The clipping region is the area to which the painting action will be limited. BeginPaint then sends a WM_ERASEBACKGROUND message, if needed, to redraw the background, and it hides the caret—the text entry cursor—if it's displayed. Finally BeginPaint retrieves the handle to the display device context so that it can be used by the application. The EndPaint function releases the device context and redisplays the caret if necessary. If no other action is performed by a WM_PAINT procedure, you must at least call BeginPaint and EndPaint if only to mark the invalid region as valid.Alternatively, you can call to ValidateRect to blindly validate the region. But no drawing can take place in that case because an application must have a handle to the device context before it can draw anything in the window.Often an application needs to force a repaint of its window. An application should never post or send a WM_PAINT message to itself or to another window. Instead, you use the following function:
BOOL InvalidateRect (HWND hWnd, const RECT *lpRect, BOOL bErase);
Notice that InvalidateRect doesn't require a handle to the window's device context, only to the window handle itself. The lpRect parameter is the area of the window to be invalidated. This value can be NULL if the entire window is to be invalidated. The bErase parameter indicates whether the background of the window should be redrawn during the BeginPaint call as mentioned above. Note that unlike other versions of Windows, Windows CE requires that the hWnd parameter be a valid window handle.
Device Contexts
A device context, often referred to simply as a DC, is a tool that Windows uses to manage access to the display and printer, although for the purposes of this chapter I'll be talking only about the display. Also, unless otherwise mentioned, the explanation that follows applies to Windows in general and isn't specific to Windows CE.Windows applications never write directly to the screen. Instead, they request a handle to a display device context for the appropriate window and then, using the handle, draw to the device context. Windows then arbitrates and manages getting the pixels from the DC to the screen.
BeginPaint, which should be called only in a WM_PAINT message, returns a handle to the display DC for the window. An application usually performs its drawing to the screen during the WM_PAINT messages. Windows treats painting as a low-priority task, which is appropriate since having painting at a higher priority would result in a flood of paint messages for every little change to the display. Allowing an application to complete all its pending business by processing all waiting messages results in all the invalid regions being painted efficiently at once. Users don't notice the minor delays caused by the low priority of the WM_PAINT messages.Of course, there are times when painting must be immediate. An example of such a time might be when a word processor needs to display a character immediately after its key is pressed. To draw outside a WM_PAINT message, the handle to the DC can be obtained using this:
HDC GetDC (HWND hWnd);
GetDC returns a handle to the DC for the client portion of the window. Drawing can then be performed anywhere within the client area of the window because this process isn't like processing inside a WM_PAINT message; there's no clipping to restrict you from drawing in an invalid region.Windows CE supports another function that can be used to receive the DC. It is
HDC GetDCEx (HWND hWnd, HRGN hrgnClip, DWORD flags);
GetDCEx allows you to have more control over the device context returned. The new parameter, hrgnClip, lets you define the clipping region, which limits drawing to that region of the DC. The flags parameter lets you specify how the DC acts as you draw on it. Note that Windows CE doesn't support the following flags: DCX_PARENTCLIP, DCX_NORESETATTRS, DCX_LOCKWINDOWUPDATE, and DCX_VALIDATE.After the drawing has been completed, a call must be made to release the device context:
int ReleaseDC (HWND hWnd, HDC hDC);
Device contexts are a shared resource, and therefore an application must not hold the DC for any longer than necessary.While GetDC is used to draw inside the client area, sometimes an application needs access to the nonclient areas of a window, such as the title bar. To retrieve a DC for the entire window, make the following call:
HDC GetWindowDC (HWND hWnd);
As before, the matching call after the drawing has been completed for GetWindowDC is ReleaseDC.The DC functions under Windows CE are identical to the device context functions under Windows XP. This should be expected because DCs are the core of the Windows drawing philosophy. Changes to this area of the API would result in major incompatibilities between Windows CE applications and their desktop counterparts.
