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 WinMain calls CreateWindow, Windows creates the window and in the process sends the window procedure a WM_CREATE message. When WinMain calls ShowWindow, Windows sends the window procedure WM_SIZE and WM_SHOWWINDOW messages. When WinMain calls UpdateWindow, Windows sends the window procedure a WM_PAINT message.

TextOut (hdc, x, y, psText, iLength) ; An Introduction to GDI To paint the client area of your window, you use Windows' Graphics Device Interface (GDI) functions. TextOut (hdc, x, y, psText, iLength) ; TextOut writes a character string to the client area of the window. The psText argument is a pointer to the character string iLength 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. The hdc argument is a "handle to a device context” A handle, is simply a number that Windows uses for internal reference to an object. With that device context handle you are free to paint your client area and make it as beautiful or as ugly as you like.

Device Context(DC) DC is really just a data structure maintained internally byGDI. 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 Two functions are involved: BeginPaint and EndPaint. These two functions require the handle to the window, which is passed to the window procedure as an argument, and the address of a structure variable of type PAINTSTRUCT, which is defined in the WINUSER.H header file. Windows programmers usually name this structure variable ps and define it within the window procedure like so: PAINTSTRUCT ps ; While processing a WM_PAINT message, the window procedure first calls BeginPaint. The BeginPaint function generally causes the background of the invalid region to be erased in preparation for painting. The value returned from BeginPaint is the device context handle. This is commonly saved in a variable named hdc.

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

If a window procedure does not process WM_PAINT messages, it must pass the WM_PAINT message to DefWindowProc, which is the default window procedure located in Windows. DefWindowProc processes WM_PAINT messages with the following code: case WM_PAINT: BeginPaint (hwnd, &ps) ; EndPaint (hwnd, &ps) ; return 0 But don't do this: return 0 ; // WRONG !!!

DC: Method Two For more detail contact us 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 GetDC to obtain the handle and ReleaseDC after you're done with it: hdc = GetDC (hwnd) ; [use GDI functions] ReleaseDC (hwnd, hdc) ; Unlike BeginPaint,GetDC does not validate any invalid regions. If you need to validate the entire client area, you can call ValidateRect (hwnd, NULL) ; For more detail contact us