Object Oriented messages structure                                          .
 --------------------------------------------------------------------------------

 Microsoft Windows it is NOT a true Object Oriented enviroment. The main
 reason of this is because it has been written using a non-true Object
 Oriented language, that is C language was used instead of C++ (it was not
 available!).

 You may read in many places that Windows is Object Oriented. This is not
 true. In order to be Object Oriented is should offer the three main rules
 of an Object Oriented enviroment: Encapsulation, Polimorphism and
 Inheritance.

 Windows should be Object Oriented and this should greatly helped programmers
 to write Windows applications. This is why Borland, Microsoft, CA and other
 manufacturers have developed C++ classes libraries to convert Windows in
 a true Object Oriented enviroment.

 The problem with this latest approach is that still there is no a standard.
 If you review Microsoft, Borland and CA Classes hierarchies you will find
 many differences. Also, those hierarchies are extremelly big and most of
 the times all its features are not required at all in a standard Windows
 bussiness apllication.

 Windows provides a very primitive way of simulating OOPS, it is called
 'SubClassing' but not in the Object Oriented sense, but in a simple way
 of changing a windows procedure by another.

 In order to make Windows a OOPS enviroment, it is required that all
 created windows and controls are automatically 'SubClassed', that is,
 we change the standard Windows API behavior mechanisms for the OOPS
 mechanisms provided by an OOP language, like C++, Clipper 5 or any other
 language with real OOPS capabilities.

 Microsoft MFC, Borland OWL, CA CommonView and Clipper-FiveWin have been
 builted using the same construction rules. The same construction processes
 are into all those products. FiveWin offers the simplest and fastest
 Classes hierarchy structure. We have developed it in that way to get
 the best performance and size results. When you are in the OOPS arena
 you have the risk of start creating Classes without a strong reason and
 you run into the danger of highly decrease performance.

 The proccess of converting Windows into a real OOPS enviroment has to be
 taken in two steps:

       * Automatically SubClassing all windows and controls as
         soon as they are created. That allow us to change standard
         Windows behaviors.

       * Designing a base general events processing mechanism to
         convert Windows messages into OOPS-language messages in
         order to take advantadge of polimorphism and code reusability.

 Thanks to OOPS inheritance it is possible to create a base TWindow Class
 which knows how to proccess most of all Windows API messages, and then
 we may inherit new Classes from it which redefine Methods and easily let
 us change the desired behaviors.

 In FiveWin, the 'SubClassing' is done automatically through the TWindow
 Methods :Link() -to perform the SubClass process- and :UnLink() to
 restore the original procedures before the window gets destroyed. Those
 processes are quite sofisticated. Don't modify them.

 FiveWin changes the standard windows procedures for a very single one
 which just gets the Clipper Object from the window handle and then
 automatically calls :HandleEvent() method. So :HandleEvent() receives all
 Windows API messages, and automatically call the apropiate Object Method.