
                             VIEWS. 
                             ------ 

 The basic building block of a Turbo Vision application is the view, which
 is an object that manages a rectangular area of the screen.  The menu bar
 at the top of the screen is a view and any program action in that area of
 the screen (e.g. a mouse click) will be dealt with by the view that
 controls that area.

 Menus, windows, the status line, buttons, scroll bars, dialog boxes are all
 views.  The program itself is a view as it controls the entire area of the
 screen, although it sets up other views, called subviews, to handle the
 interaction with the user.

 Tview, the immediate descendant of TObject, provides the start for Turbo
 Vision and contains the basic screen management methods and fields.  It is
 able to draw itself at any time, using the virtual method called 'draw' and
 it is able to handle events that are directed to it.

 The location of a view is determined by two points of type TPoint, which
 contain two fields, the X and Y coordinates of the points.  The first
 point, the 'Origin', is the top left corner of the new view, measured
 relative to the coordinate system of the owner view.  The second point, the
 'Size', is the bottom right corner of the new view measured relative to its
 own origin.  Both points are contained in an object of type TRect.

 TRect and TView both provide useful methods for manipulating the size of a
 view.  The example below illustrates how to create a view that just fits
 inside a window.

      PROCEDURE ThisWindow.MakeInside;
      VAR
        R: TRect;
        Inside: PInsideView;
      BEGIN
      GetExtent(R);                          {sets R to size of ThisWindow}
        R.Grow(-1, -1);                 {shrinks rectangle by 1, both ways}
        Inside := New(PInsideView, Init(R));          {creates inside view}
        Insert(Inside);                      {inserts new view into window}
      END;

 GetExtent is a TView method that sets the argument, TRect, to the
 coordinates of a rectangle covering the entire view.  Grow is a TRect
 method that increases the horizontal and vertical sizes of a rectangle.

 It is essential that a view must cover the entire area for which it is
 responsible.  Failure to fill the whole area and the resultant uncertainty
 is illustrated by the example program TVGUID05.PAS.  A view must also be
 able to draw itself at any time, particularly after it has been covered or
 moved or changed.

 Views frequently contain the initiator of an 'event', such as the status
 line invitation 'Close', which is dealt with by a virtual method called
 'HandleEvent', available in the hierarchy from TView to TGroup to TProgram,
 but generally overridden for a specific application.

 TGroup and its descendants are collectively referred to as 'groups',
 whereas other views are called 'terminal' views.  A group is just an empty
 box that contains and manages 'subviews'.  An example is TApplication,
 which controls the whole screen, but owns three subviews; the menu bar, the
 desktop and the status line.

 Subviews are created and then inserted into groups by the TGroup 'insert'
 procedure, as shown on page 87 of the Guide and below:

      InitDeskTop;
      ...
      ...
      IF DeskTop <> NIL THEN Insert(DeskTop);
      ...
      ...

 It is possible to have multiple, overlapping windows on the desktop, as
 groups know how to handle overlapping subviews.

 Groups keep track of the order in which subviews are inserted.  Several
 two-dimensional (X,Y) views can be considered to be in the form of layers
 in the third dimension (Z) and so the order is called the 'Z-order'.  The
 last view inserted is the 'front' view.

 Groups do not draw themselves directly, but call on each of the subviews to
 draw themselves, in Z-order, so that the most recently inserted subview
 will be in front of the others.

 Views are related to each other in two ways: they are members of the Turbo
 Vision hierarchy and they are members of a 'view tree'.  These two distinct
 relationships are differentiated by the diagrams below:

 TObject -- TView -----
                    |-- TButton
                    |--
                    |-- TFrame
                    |-- TGroup -----
                    |            |--
                    |            |--TWindow -----TDialog
                    |
                    |
                    |
                    |-- TStaticText -----
                    |

 The hierarchy, shown above, indicates that TButton, TFrame, TDialog and
 TStaticText are all descendants of Tview.  However a TDialog view owns a
 TButton, TFrame and a TStaticText, so a view tree can be constructed, as
 below:

                          TDialog
                          |  |  |
           ----------------  |  ------------------
           |                 |                   |
         TFrame           TButton            TStaticText


 Here TDialog is not an ancestor of TButton, but it owns TButton. The links
 indicate ownership, not inheritance.

 Figures 4.11 and 4.12 of the Turbo Vision Guide illustrate another view
 tree situation for an application which shows two overlapping file viewer
 windows in the desktop. The view tree is as shown here:

                            Application
                             |   |   |
             ----------------    |    ------------------
             |                   |                     |
         MenuBar              DeskTop              StatusLine
                               |   |
              -----------------     -------------------
              |                                       |
           Window                                  Window
           | | | |                                 | | | |
    -------  | |  -------                  --------  | |  ---------
    |        | |        |                  |         | |          |
  Frame      | |     Scroller            Frame       | |       Scroller
             | |                                     | |
     --------   --------                     --------   --------
     |                 |                     |                 |
  Scroll Bar       Scroll Bar            Scroll Bar        Scroll Bar

                                
           
 Selected and focused views.
 ---------------------------

 Within each group of views, one and only one subview is selected.  With
 menu bar, desktop and status line, it is desktop that is selected, because
 that is where further work will take place.

 When several windows are open on the desktop, the selected window is the
 one the user is currently working, called the 'active' window (usually the
 topmost).

 Within the active window, the selected subview is called the focused view.
 For example, in a dialog box, the focused view is the highlighted control.

 In the application view tree shown above, Application is the 'modal view'
 and DeskTop is its selected view.  Within desktop, the second (more
 recently inserted) window is selected and therefore active.  Within that
 window, the scrolling interior is selected and, because it is a terminal
 view, it is the end of the chain, the focused view.

 The currently focused view is usually highlighted on the screen.  For
 example, in a dialog box, the focused control view is brighter than the
 others, indicating that it will be acted upon if the user presses 'Enter'.

 When a group of views is created, the owner view specifies which of its
 subviews is to be focused by calling that subview's 'Select' method.  This
 establishes the default focus.

 The user may however change the view that has the focus by clicking the
 mouse on a different subview.  In a dialog box, pressing the tab key also
 moves the focus, as does the pressing of an appropriate hot key.

 Some views are not selectable, including the background of the desktop,
 frames of windows and scroll bars.  User created views can be designated
 selectable or otherwise.

 The chain of views from the parent object to the focused view is called the
 'focus chain'.


 Modal views.
 ------------

 A view may define a mode of operation, or of acting or functioning, in
 which case it is called the 'modal view'.  In the integrated development
 environment the modes are editing, debugging, compiling and run. Depending
 on which of these modes is active, keys on the keyboard may have varying
 effects.  Dialog boxes are usually modal and, when active, nothing outside
 it functions.

 When a user instantiates a view and makes it modal, only that view and its
 subviews can interact with that user.  Events are handled only by the modal
 view and its subviews.  Any part of the view tree that is not the modal
 view or owned by the modal view is inactive.


 VIEWS.WR1
 VIEWS.TXT
 3.4.91

