This series of articles is intended to discuss the Paradox system from the
point-of-view of the programmer whose primary experience is grounded in
Microsoft Access.

This forum is duplicated on our site at http://www.sundialservices.com/forum
in the "General" section, forum "TechTips," and we invite you to also
comment there.

=====
PROGRAMMING MODEL:

The programming model provided by Paradox is one thing that is almost
totally unique, and that has no precedent whatever in Microsoft Access.

On the surface, Paradox is no different from any other system in the general
organization of its user-interface: you define windows ("forms"), place
buttons and input-boxes and other widgets ("UIObjects") on them, and string
them together with procedural code if needed. The basic operative
mechanism of the form is, as with any other GUI-based programming system,
an "event-based" model that we need not elaborate on here. When the user
interacts with the environment we've created, events occur and our
procedural code can handle them. Here is where the superficial
similarities swiftly end...

In the Access system, user-interface widgets do very little on their own:
it is practically impossible to avoid using the "Wizards" which create
Visual Basic code behind each object that you create. The subroutines that
are called are identified by name. It is a "flat," non-hierarchical,
one-to-one relationship between controls and subroutines.

In the Paradox system, per contra, UIObjects are very complete in their
self-defined, default behaviors and a great deal of form-construction can
be done with no backing procedural code at all. Furthermore, there are
many different points at which procedural code, if it is required, could be
attached. This is a product of the so-called "event bubbling" concept for
which Paradox is rather justifiably famous. In this system, events are
first presented to the form itself, then to the object being addressed,
then to each object which contains (on the surface of the screen) this
object, until the event is finally presented to the form a second time.
Events therefore "ripple outward," like the waves on a pond into which a
stone has been tossed. This feature, well applied, can lead to great
economy of code.

The Paradox system is designed to exploit the natural programming
environment of Windows to its advantage. Every form, library, or report in
the system is, in fact, a Windows DLL. Thus, Windows' own memory
management system takes care of resource and memory management for these
Paradox-specific objects just as it does for its own. Paradox encourages
the use of shared libraries containing common code which is therefore
shared by all components of the application.

By the very simple expedient of defining the individual parts of an
application as individual files, and then defining those files as DLLs,
Paradox greatly reduces its own "footprint" and impact on the system. It
is much less resource-intensive than Access.

----
ChimneySweep(R): F-A-A-ST table repair at a click of the mouse!
http://www.sundialservices.com/products/chimneysweep