Click above to get retro games delivered to your door ever month!

 FiveWin Architecture
-------------------------------------------------------------------------------

 If you have some experience with Object Oriented Programming (OOPS), or if
 you just are starting out, we are sure you will be delighted to know about
 the OOPS structure that FiveWin implements.

 FiveWin's OOPS implementation is done on four basic levels:

     1.- xBase Commands
     2.- Classes and Objects
     3.- Functions and Data Structures
     4.- The Windows API

 xBase commands are the highest level of abstraction, that is, it is the
 level at which you don't care about how things work and you only care about
 functionality, that is "to make it work".

 xBase commands originally came from dBase, and they have been evolving
 towards a standard named "xBase". These commands are built over Objects.
 These Objects, and their classes are the second level of abstraction.

 To use Classes and Objects it is necessary that you have some OOPS
 skills. FiveWin uses our library Objects to use the OOPS capability
 of CA-Clipper. You can contact us to get the latest commercial release
 of Objects, at a very low price, which includes all the documentation,
 examples and source code so you will be able to utilize the incredible
 world of OOPS technology.

 Objects are also based on functions (methods) and data. This is the next
 level of abstraction. You may realize as we progress through this document
 that the complexity grows and there are more details to understand.

 Finally most of the functions we use are based on the Windows API.

 Maximum productivity is reached quickly at the xBase command level. As you
 move down towards Windows API your power and possibilities are greater but
 obviously your productivity decreases. As application programers you should
 try to be at a intermediate level: a balance between productivity and
 power.

 In spite of the low popularity achieved by dBase IV, that version did a big
 advance to consolidate the commands for creating and managing Objects
 although it did not offer OOPS.

 So in xBase the standard is established that for creating an
 Object we to use the command:

 DEFINE <ObjectClass> <ObjectName> [ ADDITIONAL CLAUSES ]

 Note that if we use that command for create any Object, in some way
 we are using a generic building 'message'. This is why we recommend
 implementing that syntax for creating new Objects.

 To activate any Object, we use:

 ACTIVATE <ObjectClass> <ObjectName>

 Finally, although this is not always necessary in Clipper, to destroy
 an Object we use the command:

 RELEASE <ObjectClass> <ObjectName>

 These commands get processed in their correspondents messages sent
 to the Object we are managing. So:

 DEFINE WINDOW oWnd  ==> Get transformed in ==>  oWnd := TWindow():New( ... )

 The use of these commands let us use a unique and common syntax for all
 the Objects. You may think that this is one of the targets of OOPS:
 We must concentrate in our goal and not in a particular implementation,
 that means, we should use a unique interface.

 As FiveWin includes the latest version of Objects, you may use it to
 build new classes from the Classes that FiveWin offers you. Review the
 FiveWin Classes hierarchy and inspect the design and the code of its
 classes to understand how you should use the power of OOPS inheritance.

 In FiveWin we have implemented for the first time a mixed system for
 developing Object Oriented environments. The system we have developed lets
 you use the power of OOPS and also the extensibility offered by 'pointers',
 in Clipper named 'CodeBlocks'.

 There is certain international discussions between these two approaches.
 There is no an agreement about what is the optimum system. This is why
 we have decided to build a mixed system which uses both technologies.

 When in a program we need to modify a behavior temporarily, as a example,
 defining a behavior for an event, we use the system based on pointers,
 that is, based on CodeBlocks. The reason for this is that we may suppose
 that behavior will not be necessary again in the future, so there is
 no need for building a new Class.

 When we do:

 ACTIVATE WINDOW oWnd ;
    ON PAINT ...

 We are modifying the behavior for that window when it receives the
 PAINT event. This system is based on CodeBlocks. It is logical because
 that behavior will not be reused in the future.

 But, if we were building a system that it is going to be reused in the
 future, then it has all sense to build a new class: this is the
 traditional OOPS way.

 So, at FiveWin's TMsgBar Class, which is a class that will be used
 frequently in other programs, we inherit a new Class  form TWindow
 and we redefine the method PAINT.

 We are convinced that a good OOPS architecture should use this two
 building models. As you get more OOPS experience you will understand
 our point of view.

 OOPS is marvelous, but still there are some aspects that should evolve.
 The construction of this mixed model may be a good way for discovering
 new possibilities.