1. walters@buffalo.edu480/580 Lecture 2Slide 1 Event Driven Computing Basic Interaction Handling –Interactive programs - must pay attention to the user interface

2. walters@buffalo.edu480/580 Lecture 2Slide 2 Human Factors 1) Provide simple and consistent interaction sequences eg. each window has same mouse button functions 2) Don't overload user with options - KISS 3) Show available options clearly at every stage of interaction Don't expect user to remember Place info accessibly but not so it interferes with advanced user 4) Give feedback to user Examples in your window manager? - highlights, key echos 5) Allow user to recover gracefully from mistakes Allow for arbitrary input Cancel, undo

3. walters@buffalo.edu480/580 Lecture 2Slide 3 Logical Input Devices Used by graphics packages to provide device- independent code Locator - specify screen coordinates and maybe some state buttons Keyboard - alphanumeric input many others

4. walters@buffalo.edu480/580 Lecture 2Slide 4 Event Driven Computing How different from programming with simple user input and an emphasis on internal computations? Example A: Read array of integers, Sort them, largest first, Print the sorted array. Example B (ATM machine): W: wait for signal that card has been inserted, Take care of transaction, Go to W.

5. walters@buffalo.edu480/580 Lecture 2Slide 5 In A the program determines the sequence of instructions In B the users largely determine the sequence B is an example of interrupt driven computing –An “Interrupt” is the signal that is produced when a physical even is sensed by one of the peripherals of a machine –What are the possible interrupts for the ATM machine? Example Interrupt Driven Computing (ATM): –If an interrupt occurs call interrupt_handler (kind_of_interrupt). –Repeat above.

6. walters@buffalo.edu480/580 Lecture 2Slide 6 Programs with Graphical User Interfaces require interrupt driven computing –Not because of the geometric aspects of the display and pictures, etc –But because the program has to wait for signals from the user and execute the appropriate action for each signal received

7. walters@buffalo.edu480/580 Lecture 2Slide 7 Events Programs running under operating systems such as Unix cannot directly sense physical interrupts What part of the system handles interrupts? Operating system can pass info about interrupts to program in two different ways –signal the program immediately program samples or polls a logical input device looking for state changes continuous sampling required by the application program –store the info in a place that the application program can check it In window systems the structures containing information about physical interrupts are called “events” place stored called “event queue” event driven computing

8. walters@buffalo.edu480/580 Lecture 2Slide 8 Events are more general than interrupts –can be used to pass info about things that are not physical interrupts Events are associated with “event-triggers” –a user action that causes an event to occur

9. walters@buffalo.edu480/580 Lecture 2Slide 9 Example: Event Handling Program: –Check whether an event has occurred and it if has, then call event_handler(kind_of_event) –Repeat above Compare to Interrupt Driven Computing (ATM): –If an interrupt occurs call interrupt_handler(kind_of_interrupt) –Repeat above. Appear similar - big difference if program has to perform significant other computations –interrupt driven jumps from current computation to service interrupt when it occurs –event driven doesn’t notice event until it checks for it problem of user feedback - type-ahead versus draw-ahead

10. walters@buffalo.edu480/580 Lecture 2Slide 10 Review Standard programming versus interaction based programming Sampling (Polling) versus Event handling of interactions Interrupt-driven versus Event-driven

11. walters@buffalo.edu480/580 Lecture 2Slide 11 Two programming styles for event handling Response to same event needs to differ at times –what are the input devices on an ATM? –Eg. ATM typing in PIN number, typing in withdrawal amount, etc. Nested event handlers only one sequence of accepted events valid infinite wait loops inserted were needed code dealing with events spread throughout so harder to make portable between window systems State variables only one sequence of accepted events valid only one wait loop code dealing with events in one place - easier to make portable encourages modular programming

12. walters@buffalo.edu480/580 Lecture 2Slide 12

13. walters@buffalo.edu480/580 Lecture 2Slide 13