Fundamentals Of Event Driven Programming

Published Date: 02 Nov 2017

Chapter 11 Fundamentals of Event Driven Programming

In this chapter, you will learn how to:

Explain fundamental concepts of event driven programming environments and the connection between text and graphical user interfaces and event processing.

Differentiate between event driven programming and sequential processing environments.

Demonstrate the design of logic models for event driven programming applications.

Explain the connection between registering and handling events and the lifecycle of an event.

Describe common trapped events found in text based interfaces.

Describe design and testing concepts used when developing event driven programs.

 

Event Driven Programming Fundamentals

 

 

This chapter marks the start of the section on event driven programming. With the advent of graphical user interfaces (GUI) and their popularity, most programs today are designed to be interactive capitalizing on graphically rich operating systems where the user interacts with the program logic via icons and graphics. Whereas programs covered in earlier chapters focused mainly on the sequential processing of logic, event driven programs are typically controlled by the end user where the sequence of operations is partly under the control of the programmer and partly under the control of the user. When the end user clicks on graphical controls or uses a shortcut key to execute a selection in a pull down menu, the program then responds to that event or action. The event initiates the execution of a block of code reflecting some piece of the program associated with that event. It has been in the introduction of graphical user interfaces that has popularized event driven programming. In our discussion, we will approach this program design from two directions. We will look at event driven programming with text and graphical programming interfaces.

 

In this chapter, we will first focus on the coding of applications that respond to keyboard events. The topics covered will highlight the mechanics of event processing without graphical controls. We will still be able to use pseudo code to model the logic and PYTHON to validate our model design.

Event driven programming: Event driven programming consists of designing program logic that partly depends on user interaction to control program execution. The user triggers an event by clicking on graphical controls or keys on the keyboard. Each event is tied to an event handler that is associated with a block of program code. An event might be hitting the Q key and the event handler code for that key might be code to quit or end the program.

 

 

Sequential Processing - When a program uses sequential processing, statements are executed in sequential order from top to bottom (much list the way we read a book). The only exception from the top to bottom sequence is to call a module. When the module is called, execution moves to the module and returns back to the call point when all of the statements in the module have been executed. We have used sequential processing in our previous chapters.

Event - An event is an input action that is caused by clicking on a graphical object with the mouse, hitting a key on the keyboard to select an option or signaling an event as a result of programming logic (i.e. for example the result of a if statement decision structure).

Graphical User Interface - Also referred to as GUI (pronounced Gooey), a graphical user interface consists of graphical objects such as icons that are used by the end user to interact with the operating system. Perhaps the most famous GUI program is the Microsoft Windows desktop. A program can also have a GUI and it also uses graphics and icons that allow the user to control the application.

 

What makes this final section so important to your training is that event driven programming represents a design that is favored by most users. As we have adopted graphically rich operating systems like Microsoft Windows, Apple Macintosh OS and Linux, and with the continued familiarity with graphical Internet browsers, users have come to expect their interaction with a computer to be much like interactive TV where multimedia graphical objects and input devices, like the mouse, control their use of the computer.

 

In my programming classes, many of the students have never seen the older command line operating system interfaces which were available when personal computing first became popular. Since the introduction of a Microsoft Windows operating system environment in 1990, anyone who has any experience with a personal computer probably only knows a graphical interface. Although event driven processing is associated with the newer operating systems it was possible and was popular to create event driven programs without a graphical interface and only a command line prior to MS-Windows.

 

 

Figure 1: Screen Shot Command Line (DOS prompt)

 

 

Figure 2: Graphical User Interface (Visual Basic Program)

 

 

Command line - Most operating systems provide a command line prompt to signal the computer is ready for input (instructions or commands). The command prompt is used when a graphical interface is not needed or available. This input could be the execution of a program or a request for program input (a prompt asking for input to supply a value for a variable).

 

 

Our first exposure to event driven programming will be done using the techniques learned in earlier chapters. Since all of the PYTHON programming we have done to this point has been from the command line, event driven programming in this chapter will graphically not look much different than what we have done in the past. What we will do in this chapter is learn to take text based application environments and implement event driven programming with keyboard events. Our next chapter will focus on topics which relate to visual programming environments. In this chapter, we won’t see icons and graphics whereas in the next chapter we will spend a lot more time on screen design and the effective use of graphics in interacting with the user.

Programming Tip: Event driven programming can be implemented in both text based command line interfaces and the more modern graphical user interfaces.

 

 

Background Information: Event driven interfaces better? - Just like we discussed when we introduced class objects into our programs, event driven interfaces do not necessarily represent the only way or the best way to write the program. A program that uses an event driven processing design works internally no better then a program that uses a sequential design. Sequential processing gives us speed and simplicity, class objects give us reusability and events give us better interactivity with the user. Using one or all of these design techniques are dependent on the kind of solution you want to provide for your end user.

 

What Do We Mean By Processing an Event

 

So far much our discussion has been dominated by interfaces. Graphical interfaces and text interfaces. Interfaces are important to events because for any event processing to take place the user has to see the options offered by the program. While the interface is displayed, the program is looping patiently waiting for an event to occur and then handled.

 

By design, this is dramatically different than how we have done processing so far. In our previous programs, we researched user requirements and then designed our program to meet the user’s requirements. We limited the user’s control of the program. We are now giving the user choices. We now design the program to include all of the operations that satisfy the user’s requirements but the control of the program is left with the user via the interface. This is implemented by providing the user an interface with options. Each option is an event and each event has its own logic module (and therefore part of the program) associated with it.

 

Text Interface - A text interface uses text displayed across the entire screen to facilitate an environment where the user can’t interact with a program by selecting keys from the keyboard that execute code blocks within a program.

 

For example, the user may be presented a screen that has a various letter options. The act of selecting a letter corresponding to the desired option is an event. The program is listening for the event and handles it. Handling the event (also called event handling) means the program has code associated with the event. We are letting the user decide which option they want to take and therefore which direction the program will take. Again, we are giving up control for the sake of an interface that is more conversational and presents the user with greater flexibility. As we will see later in the chapter, relinquishing control of our program to the user means that the logic must be built to not allow the user to take an option that would cause the program to fail.

 

 

Figure 3: Sample Text Interface, Event and Event Hander.

 

 

Programming Tip: Programs can contain one or many events.

 

The lifecycle of an Event

 

 

Events are at the center of event driven processing and they have three stages which they move through. All events start with some registration process. When the event driven programming is initiated from a text interface, the program associates an event with a key from the keyboard. The registration occurs when program code associates and event action with a key. Once the event is registered, the program listens for that key to be clicked. Listening typically requires the program to be placed in a looping state where it is listening for an event to be trigger or fired. When the key is clicked it is said that the event is fired. In terms of the loop, the firing is connected to a Boolean expression which has been associates with code linked to the event. Once fired, the event must be handled. Event handling means that code that has been designated as the event handler for that event. When and unhandled event has be identified the code associated with handling that event will be executed. Event handling code is usually stored within a module associated with the designated role of the event in the program.

 

Lifecycle of event handling performed in a text Interface:

 

Registering the Event - Identifying the key that is associated with the event.

Listening for the Event - Placing the program in a state to listen for the events to be fired

Event handing - Once fired, the code associated with the event is executed.

 

 

Programming Tip: It should be noted that events can still happen within a program that does not have a text or graphical interface. This type of event is fired and responsive to a state the program has moved to. An example of this type of event processing can be seen at the end of this chapter.

Background Information: Looking for Command Line Interfaces - My students give me a lot of strange looks when I talk about command line interfaces. Since most of the students, were brought up with computers that had graphical user interfaces (post 1990), the concept of a command line interface is something which needs further explanation. I explain to them that before the mouse and icons, computers were run with commands issued at a command prompt (or the command line). If you wanted to run a program then you would type that program name in at the command prompt and then hit enter. The program was then executed and reported back to the screen some text as the programs output. Programs were typically not as interactive and certainly not as conversational as we have with the graphical user interfaces of operating systems like Microsoft Windows.

 

For those of you who would like to see a command line prompt in action, if you’re a Microsoft Windows user you can access Accessories under the Program Menu list and then select DOS Command Prompt. The command prompt will consist of a window with a black background white foreground and a starting drive letter and folder.

 

 

Figure 4: MS Windows Command Prompt Window Screen Shot

 

 

Status Check

What stages are in the event lifecycle?

How is a text interface different than a graphical user interface?

 

How Does Event Driven Programming Fit In With What We Have Done So Far?

 

 

For the programming of solutions that use a graphical user interface, event handling is critical to take advantage of the graphical objects (i.e. command buttons, text boxes, etc.) that control the program. For a program that has only a text interface, the effect is less dramatic. Event handling as a way of controlling the program that can make it more interactive. For most applications this is an advantage. The exception would be those applications that process large numbers of file maintenance operations (add, change and delete) or where user interaction is not necessary.

 

 

Related Subject: Event Driven Transaction Processing - When we process data record by record from a file or database, this type of programming is called transaction processing. Usually in most business applications, when we are processing transactions, the records processed are in the hundreds or thousands. Although, event driven processing could be very useful for working on a record at a time (i.e. maybe for a customer service program that is used when talking to a customer on the phone), if we needed to process thousands of records, event driven design would not offer an advantage and it fact it would be a disadvantage. For those large update operations that involve a large number of transactions, we would probably choose a program design that uses a sequential processing design.

 

Event Driven Processing as a Code Pattern

 

 

Event driven programming is performed with all of the techniques we have covered so far. It borrows a little from control structures (decisions and looping) and can also take advantage of class objects if code reuse is important. We have talked about many logic patterns in this wiki that qualify as code patterns. Event processing would certainly qualify as a pattern.

 

 

Figure 5: Basic Graphical User Interface Controls

 

Event Driven Programming versus Sequential programming

 

 

It is important now to compare and contrast a program developed with event driven processing and one developed using simple sequential processing. Let look at a simple sequential application that adds to numbers. Taking from concepts learned and earlier chapters we know that this type of program would require us to identify the least three variables. One variable to hold the total and the other two variables to hold the numbers that would be added together for the total. Our program might prompt us for the two values to be added together and the program would automatically display the answer to the screen.

 

 

Event driven design affords us some benefits that we don’t see with sequential execution. In the first example, the programmer controlled program execution and determined when the user was asked for input, when the calculation would take place and when the program would end. The event driven alternative gives the control to the user and lets the user run the program over and over again. The user controls when the program is complete and needs to end.

 

Which design is best? It is a good question and one I would like to answer. Both programs work just as well. From the standpoint of the program coming up with the correct answer, either solution is fine. Sequential or event processing makes no difference. Where one version has an advantage over the other may be due to other factors. If the program needs to be written for a wrist watch then program size is a factor and the sequential solution may the preferred design. If the program is being run from a graphical desktop then an event driven solution would be preferred. Graphical controls require that events be defined and event handlers be coded. Graphical interface designs are also preferred by users.

 

Menu Processing in a Text Interface

 

 

Let’s take a look at another example of text interface event handing. Menus are an excellent example of how a text interface can make the program easier to use. Before programs had mice and graphical interfaces, programmers would develop applications with a menu interface. Menus just like menus you would find in restaurants. You decide the option you would like and select it. This example builds upon concepts and techniques used in earlier chapters. The code used to build this design is no different than the code and logic structures used in earlier chapters. This application has an event driven code pattern to give the user a menu to select from.

 

 

Let’s look at the menu interface for program navigation. Rather than prompting the user for the selection why not print on the display all the menu options and let this user select one. When the selection is made why not trap the input and process that selection taking the user to the next screen. Is this not similar to what happens when a user uses the mouse to click on a command button to navigate to a new screen? In the following pseudo code and PYTHON examples, I have simulated an event driven application. I will create a pseudo-code logic model to put together the program logic and use PYTHON to implement the solution.

 

Before we model the application, let’s talk about what is essential if the program is to operate as an event driven application. First of all, I must design a text interface that fills up the entire screen (full screen interface). A full screen interface is where the display is formatted to use up all 24 lines of the display so that the programs text utilizes the entire screen. When the display takes the entire screen it facilitates the perception that the user is interacting with the application and not the command line (See screen shot below). The next step in my program is to create a while loop continues to loop until a menu selection has been selected (i.e. maybe Q to quit). We will call this loop the event processing loop. Within the loop, in each key entered is stored and processed through a call to the appropriate module. For example, I might have the menu selection ‘A’ for add, ‘C’ for change, ‘D’ to delete and "Q" for quit. Once the letter is selected, logic in the event loop will call the appropriate module.

 

 

Full Screen Interface - the full screen interface is accomplished when the user sees text painted across the entire screen as opposed to a command prompt waiting at the bottom of the screen. Visually, the user looks like they’re interacting with the entire computer instead of just the command line. The text based interface uses full screen design to provide a more interactive environment for the programs user.

 

 

Figure 6: Screen Shot Of A Full Screen Text Interface.

 

 

Programming Tip: A command line interface can be converted to a full screen interface if print statements are sent to the display to clear any previous print statements.

 

Pseudo code Menu Programming Logic

 

start

selection = "A"

while selection not equal to "Q"

selection = prompt("Enter Selection ")

if selection = "1" then

call clearScreen

print "1 Selected"

else if selection = "2" then

call clearScreen

call menuTwo

end

clearScreen()

cnt = 1

while cnt < 24

print

cnt = cnt + 1

return

menuTwo()

selection = "A"

while selection not equal to "R"

selection = prompt("Enter Selection ")

if selection = "A" then

call clearScreen

print "Option A"

else if selection = "B" then

call clearScreen

print "Option B"

return

 

Status Check

Why is the event loop critical to an event driven interface?

Why is filling the screen display with your text interface so important?

 

Designing Programs that use Event Driven Programming

 

 

The program that uses events sounds interesting but what are the ramifications. The ramifications deal mostly with the fact that as programmers we may have lost some of the control we had in deciding the sequence of our programming statements. As mentioned above, the number of statements and how they’re programmed may not be significantly different but their execution is under the control of the person interacting with the interface. This can sometimes present problems for the programmer. For example, what if a program has three distinct parts? Each part of the program would represent some logic that is part of the total program solution. These three parts need to be executed in a sequential order. In other words, part one has to be done before part two and part two has to be completed before part three. If the programmer was to simply put key events on the text interface which triggered these three parts of the program, problems could develop if the user executed part three without doing part one and two first. The result could lead to a logic error or runtime error but in any case an error. This is a common problem when the control of the logic is built into the interface.

 

As the designer of a program written to take advantage of event driven programming, there will be occasions where you may need in your design to deactivate or make keys inactive. For example, in the previous example where three parts had to be executed in order, the programmer might make the keys for part two and three to be invisible until the key associated with part one has been typed. The program has to design the interface to facilitate the sequence of logic contained in the program.

 

Programming Tip: Programmers using event driven program designs need to use the interface to control sequence in which the user can activate program code from the screen.

Related Information - Console Applications - Even programming languages noted for their ability to create graphical applications like Visual ~Basic.Net will support the development of a console application. A console application is essentially a program written to be run at the command prompt. Even Microsoft Windows, the operating system known for its graphical user interface, supports the command line interface called DOS prompt. DOS prompt can be found by default in the accessories menu option off of the programs list. Why I support the console applications? Some computers don’t have a display (i.e. a smart card for example) and therefore if the programming language will truly support all environments and they will also have to support applications which can only run as console applications.

 

What is asked of the programmer when developing event driven programs is not more complicated but different. In a sense, there’s a tradeoff between the graphical nature of the program and the benefits associated with that versus the extra code that may be required in the program to control the sequence of program logic execution. I think if we took a survey of users most would prefer to use a graphical interface program over a sequential program run at the command prompt.

 

GUI Events versus Program Events

 

 

It is easy to only think of events in terms of the graphical or text user interface but this is incorrect. As you’ll experience with learning programming languages that support event driven programming, it is also possible to register and handle events from program logic (the interface is not required). We have seen this already in chapter ten where in accessor method of a class object, we threw a custom exception which was handled by driver program. The custom exception was our event and the logic in the class file was the action that fired that event.

 

Programming Tip: A common way that programmers refer to the registering of a new event is to say that that event was fired. Fired events are in turn handled which is to say program code is associated with each event in executed when the event is fired.

 

If we will discuss the firing of program events in this chapter and leave our discussion of screen events to the next chapter.

 

A Logic/Program Event

 

Different programming languages handle program events in different ways. In Visual Basic there is an Event object that can be used to register an event and event handlers can handle a program event as easily as an event from a graphical control. The event is triggered with the raise keyword and the event handler kicks in automatically with a program sub procedure identified with the event handler. PYTHON can be programmed to perform in a similar fashion by utilizing custom exceptions. Since we have used PYTHON throughout the wiki, we will stay with PYTHON to demonstrate program throw events even though this approach is a little unconventional due to our liberal use of the exceptions.

 

Program events - A program event is an event that’s fired as the result of logic. Rather than being fired directly as the result of user interaction, a program event is fired as a result of program logic. Typically, this would be done as the result of an if statement some other decisions structure.

 

For example, let’s build an application that fires and event when the cost of an item exceeds 300 dollars. An if statement will be used to fire the event (providing the boolean expression evaluates as true) if the cost exceeds 300 dollars and a customer exception object will act as the event handler. The following example illustrates this:

 

#ProgEventHand.py

#program event example

class over300Event(Exception):

def __init__(self, msg = None):

self.msg = msg

def __str__(self):

return str(self.msg)

#start of program

cost = 300

try:

if (cost >= 300):

print "Event fired..."

raise over300Event, "Cost over 300 - Management Approval Required"

else:

print "Event not Fired..."

except over300Event, msg:

print msg

#end of program

- The class over300Event symbolizes our event and registers the event with the program

 

- The try block enables the processing of exceptions and therefore our enables our event processing.

 

- The catch block constitutes our event handler and is executed only if the event is fired due to the if statements Boolean expression.

 

The following example should be contrasted with earlier examples where we used a text interface to allow the user to control the application. In this example, our program logic triggers events and how logic should be executed. One could argue (and probably prove with a program) a similar solution that used modules and if statement logic to accomplish much the same function as this program. Event processing logic is more functional when used with either a text or graphical interface.

 

The Programming Process with Event Driven Programming

 

 

As we will see in both this chapter in the one that follows it, if we are developing an application which we know will be implemented in a graphical environment, we will certainly have to a take the event handling processing into consideration in our logic models. What this means is that the conceptual design still takes place and programming is still driven from our logic models, but what changes is an appreciation that an interface and the users selection of events will drive the execution of the program. The design process will have modules and code will be mapped to an event rather than to a tightly controlled sequence.

 

Design Concerns

 

We have mentioned some of the concerns which are connected with event driven programming already but it is important that we review them one more time. For starters, most event driven programs utilize an interface (either text or graphical). We have spent many pages in this wiki emphasizing the importance of models. For the most part, our modules have been of programming logic. With event driven programs we also want to create a model of our interface. This is best done with a storyboard. A storyboard is a freehand drawing (or a drawing created from a product like Microsoft Visio) of the interface. If the interface is text based then the storyboard will have text. For a graphical interface, the storyboard will contain graphical controls. The storyboard should what the user will see when the application is created. See the example below for a simple text interface storyboard.

 

 

Figure 7: Storyboard of a Text interface.

 

 

Storyboard - A story board is usually a drawing of the interface. The storyboard a prickly is used to lay out the graphical elements of the GUI. It would lay out the tax displayed on the full screen.

 

Testing

 

Testing can be more challenging with programs that use events. Whereas a sequence program is controlled by the programmer, the event driven program is not. As the programmer, you will have to make sure your test matrix exercises all of the options (test cases) on the text interface and all the combinations that could be used on that interface. In the past we talked of the test matrix needing to focus on program logic. Since the interface allows the user to call out the sequence of the program logic, it is important that you exercise all of the user’s options on the interface.

 

A user will take some of the most outrageous and unbelievable approaches to your interface. You must test all of the interface possibilities to insure that even though the user has flexibility in choosing the execution path, that the sequence of their actions does not break the login in your program. As to determine test cases, place them in your text matrix to insure you have proper text coverage.

 

Test Matrix - The text matrix is a grid that on the vertical axis documents all of the test case as necessary to exercise all the options of the interface. On the horizontal axis holds the outcomes expected from each test case.

Status Check

Does the program process change now that we are using a text interface?

What special problems in program control does a program with a user interface have that a program without an interface does not?

 

Cactus Case Study

 

 

One of the design goals of Cactus Books and Tapes was to make the program and interface as easy to use as possible. Customers will be reluctant to use a web site that is not easy to use and intuitive. Ultimately, the finished site will have graphical controls but for now you have decided to build a prototype of menu options to make sure that the interface options are clear.

 

After talking with the Chavez sisters, you have come up with an initial design that, based on the sister’s experience, will work well to capture key information.

 

Main Menu

Browse Books and Audio Tapes Screen

Search Books and Audio Tapes Screen

Checkout Shopping Cart

End Session

Browse Books and Audio Tapes Screen

Drama

Mystery

Sci-FI

Non-Fiction

Biography

Humor

Search Books and Audio Tapes Screen

Enter Keyword

Enter Title

Enter Author

Enter Book Type

 

Case Study Tasks:

Review the following interface recommendations and create a logic model of the interface and options

 

 

 

Figure 8: Story Board of Text Interface

 

Pseudo code Solution

 

start

mainMenu()

clearScreen()

end

clearScreen()

for i = 1 to 50

print

return

browseMenu()

selection = "0"

while selection not equal "R"

call clearScreen()

print " Browse Menu"

print

print " a. Browse Drama"

print " b. Browse Mystery"

print " c. Browse Sci-Fi"

print " d. Browse Non-Fiction"

print " e. Browse Biography"

print " f. Browse Humor"

print

print "R - Return to Main Menu"

print

selection = input(" Enter Choice >> ")

if selection equals "a":

call clearScreen()

print "Under Construction - Drama Selected"

else if selection equals "b"

call clearScreen()

print "Under Construction - Horror Selected"

else if selection equals "c"

call clearScreen()

print "Under Construction - Sci-Fi Selected"

else if selection equals "d"

call clearScreen()

print "Under Construction - Non-Fiction Selected"

else if selection equals "e"

call clearScreen()

print "Under Construction - Biograpahy Selected"

else if selection equals "f"

call clearScreen()

print "Under Construction - Humor Selected"

else if selection equals "R"

break

else

call clearScreen()

myDisplay = input( "Invalid Choice = Must be a, b, c, d, e, f, R ")

return

searchMenu()

selection = "0"

while selection not equal "R"

print "Search Menu"

print

print " a. Search by Keyword"

print " b. Search by Title"

print " c. Search by Author"

print " d. Search by Book Type (i.e. drama, mystery, etc.)"

print

print "R - Return to Main Menu"

print

selection = input(" Enter Choice >> ")

if selection equals "a"

call clearScreen()

print "Under Construction - Keyword Selected"

else if selection equals "b"

call clearScreen()

print "Under Construction - Title Selected"

else if selection equals "c"

call clearScreen()

print "Under Construction - Author Selected"

else if selection equals "d"

call clearScreen()

print "Under Construction - Book Type Selected"

else if selection equals "R"

break

else:

call clearScreen()

myDisplay = input( "Invalid Choice = Must be a, b, c, d, R ")

return

mainMenu()

selection = "0"

while selection not equal "Q"

call clearScreen()

print "Main Menu"

print

print " 1. Browse Books and Audio Tapes"

print " 2. Search Books and Audio Tapes"

print " 3. Checkout Shopping Cart"

print

print "Q to Quit program"

print

selection = input("Enter Choice >> ")

if selection equals "1"

call clearScreen()

call browseMenu()

continue

else if selection equals "2"

call clearScreen()

call searchMenu()

continue

else if selection equals "3"

clearScreen()

print "Under Construction - Cart Checkout"

msg = input("Hit Enter to Continue")

continue

else if selection equals "Q"

myDisplay = input(" Goodbye! ")

break

else:

call clearScreen()

myDisplay = input( "Invalid Choice = Must be 1, 2,3 Q ")

return

Putting It to Use

 

 

The intent of this section is to introduce the new programmer to standards and techniques frequently used by professional programmers. Topics in this section relate to concepts introduced in the chapter but with a more vocational or occupational focus for students considering a career in programming.

 

Chapter Review

 

 

Chapter summary, highlights, key terms, short answer questions, quizzes and case studies to reinforce topics covered in this chapter.

 

Chapter Summary

 

After finishing this chapter you should understand and in some cases, demonstrate the following topics:

 

Explain fundamental concepts of event driven programming environments and the connection between text and graphical user interfaces and event processing.

Event driven programming design can make programs easier to use and more conversational.

For some programming languages (like Visual ~Basic.Net), event driven programming are the design of choice.

A text or graphical user interface is necessary to register events for the user and provide them an interface to trigger/fire events.

Event driven programs allow the user to control the sequence of logic processing with the triggering or firing of events.

Differentiate between event driven programming and sequential processing environments.

Sequential driven programs execute statements one after another in a fashion similar to reading a book.

Event driven programming logic is controlled with the execution of the events. The programmer designs the program so that the user can control the sequence of program step.

Losing absolute control of program logic execution can create additional error processing concerns and testing for the programmer.

Demonstrate the design of logic models for event driven programming applications.

Explain the connection between registering and handling events and the lifecycle of an event.

Events are first registered on a user interface (text or graphical). Once the event is selected or fired the listening program dispatches the event to the appropriate event handler where code associated with the event is processed.

Describe common trapped events found in text based interfaces.

In application that only support text interfaces, keyboard events can trip event handing.

Graphical interface applications use graphical controls to trip event handling.

Describe design and testing concepts used when developing event driven programs.

Event driven environments require additional testing to insure that the user can not trigger events in a sequence that might cause the program to error.

 

Chapter Key Terms

 

Command Line

Event

Event Driven Programming

Full Screen Interface

Graphical User Interfaces

Program Events

Sequential Processing

Storyboard

Test Matrix

Text Interfaces