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

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

 Microsoft Windows it is NOT a true Object Oriented environment. The main
 reason for this is because it has been written using a non-true Object
 Oriented language, C language.  C was used instead of C++ because at that
 time 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 environment: Encapsulation, Polymorphism and
 Inheritance.

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

 The problem with this latest approach is that there is still no standard.
 If you review Microsoft, Borland and CA Class hierarchies you will find
 many differences. These hierarchies are extremely large and most of
 the time all of their features are not required in standard Windows
 business applications.

 Windows provides a very primitive way of simulating OOPS, it is called
 'SubClassing', 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 environment, 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
 built using the same construction rules. The same construction processes
 are in all those products. FiveWin offers the simplest and fastest
 Class 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 run the risk of starting to create Classes without a strong reason and
 you then run into the danger of huge performance decrease.

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

       * Automatically SubClassing all windows and controls as
         soon as they are created. That allows 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 advantage of polymorphism and code reusability.

 Thanks to OOPS inheritance it is possible to create a base TWindow Class
 which knows how to process 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 sophisticated. Don't modify them.

 FiveWin changes all the standard windows procedures to a 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 calls the appropriate Object Method.