• A previously hidden area of the window is brought into view when a user moves a window or uncovers a window.
• The user resizes the window (if the window class style has the CS_HREDRAW and CW_VREDRAW bits set).
• The program uses the ScrollWindow or ScrollDC function to scroll part of its client area.
• The program uses the InvalidateRect or InvalidateRgn function to explicitly generate a WM_PAINT message.

In some cases when part of the client area is temporarily written over, Windows attempts to save an area of the display and restore it later. This is not always successful. Windows may sometimes post a WM_PAINT message when:

• Windows removes a dialog box or message box that was overlaying part of the window.
• A menu is pulled down and then released.
• A tool tip is displayed.

In a few cases, Windows always saves the area of the display it overwrites and then restores it. This is the case whenever:

• The mouse cursor is moved across the client area.
• An icon is dragged across the client area.

Dealing with WM_PAINT message requires that you alter the way you think about how you write to the video display. Your program should be structured so that it accumulates all the information necessary to paint the client area but paints only “on demand”—when Windows sends the window procedure a WM_PAINT message. If your program needs to update its client area at some other time, it can force Windows to generate this WM_PAINT message. This may seem a roundabout method of displaying something on the screen, but the structure of your program will benefit from it.

Programmers new to Windows are sometimes confused about the distinction between the window class and the window and why all the characteristics of a window can’t be specified in one shot. Actually, dividing the information in this way is quite convenient. For example, all push-button windows are created based on the same window class. The window procedure associated with this window class is located inside Windows itself, and it is responsible for processing keyboard and mouse input to the push button and defining the button’s visual appearance on the screen. All push buttons work the same way in this respect. But not all push buttons are the same. They almost certainly have different sizes, different locations on the screen, and different text strings. These latter characteristics are part of the window definition rather than the window class definition.

While the information passed to the RegisterClass function is specified in a data structure, the information passed to the CreateWindow function is specified as separate arguments to the function. Here’s the CreateWindow call

hwnd = CreateWindow (szAppName,                  // window class name
TEXT (“The Hello Program”), // window caption
WS_OVERLAPPEDWINDOW,        // window style
CW_USEDEFAULT,              // initial x position
CW_USEDEFAULT,              // initial y position
CW_USEDEFAULT,              // initial x size
CW_USEDEFAULT,              // initial y size
NULL,                       // parent window handle
NULL,                       // window menu handle
hInstance,                  // program instance handle
NULL) ;                     // creation parameters

szAppName — > “window class name”. The name of the window class the program just registered

The window created by this program is a normal overlapped window. It will have a title bar; a system menu button to the left of the title bar; a thick window-sizing border; and minimize, maximize, and close buttons to the right of the title bar. That’s a standard style for windows, and it has the name WS_OVERLAPPEDWINDOW, which appears as the “window style” parameter in CreateWindow. If you look in WINUSER.H, you’ll find that this style is a combination of several bit flags:

#define WS_OVERLAPPEDWINDOW (WS_OVERLAPPED     | \
WS_CAPTION        | \
WS_SYSMENU        | \
WS_THICKFRAME     | \
WS_MINIMIZEBOX    | \
WS_MAXIMIZEBOX)
The “window caption” is the text that will appear in the title bar of the window.

The arguments marked “initial x position” and “initial y position” specify the initial position of the upper left corner of the window relative to the upper left corner of the screen. By using the identifier CW_USEDEFAULT for these parameters, we are indicating that we want Windows to use the default position for an overlapped window. (CW_USEDEFAULT is defined as 0×80000000.) By default, Windows positions successive newly created windows at stepped horizontal and vertical offsets from the upper left corner of the display. Similarly, the “initial x size” and “initial y size” arguments specify the initial width and height of the window. The CW_USEDEFAULT identifier again indicates that we want Windows to use a default size for the window.

The argument marked “parent window handle” is set to NULL when creating a “top-level” window, such as an application window. Normally, when a parent-child relationship exists between two windows, the child window always appears on the surface of its parent. An application window appears on the surface of the desktop window, but you don’t need to find out the desktop window’s handle to call CreateWindow.

The “window menu handle” is also set to NULL because the window has no menu. The “program instance handle” is set to the instance handle passed to the program as a parameter of WinMain. Finally, a “creation parameters” pointer is set to NULL. You could use this parameter to point to some data that you might later want to reference in your program.

The CreateWindow call returns a handle to the created window. This handle is saved in the variable hwnd, which is defined to be of type HWND (“handle to a window”). Every window in Windows has a handle. Your program uses the handle to refer to the window. Many Windows functions require hwnd as an argument so that Windows knows which window the function applies to. If a program creates many windows, each has a different handle. The handle to a window is one of the most important handles that a Windows program (pardon the expression) handles.

# Preprocessor directives are lines included in the code of our programs that are not program statements but directives for the preprocessor. These lines are always preceded by a hash sign (#). The preprocessor is executed before the actual compilation of code begins, therefore the preprocessor digests all these directives before any code is generated by the statements.

These preprocessor directives extend only across a single line of code. As soon as a newline character is found, the preprocessor directive is considered to end. No semicolon (;) is expected at the end of a preprocessor directive. The only way a preprocessor directive can extend through more than one line is by preceding the newline character at the end of the line by a backslash (\).

WINDOWS.H is a master include file that includes other Windows header files, some of which also include other header files. The most important and most basic of these header files are:

• WINDEF.H Basic type definitions.
• WINNT.H Type definitions for Unicode support.
• WINBASE.H Kernel functions.
• WINUSER.H User interface functions.
• WINGDI.H Graphics device interface functions.

These header files define all the Windows data types, function calls, data structures, and constant identifiers. They are an important part of Windows documentation. You might find it convenient to use the Find In Files option from the Edit menu in the Visual C++ Developer Studio to search through these header files. You can also open the header files in the Developer Studio and examine them directly.

The entry point to a Windows program is WinMain

Looks Like this

int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow)

WINAPI must be included because windows expects a WinMain that is of the _stdcall calling convention, not the default _cdecl.

The first parameter HINSTANCE hInstance is a instance handle.  Handle is simply a number that an application uses to identify something. In this case, the handle uniquely identifies the program. It is required as an argument to some other Windows function calls. In early versions of Windows, when you ran the same program concurrently more than once, you created multiple instances of that program. All instances of the same application shared code and read-only memory (usually resources such as menu and dialog box templates). A program could determine if other instances of itself were running by checking the hPrevInstance Second parameter. It could then skip certain chores and move some data from the previous instance into its own data area.

In the 32-bit versions of Windows, this concept has been abandoned. The second parameter to WinMain is always NULL (defined as 0).

The third parameter to PSTR szCmdLine is the command line used to run the program. Some Windows applications use this to load a file into memory when the program is started.

The fourth parameter to int iCmdShow indicates how the program should be initially displayed—either normally or maximized to fill the window, or minimized to be displayed in the task list bar.