Lecture 2Slide 1 Event Driven Computing Basic Interaction Handling –Interactive programs - must pay attention to the user interface.
Published byModified over 4 years ago
Presentation on theme: "Lecture 2Slide 1 Event Driven Computing Basic Interaction Handling –Interactive programs - must pay attention to the user interface."— Presentation transcript:
firstname.lastname@example.org/580 Lecture 2Slide 1 Event Driven Computing Basic Interaction Handling –Interactive programs - must pay attention to the user interface
email@example.com/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
firstname.lastname@example.org/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
email@example.com/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.
firstname.lastname@example.org/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.
email@example.com/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
firstname.lastname@example.org/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
email@example.com/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
firstname.lastname@example.org/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
email@example.com/580 Lecture 2Slide 10 Review Standard programming versus interaction based programming Sampling (Polling) versus Event handling of interactions Interrupt-driven versus Event-driven
firstname.lastname@example.org/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