Multiple windows can be displayed at one time, can overlap one another, can be minimized/maximized or can even be hidden. The Windows desktop itself is a window, on top of which application windows are painted.

Graphical applications create at least one window, with the familiar parts as shown in the next image. The Windows operatings system manages all of these - title bar, menu bar, scroll bars and client area.

Classes
The code which defines a window is most often kept in binary file, typically with a .DLL extension (DLL - dynamic link library). The code, which defines all visual and functional aspects of a window, is said to define a window "class" - a template from which one or more copies can be made and placed on the desktop (or within other windows). Each copy of a class is called an "instance" of the class.

The Windows operating system provides a single, top level window class. Starting with that base class, programmers create customized window classes which differ visually and functionally from the base class. Languages such as C++ emphasize the creation of custom windows in designing graphical user interfaces.

This is not the focus of PowerBASIC, which emphasizes the use of pre-defined window classes that are installed as a part of the Windows operating system. The pre-defined window classes are commonly known as dialog windows and common controls.

Although PowerBASIC can be used to create custom windows, it is with these pre-defined windows that PowerBASIC is focused. It provides extensive tools for creating and mangaging both dialogs and common controls.

Handles
At the time it is created, every window (an instance of a class) is assigned a unique number by the Windows operating system. That unique number is called a "handle" and distinguishes the window from any other window that exists in the system.

Handles are a numeric data type Long (32 bits, 4 bytes).

As will become more obvious, the handle to a window is central to Windows and PowerBASIC programming concepts.

Custom Windows
Because PowerBASIC provides direct access to the use of Windows API, its applications can create custom windows to use for the grapical user interface. Windows created by directly calling API are said to have been created using SDK techniques, referring to the Software Develoment Kit (SDK) from Microsoft which describes how to use Windows API to create and manage windows.

However, as the next section describes, PowerBASIC has chosen to base its application interface windows on pre-defined dialog window classes.

Dialog Boxes
In addition to the top level, standard window class the Windows operating system installs with a pre-defined class of windows called "Dialog Boxes", or just "dialogs".

Dialogs are very similar to a custom window, in that both can have menus and contain child controls. However, because the dialogs are somewhat simpler to create and use, especially with respect to handling system messages, PowerBASIC has chosen to provide extensive support for using dialogs as the main windows of PowerBASIC applications. The collective statements for creating and managing dialogs, as well as the children controls placed in dialogs, are called Dynamic Dialog Technology (DDT).

Some PowerBASIC programmers chose to use DDT while others prefer the added control offerred by SDK style programming.

Common Controls
PowerBASIC dialog windows can act as a parent to smaller windows called controls, which are typically placed in the client area of a parent window.

Controls are the familiar buttons, textboxes or other smaller windows contained within the main window. Controls are typically used to get or display information.

The Windows operating system ships with a set of about 30 pre-defined controls which programmers may include in their PowerBASIC applications. At the MSDN site is a list of these "common controls", as they are called.

Here's the MSDN list of pre-defined controls. The Windows operating system pre-defines a class for each of these controls.

    Animation                  Images List              Scroll Bar
    Button                     IP Address               Static
    Combo Box                  List Box                 Status Bar
    ComboBoxEx                 List-View                SysLink
    Date and Time Picker       Month Calendar           Tab
    Drag List Box              Pager                    Toolbar
    Edit                       Progress Bar             Tooltip
    Flat Scroll Bar            Property Sheet           Trackbar
    Header                     ReBar                    Tree-View
    Hot Key                    Rich Edit                Up-Down

Any of these can be included in a PowerBASIC application by using SDK-style programming (direct calls to API).

PowerBASIC Common Control Support
However, because API can be somewhat difficult to use, PowerBASIC has chosen to provide special support for creating and managing selected controls. The "special support" refers to PowerBASIC statements and functions which simplify the creation and management of controls. These statements and functions handle the details of calling the Windows API, providing the user with a somewhat simplified programming interface.

Here's the list of controls directly supported by PowerBASIC:

Button	Frame	ImgButton	ListBox	StatusBar
Check3State	Graphic	ImgButtonX	ListView	TAB
Checkbox	Image	Label	Option	TextBox
ComboBox	ImageX	Line	Progress Bar	Toolbar
			Scrollbar	TreeView

Some of the controls supported by PowerBASIC are not on on the list of common controls, as listed at MSDN.

The explanation is that PowerBASIC has defined its own custom window classes, derived from one of pre-defined Windows control classes listed above. About half of the PowerBASIC controls fall into that category.

Here's a list of the PowerBASIC controls which are derivations from Windows common control.

Common Control	PowerBASIC Control
Edit control	textbox
Static control	graphic, image, imagex, label, line
Button control	button, check3state, checkbox, frame, imgbutton, imgbuttonx, option

As other tutorial sections will show, PowerBASIC common controls that are derived from the same WIndows common control share many common visual and functional features but differ in the specifics of interacting with a user.

If you have any suggestions or corrections, please let me know.