$32.4 INTERACTION MECHANISMS 1071 The proportional procedures interpret the values of their arguments as fractions of the parent window's height and width;arguments to the other procedures are absolute values (in world coordinates for go and pan,in device coordinates for the pixel procedures).Procedures are similarly available to set the extent and size of a window. Graphical classes and operations All classes representing figures are descendants of a deferred class F/GURE;standard features include display,hide,translate,rotate,scale It is indispensable to keep the set of figure types extendible,allowing application developers (and,indirectly,end users of graphical tools)to define new types.We have seen how to do this:provide a class COMPOSITE FIGURE,built by multiple inheritance from FIGURE and a container type such as LIST [FIGURE]. 32.4 INTERACTION MECHANISMS Let us now turn our attention to how our applications will interact with users. Events Modern interactive applications are event-driven:as the interactive user causes certain events to occur (for example by entering text at the keyboard,moving the mouse or pressing its buttons),certain operations get executed. Innocuous as this description may seem,it represents a major departure from more traditional styles of interaction with users.In the old style (which is still by far the most common),a program that needed input from its user would get it by repeatedly executing scenarios of the form ..Perform some computation .. print ("Please type in the value for parameter xxx.") read input xxx :value read ..Proceed with the computation,until it again needs a value from the user... In the event-driven style,roles are reversed:operations occur not because the software has reached a preset stage of its execution,but because a certain event,usually triggered by the interactive user,has caused execution of a certain component of the software.Input determines the software's execution rather than the reverse. The object-oriented style of software development plays an important role in making such schemes possible.Dynamic binding,in particular,enables the software to call a feature on an object under the understanding that the form of the object will determine how it will handle the feature.The feature may be associated with an event and the object to a command;more on this below. The notion ofevent is important enough in this discussion to yield a data abstraction. An event object(instance of the EIENT class)will represent a user action;examples are key press,mouse movement,mouse button down,mouse button up.These predefined events will be part of the event catalog§32.4 INTERACTION MECHANISMS 1071 The _proportional procedures interpret the values of their arguments as fractions of the parent window’s height and width; arguments to the other procedures are absolute values (in world coordinates for go and pan, in device coordinates for the _pixel procedures). Procedures are similarly available to set the extent and size of a window. Graphical classes and operations All classes representing figures are descendants of a deferred class FIGURE; standard features include display, hide, translate, rotate, scale. It is indispensable to keep the set of figure types extendible, allowing application developers (and, indirectly, end users of graphical tools) to define new types. We have seen how to do this: provide a class COMPOSITE_FIGURE, built by multiple inheritance from FIGURE and a container type such as LIST [FIGURE]. 32.4 INTERACTION MECHANISMS Let us now turn our attention to how our applications will interact with users. Events Modern interactive applications are event-driven: as the interactive user causes certain events to occur (for example by entering text at the keyboard, moving the mouse or pressing its buttons), certain operations get executed. Innocuous as this description may seem, it represents a major departure from more traditional styles of interaction with users. In the old style (which is still by far the most common), a program that needed input from its user would get it by repeatedly executing scenarios of the form … Perform some computation … print ("Please type in the value for parameter xxx.") read_input xxx := value_read … Proceed with the computation, until it again needs a value from the user … In the event-driven style, roles are reversed: operations occur not because the software has reached a preset stage of its execution, but because a certain event, usually triggered by the interactive user, has caused execution of a certain component of the software. Input determines the software’s execution rather than the reverse. The object-oriented style of software development plays an important role in making such schemes possible. Dynamic binding, in particular, enables the software to call a feature on an object under the understanding that the form of the object will determine how it will handle the feature. The feature may be associated with an event and the object to a command; more on this below. The notion of event is important enough in this discussion to yield a data abstraction. An event object (instance of the EVENT class) will represent a user action; examples are key press, mouse movement, mouse button down, mouse button up. These predefined events will be part of the event catalog