home *** CD-ROM | disk | FTP | other *** search
/ Collection of Hack-Phreak Scene Programs / cleanhpvac.zip / cleanhpvac / OOPTUT34.ZIP / EVENTS.TXT < prev    next >
Text File  |  1992-09-07  |  5KB  |  83 lines
  1.                              EVENTS.
  2.                              -------
  3.  
  4.  Turbo Vision applications are event-driven.  Events are occurrences to
  5.  which the application must respond.  Traditional Turbo Pascal handling of
  6.  events is achieved by reading some form of input and making decisions based
  7.  on that input.  Turbo Vision deals with these tasks for the programmer.  It
  8.  packages the input into Pascal records called 'events' and dispatches the
  9.  events to the appropriate views in the program.
  10.  
  11.  A variant record of type TEvent is used (see page 376 of the Turbo Vision
  12.  Guide).  The first field of the record is 'What' and this will be set to a
  13.  word value representing one of four events: evNothing, evMouse, evKeyDown
  14.  or evMessage.  A CASE statement is then used to determine the other fields
  15.  appropriate to the event, with the fields associated with evKeyDown and
  16.  evMessage themselves controlled by other CASE statements.
  17.  
  18.  Both outside events, such as mouse and keyboard events, and command events
  19.  generated by inter-communicating views are stored and transmitted as TEvent
  20.  records.
  21.  
  22.  The capture and execution of an event is automatically dealt with by the
  23.  main processing loop of any instance of a type TApplication, the 'Run'
  24.  method, which calls TGroup.Execute (see page 239).  This method repeatedly
  25.  gets events using the 'GetEvent' method and handles them using the
  26.  'HandleEvent' method.  In almost all cases it is the TProgram.GetEvent
  27.  method which is called (page 271), unless this has been overridden.
  28.  HandleEvent methods exist in the object hierarchy from TView through TGroup
  29.  to TWindow, TDeskTop and TProgram.  Although TDeskTop.HandleEvent is seldom
  30.  overridden, the other two frequently are, with TProgram.HandleEvent almost
  31.  always overridden to introduce handling of commands that are specific to
  32.  the user's own application.
  33.  
  34.  TProgram.GetEvent first checks if TProgram.PutEvent has generated a pending
  35.  event and, if so, GetEvent returns that event.  If there is no pending
  36.  event, GetEvent calls GetMouseEvent (page 345), a standard procedure.  If
  37.  that returns evNothing, it then calls GetKeyEvent (page 344), another
  38.  standard procedure.  If it also returns evNothing, indicating that there is
  39.  no user input, GetEvent calls TProgram.Idle to allow 'background' tasks to
  40.  be performed while the application is waiting for user input.  Before
  41.  returning, GetEvent passes any evKeyDown and evMouseDown events to the
  42.  StatusLine for it to map into associated evCommand hot-key events.
  43.  
  44.  The various kinds of event were mentioned in the second paragraph above and
  45.  can now be defined in more detail.  A 'nothing' event is really a dead
  46.  event.  When a Turbo Vision object finishes handling an event, it calls a
  47.  method named ClearEvent, which sets the 'What' field back to evNothing,
  48.  indicating that the event has been handled.
  49.  
  50.  There are four kinds of mouse event: an up or down click of either
  51.  button, generating evMouseUp and evMouseDown respectively; a change of
  52.  position, generating evMouseMove; or an 'auto' mouse event, periodically
  53.  generated by Turbo Vision when the mouse is moved whilst a button is held
  54.  down.
  55.  
  56.  The keyboard event simply generates evKeyDown and keeps track of which key
  57.  was pressed.
  58.  
  59.  There are three kind of message events: commands, flagged by evCommand in
  60.  the 'What' field; broadcasts, indicated by evBroadcast; and user messages,
  61.  described by a user-defined constant.
  62.  
  63.  Events are sent first to the current 'modal' view, which is the view that
  64.  currently defines the mode of operation.  For example, in the integrated
  65.  development environment, there are editing, debugging, compiling and run
  66.  modes.  When an application uses a modal dialog box, the dialog box object
  67.  is the modal view and initiates the event handling.  Subsequently the event
  68.  may be routed in one of three ways: positional, focused and broadcast.
  69.  
  70.  Positional events are almost always mouse events and are passed first to
  71.  the modal view and then subsequently to the subviews in layer order, top
  72.  downwards, called the Z-order.  This continues until a view is found which
  73.  contains the position where the event occurred.  This continues until
  74.  either there are no more subviews or there is no subview in the position
  75.  where the event occurred.  Once the event has reached the object where the
  76.  positional event took place, that object handles the event.
  77.  
  78.  
  79.  
  80.  EVENTS.WR1
  81.  EVENTS.TXT
  82.  31.3.91
  83.