When Microsoft introduced Windows 1.0 in 1985, it was the most sophisticated solution yet devised to go beyond the limitations of DOS. Back then, Windows ran in real mode, but even so, it was able to move memory blocks around in physical memory—a prerequisite for multitasking—in a way that was not quite transparent to applications but almost tolerable.

Multitasking makes a lot more sense in a graphical windowing environment than it does in a command-line single-user operating system. For example, in classical command-line UNIX, it is possible to execute programs off the command line so that they run in the background. However, any display output from the program must be redirected to a file or the output will get mixed up with whatever else the user is doing.

A windowing environment allows multiple programs to run together on the same screen. Switching back and forth becomes trivial, and it is also possible to quickly move data from one program to another; for example, to imbed a picture created in a drawing program into a text file maintained by a word processing program. Data transfer has been supported in various ways under Windows, first with the clipboard, later through Dynamic Data Exchange (DDE), and now through Object Linking and Embedding (OLE).

Yet the multitasking implemented in the early versions of Windows was not the traditional preemptive time-slicing found in multiuser operating systems. Those operating systems use a system clock to periodically interrupt one task and restart another. The 16-bit versions of Windows supported something called “nonpreemptive multitasking.” This type of multitasking is made possible because of the message-based architecture of Windows. In the general case, a Windows program sits dormant in memory until it receives a message. These messages are often the direct or indirect result of user input through the keyboard or mouse. After processing the message, the program returns control back to Windows.

The 16-bit versions of Windows did not arbitrarily switch control from one Windows program to another based on a timer tick. Instead, any task switching took place when a program had finished processing a message and had returned control to Windows. This nonpreemptive multitasking is also called “cooperative multitasking” because it requires some cooperation on the part of applications. One Windows program could tie up the whole system if it took a long time processing a message.

Although nonpreemptive multitasking was the general rule in 16-bit Windows, some forms of preemptive multitasking were also present. Windows used preemptive multitasking for running DOS programs and also allowed dynamic-link libraries to receive hardware timer interrupts for multimedia purposes.

The 16-bit Windows included several features to help programmers solve—or at least cope with—the limitations of nonpreemptive multitasking. The most notorious is, of course, the hourglass mouse cursor. This is not a solution, of course, but just a way of letting the user know that a program is busy working on a lengthy job and the system will be otherwise unusable for a little awhile. Another partial solution is the Windows timer, which allows a program to receive a message and do some work at periodic intervals. The timer is often used for clock applications and animation.

The main application window of an MDI program is conventional: it has a title bar, a menu, a sizing border, a system menu icon, and minimize/maximize/close buttons. The client area, however, is often called a “workspace” and is not directly used to display program output. This workspace contains zero or more child windows, each of which displays a document.

These child windows look much like normal application windows and much like the main application window of an MDI program. They too have a title bar, a sizing border, a system menu icon, minimize/maximize/close buttons, and possibly scroll bars. None of the document windows has a menu, however. The menu on the main application window applies to the document windows.

At any one time, only one document window is active (indicated by a highlighted title bar), and it appears in front of all the other document windows. All the document child windows are clipped to the workspace area and never appear outside the application window.

At first, MDI seems a fairly straightforward job for the Windows programmer. All you need to do is create a WS_CHILD window for each document, making the program’s main application window the parent of the document window. But with a little exploration of existing MDI applications, you’ll find some complications that require difficult code.

• An MDI document window can be minimized. A short title bar with an icon appears at the bottom of the workspace. Generally, an MDI application will use different icons for the main application window and each type of document window.
• An MDI document window can be maximized. In this case, the title bar of the document window (normally used to show the filename of the document in the window) disappears and the filename appears appended to the application name in the application window’s title bar. The system menu icon of the document window becomes the first item in the top-level menu of the application window. The button to close the document window becomes the last item in the top-level menu and appears to the far right.
• The system keyboard accelerator to close a document window is the same as that to close the main window, except that the Ctrl key is used rather than Alt. That is, Alt-F4 closes the application window, while Ctrl-F4 closes the document window. In addition, Ctrl-F6 switches among the child document windows within the active MDI application. Alt-Spacebar invokes the system menu of the main window, as usual. Alt– (minus) invokes the system menu of the active child document window.
• When using the cursor keys to move among items on the menu, control normally passes from the system menu to the first item on the menu bar. In an MDI application, control passes from the application system menu to the active document system menu to the first item on the menu bar.
• If the application is capable of supporting several types of child windows (for example, the worksheet and chart documents in Microsoft Excel), the menu should reflect the operations associated with that type of document. This requires that the program change the menu when a different document window becomes active. In addition, when no document window exists, the menu should be stripped down to only those operations involved in opening or creating a new document.
• The top-level menu bar has an item called Window. By convention, this is the last item on the top-level menu bar except for Help. The Window submenu generally has options to arrange the document windows within the workspace. Document windows can be “cascaded” from the upper left or “tiled” so that each document window is fully visible. This submenu also has a list of all the document windows. Selecting one moves that document window to the foreground.

The Caret (Not the Cursor)

When you type text into a program, generally a little underline, vertical bar, or box shows you where the next character you type will appear on the screen. You may know this as a “cursor,” but you’ll have to get out of that habit when programming for Windows. In Windows, it’s called the “caret.” The word “cursor” is reserved for the little bitmap image that represents the mouse position.

There are five essential caret functions:

• CreateCaret Creates a caret associated with a window.
• SetCaretPos Sets the position of the caret within the window.
• ShowCaret Shows the caret.
• HideCaret Hides the caret.
• DestroyCaret Destroys the caret.

There are also functions to get the current caret position (GetCaretPos) and to get and set the caret blink time (GetCaretBlinkTime and SetCaretBlinkTime).

In Windows, the caret is customarily a horizontal line or box that is the size of a character, or a vertical line that is the height of a character. The vertical line caret is recommended when you use a proportional font such as the Windows default system font. Because the characters in a proportional font are not of a fixed size, the horizontal line or box can’t be set to the size of a character.

If you need a caret in your program, you should not simply create it during the WM_CREATE message of your window procedure and destroy it during the WM_DESTROY message. The reason this is not advised is that a message queue can support only one caret. Thus, if your program has more than one window, the windows must effectively share the same caret.

This is not as restrictive as it sounds. When you think about it, the display of a caret in a window makes sense only when the window has the input focus. Indeed, the existence of a blinking caret is one of the visual cues that allows a user to recognize that he or she may type text into a program. Since only one window has the input focus at any time, it doesn’t make sense for multiple windows to have carets blinking all at the same time.

A program can determine if it has the input focus by processing the WM_SETFOCUS and WM_KILLFOCUS messages. As the names imply, a window procedure receives a WM_SETFOCUS message when it receives the input focus and a WM_KILLFOCUS message when it loses the input focus. These messages occur in pairs: A window procedure will always receive a WM_SETFOCUS message before it receives a WM_KILLFOCUS message, and it always receives an equal number of WM_SETFOCUS and WM_KILLFOCUS messages over the course of the window’s lifetime.

The main rule for using the caret is simple: a window procedure calls CreateCaret during the WM_SETFOCUS message and DestroyWindow during the WM_KILLFOCUS message.

There are a few other rules: The caret is created hidden. After calling CreateCaret, the window procedure must call ShowCaret for the caret to be visible. In addition, the window procedure must hide the caret by calling HideCaret whenever it draws something on its window during a message other than WM_PAINT. After it finishes drawing on the window, the program calls ShowCaret to display the caret again. The effect of HideCaret is additive: if you call HideCaret several times without calling ShowCaret, you must call ShowCaret the same number of times before the caret becomes visible again.

Windows programs can usually ignore WM_DEADCHAR and WM_SYSDEADCHAR messages, but you should definitely know what dead characters are and how they work.

On some non-U.S. English keyboards, certain keys are defined to add a diacritic to a letter. These are called “dead keys” because they don’t generate characters by themselves. For instance, when a German keyboard is installed, the key that is in the same position as the +/= key on a U.S. keyboard is a dead key for the grave accent (`) when shifted and the acute accent (´) when unshifted.

When a user presses this dead key, your window procedure receives a WM_DEADCHAR message with wParam equal to ASCII or Unicode code for the diacritic by itself. When the user then presses a letter key that can be written with this diacritic (for instance, the A key), the window procedure receives a WM_CHAR message where wParam is the ANSI code for the letter `a’ with the diacritic.

Thus, your program does not have to process the WM_DEADCHAR message because the WM_CHAR message gives the program all the information it needs. The Windows logic even has built-in error handling: If the dead key is followed by a letter that can’t take a diacritic (such as `s’), the window procedure receives two WM_CHAR messages in a row—the first with wParam equal to the ASCII code for the diacritic by itself (the same wParam value delivered with the WM_DEADCHAR message) and the second with wParam equal to the ASCII code for the letter `s’.

Of course, the best way to get a feel for this is to see it in action. You need to load a foreign keyboard that uses dead keys, such as the German keyboard that I described earlier. You do this in the Control Panel by selecting Keyboard and then the Language tab. Then you need an application that shows you the details of every keyboard message a program can receive.

The messages that an application receives from Windows about keyboard events distinguish between keystrokes and characters. This is in accordance with the two ways you can view the keyboard.

First, you can think of the keyboard as a collection of keys. The keyboard has only one key labeled “A.” Pressing that key is a keystroke. Releasing that key is also considered a keystroke. But the keyboard is also an input device that generates displayable characters or control characters. The “A” key can generate several different characters depending on the status of the Ctrl, Shift, and Caps Lock keys. Normally, the character is a lowercase “a.” If the Shift key is down or Caps Lock is toggled on, the character is an uppercase “A.” If Ctrl is down, the character is a Ctrl-A (which has meaning in ASCII but in Windows is probably a keyboard accelerator if anything). On some keyboards, the “A” keystroke might be preceded by a dead-character key or by Shift, Ctrl, or Alt in various combinations. The combinations could generate a lowercase or uppercase letter with an accent mark, such as à, á, â, ã, Ä, or Å.

For keystroke combinations that result in displayable characters, Windows sends a program both keystroke messages and character messages. Some keys do not generate characters. These include the shift keys, the function keys, the cursor movement keys, and special keys such as Insert and Delete. For these keys, Windows generates only keystroke messages.

As the user presses and releases keys on the keyboard, Windows and the keyboard device driver translate the hardware scan codes into formatted messages. However, these messages are not placed in an application’s message queue right away. Instead, Windows stores these messages in something called the system message queue. The system message queue is a single message queue maintained by Windows specifically for the preliminary storage of user input from the keyboard and the mouse. Windows will take the next message from the system message queue and place it in an application’s message queue only when a Windows application has finished processing a previous user input message.

The reasons for this two-step process—storing messages first in the system message queue and then passing them to the application message queue—involves synchronization. As we just learned, the window that is supposed to receive keyboard input is the window with the input focus. A user can be typing faster than an application can handle the keystrokes, and a particular keystroke might have the effect of switching focus from one window to another. Subsequent keystrokes should then go to another window. But they won’t if the subsequent keystrokes have already been addressed with a destination window and placed in an application message queue.

Window procedure should be prepared to update the entire client area whenever it receives a WM_PAINT message, it often needs to update only a smaller area, most often a rectangular area within the client area. This is most obvious when a dialog box overlies part of the client area. Repainting is required only for the rectangular area uncovered when the dialog box is removed.

That area is known as an “invalid region” or “update region.” The presence of an invalid region in a client area is what prompts Windows to place a WM_PAINT message in the application’s message queue. Your window procedure receives a WM_PAINT message only if part of your client area is invalid.

Windows internally maintains a “paint information structure” for each window. This structure contains, among other information, the coordinates of the smallest rectangle that encompasses the invalid region. This is known as the “invalid rectangle.” If another region of the client area becomes invalid before the window procedure processes a pending WM_PAINT message, Windows calculates a new invalid region (and a new invalid rectangle) that encompasses both areas and stores this updated information in the paint information structure. Windows does not place multiple WM_PAINT messages in the message queue.

A window procedure can invalidate a rectangle in its own client area by calling InvalidateRect. If the message queue already contains a WM_PAINT message, Windows calculates a new invalid rectangle. Otherwise, it places a WM_PAINT message in the message queue. A window procedure can obtain the coordinates of the invalid rectangle when it receives a WM_PAINT message (as we’ll see later in this chapter). It can also obtain these coordinates at any other time by calling GetUpdateRect.

After the window procedure calls BeginPaint during the WM_PAINT message, the entire client area is validated. A program can also validate any rectangular area within the client area by calling the ValidateRect function. If this call has the effect of validating the entire invalid area, then any WM_PAINT message currently in the queue is removed.

Windows programs call the function UpdateWindow during initialization in WinMain shortly before entering the message loop. Windows takes this opportunity to send the window procedure its first WM_PAINT message. This message informs the window procedure that the client area must be painted. Thereafter, that window procedure should be ready at almost any time to process additional WM_PAINT messages and even to repaint the entire client area of the window if necessary. A window procedure receives a WM_PAINT message whenever one of the following events occurs:

• 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.

The window class defines general characteristics of a window. By using that window class we can create many different windows. We can create a window by calling CreateWindow.

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.

The MessageBox function is designed to display short messages.

Syntax

int MessageBox(
HWND hWnd,
LPCTSTR lpText,
LPCTSTR lpCaption,
UINT uType
);

Parameters

hWnd –> Handle to the owner window of the message box to be created. If this parameter is NULL, the message box has no owner window.

lpText –> Pointer to a null-terminated string that contains the message to be displayed. If the string consists of more than one line, you can separate the lines using a carriage return and/or linefeed character between each line.

lpCaption –> Pointer to a null-terminated string that contains the dialog box title. If this parameter is NULL, the default title is Error.

uType –> Specifies the contents and behavior of the dialog box. This parameter can be a combination of flags from the following groups of flags.

You can pick one constant from the first set to indicate what buttons you wish to appear in the dialog box:

• #define MB_OK                       0x00000000L
• #define MB_OKCANCEL                 0x00000001L
• #define MB_ABORTRETRYIGNORE         0x00000002L
• #define MB_YESNOCANCEL              0x00000003L
• #define MB_YESNO                    0x00000004L
• #define MB_RETRYCANCEL              0x00000005L

When you set the fourth argument to 0 in HELLOMSG, only the OK button appears.

Return Value

If a message box has a Cancel button, the function returns the IDCANCEL value if either the ESC key is pressed or the Cancel button is selected. If the message box has no Cancel button, pressing ESC has no effect.

If the function fails, the return value is zero. To get extended error information, call GetLastError

If the function succeeds, the return value is one of the following menu-item values.

#include <windows.h>

int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
PSTR szCmdLine, int iCmdShow)
{
MessageBox (NULL, TEXT (“Hello, vdiscussion.com”), TEXT (“Vdiscussion.com”), 0) ;

return 0 ;
}

Output

Helloprogramoutput