Queued and Nonqueued Messages The queued messages are

  • Slides: 8
Download presentation
Queued and Nonqueued Messages The queued messages are primarily those that result from user

Queued and Nonqueued Messages The queued messages are primarily those that result from user input in the form of keystrokes (such as the WM_KEYDOWN and WM_KEYUP messages), characters that result from keystrokes (WM_CHAR), mouse movement (WM_MOUSEMOVE), and mouse−button clicks (WM_LBUTTONDOWN). Queued messages also include the timer message (WM_TIMER), the repaint message (WM_PAINT), and the quit message (WM_QUIT). Visit for more Learning Resources

 Nonqueued messages Often result from calling certain Windows functions. For example, when Win.

Nonqueued messages Often result from calling certain Windows functions. For example, when Win. Main calls Create. Window, Windows creates the window and in the process sends the window procedure a WM_CREATE message.

An Introduction to GDI To paint the client area of your window, you use

An Introduction to GDI To paint the client area of your window, you use Windows' Graphics Device Interface (GDI) functions. Text. Out (hdc, x, y, ps. Text, i. Length) ; Text. Out writes a character string to the client area of the window. The ps. Text argument is a pointer to the character string i. Length is the length of the string in characters. The x and y arguments define the starting position of the character string in the client area.

 Device Context(DC) DC is really just a data structure maintained internally by. GDI.

Device Context(DC) DC is really just a data structure maintained internally by. GDI. A device context is associated with a particular display device, such as a video display or a printer. For a video display, a device context is usually associated with a particular window on the display.

Getting a Device Context Handle Method One-use this method when you process WM_PAINT messages

Getting a Device Context Handle Method One-use this method when you process WM_PAINT messages Two functions are involved: Begin. Paint and End. Paint. These two functions require the handle to the window, which is passed to the window procedure as an argument,

 The program may then use GDI functions, such as Text. Out, that require

The program may then use GDI functions, such as Text. Out, that require the handle to the device context. A call to End. Paint releases the device context handle. Typically, processing of the WM_PAINT message looks like this: case WM_PAINT: hdc = Begin. Paint (hwnd, &ps) ; [use GDI functions] End. Paint (hwnd, &ps) ;

 If a window procedure does not process WM_PAINT messages, it must pass the

If a window procedure does not process WM_PAINT messages, it must pass the WM_PAINT message to Def. Window. Proc, which is the default window procedure located in Windows. Def. Window. Proc processes WM_PAINT messages with the following code: case WM_PAINT: Begin. Paint (hwnd, &ps) ; End. Paint (hwnd, &ps) ; return 0

DC: Method Two It useful to paint part of the client area (for other

DC: Method Two It useful to paint part of the client area (for other purposes )while processing messages other than WM_PAINT To get a handle to the device context of the client area of the window, you call Get. DC to obtain the handle and Release. DC after you're done with it: hdc = Get. DC (hwnd) ; [use GDI functions] Release. DC (hwnd, hdc) ; Unlike Begin. Paint, Get. DC does not validate any invalid regions. If you need to validate the entire client area, you can call Validate. Rect (hwnd, NULL) ; For more detail contact us