Applications, Threads, and Windows

What is the relationship between applications and windows? A typical Win32 application consists of one or more threads, which are basically parallel paths of execution. Think of threads as multitasking within a single application; for example, one thread in a word processing application may be processing user input, while another is busy sending a document to the printer.

A window is always "owned by" a thread; a thread may own one or more windows, or none at all. Finally, windows themselves are in a hierarchical relationship; some are top-level windows, others are subordinated to their parent windows.

There are many types of windows in Windows—no pun intended!. The most obvious, of course, is the large rectangular area that we typically associate with an application. Also obvious is that a dialog box is a window in its own right; it can be moved around, sometimes sized, maximized, or minimized just like the main window of an application. What is less obvious is that many elements displayed within main windows or dialogs are also windows themselves. Every button, edit box, scrollbar, listbox, icon, even the screen background itself is treated as a window by the operating system.

A very revealing exercise, if you have not done this before, is spending some time with the Spy++ application that comes with Visual C++. Use its Find Window command from the Spy menu and drag the finder tool around the screen to find out how even an apparently simple application window can have many window components.

Window Classes

The basic behavior of a window is defined by its window class. The window class carries information about the window's initial appearance; the default icon, cursor, and menu resource associated with the window; and perhaps most importantly, the address of a function called the window procedure. When an application processes messages, it usually does so by calling the Windows function DispatchMessage for each message received; DispatchMessage, in turn, calls the appropriate window procedure by checking the class of the window the message is for. It is the window procedure that actually processes messages sent to that window.

There are many standard window classes provided by Windows itself. These system global classes implement the functionality of common controls, for example. Any application can use these classes for its windows; for example, any application can implement edit controls by using the Edit window class.

Applications can also define their own window classes through the RegisterClass function. This enables programmers to implement window behavior that is not part of any of the system-supplied global classes. For example, this is how a typical application implements the functionality of its own main window and registers the main window's icon and menu resource.

Windows also enables subclassing and superclassing an existing class. Subclassing substitutes the window procedure for a window class with another. Subclassing is accomplished by changing the window procedure address through the SetWindowLong (instance subclassing) or SetClassLong (global subclassing) function. The difference? In the first case, only the behavior of a specific window changes; in the second case, the behavior of all windows of the specified class is affected.

NOTE: Global subclassing behaves differently in Win32 and 16-bit Windows (Win32s). In the Win32 case, it affects only windows under the control of the application doing the subclassing; in 16-bit windows, the effect is global, affecting the windows of every application.

Superclassing creates a new class based on an existing class, retaining its window procedure. To superclass a window class, an application retrieves class information using the GetClassInfo function, modifies the WNDCLASS structure thus received, and uses the modified structure in a call to RegisterClass. Through GetClassInfo, the application also obtains the address of the original window procedure, which it should retain; messages that the new window procedure does not process should be passed to this function.

Although the terminology is reminiscent of object-oriented terminology, the concept of a window class should not be confused with C++ concepts (or, in particular, concepts of the MFC library). The concept of window classes predates the use of object-oriented languages in Windows by several years.