PowerBASIC Information Center Tutorials
These tutorials were written to help you get a quick, but thorough, understanding of PowerBASIC -
the scope of the language as well as it's specific capabilities.
The visual interface of an application consists of one or more windows - rectangular
areas on the screen which the Windows operating system manages as objects. User
actions, hardware events, and application code may result in changes to windows -
but only by sending requests to Windows to make those changes. The Windows operating system controls all aspects of windows.
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.
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.
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.
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.
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.
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:
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 ||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.