This two-part course is designed to help students with very little or no computing background learn the basics of building simple interactive applications. Our language of choice, Python, is an easy-to learn, high-level computer language that is used in many of the computational courses offered on Coursera. To make learning Python easy, we have developed a new browser-based programming environment that makes developing interactive applications in Python simple. These applications will involve windows whose contents are graphical and respond to buttons, the keyboard and the mouse. In part 1 of this course, we will introduce the basic elements of programming (such as expressions, conditionals, and functions) and then use these elements to create simple interactive applications such as a digital stopwatch. Part 1 of this class will culminate in building a version of the classic arcade game "Pong".
Event-Driven Programming
Loading...
From the course by Rice University
An Introduction to Interactive Programming in Python (Part 1)
1714 оценки
From the lesson
Week 2 - Event-driven programming, local/global variables
Learn the basics of event-driven programming, understand difference between local and global variables, create an interactive program that plays a simple guessing game
Meet the Instructors
John GreinerLecturer
Department of Computer Science
Stephen WongLecturer
Computer Science
Scott RixnerProfessor
Computer Science
Joe WarrenProfessor
Computer Science
. In this video, we're going to talk about
the programming model that we're going to use for this class.
We're going to use the event driven programming model.
And this is what's going to allow us to build the interactive applications that we
wanna build for this class. Coincidentally, event driven programming
is also my favorite programming model. [laugh] Alright, there is no coincidence
here. I am one of the professors teaching this
class. Obviously, I'm going to teach you one of
the models that I like best. So let's start learning about it.
Alright, so far the programs that we have written have sort of executed in this
linear fashion. What do I mean by that?
Well, the program starts. And then we run, you know blocks of code.
There's a, then b, then c, then d. And we keep going, and eventually your
program ends, okay? And each letter here, you know, like A,
this corresponds to some block of code. This might be the body of a function, it
might be part of an if statement, or the block of code after an if or an else, or
whatever, okay? But after that executes you know exactly
what's going to execute next. The only thing that can change the flow of
control of your program is the data, right?
So it doesn't mean that the programs execute exactly the same every time,
right? The different input data, maybe I do an A,
C, G. H, you know, Z, whatever, and eventually I
end. Okay, so this doesn't mean that your
program is exactly the same every time, it means that the flow of control is dictated
by how you wrote the program and what the inputs are.
So that when you get to the conditionals in the program, you know which way you're
going to go. And I can write very complicated and very
powerful programs using this model, okay. Now, in this, in this class instead
though, we're going to look at the Event-driven programming model, alright?
And what's different, okay? It does not look like this above here
instead, my program starts. I initialize every thing so I need to set
my program up. And then.
I wait, and this is the key difference. My program effectively just ends and
starts waiting, doing nothing else, Okay?
And nothing now is going to happen in my program until some event occurs, and that
doesn't mean that you can't wait up here. So imagine, you know, block H here is
looking for some sort of file input. So maybe it's waiting for you to type the
name of a file in, so it can read the name of the file in the next Q block C and move
on from there, right? The difference is, is block H is waiting
for a specific input. I'm waiting for you to type a file name.
Down here, I'm not waiting for anything in particular.
I'm just waiting. So any event.
Can occur, and I will respond to it. So some time in the future, some event
occurs We'll talk about what events are in a second, all right?
And when that event occurs, I run some function which is called a handler.
That handler executes, when it completes I go back to waiting, some time in the
future, another event occurs, right? I execute a, another handler and this
handler is probably different because that event was probably different.
When that's done, I go back to waiting. So now most of the time my program is just
sitting there waiting. Its not doing anything but whenever an
event occurs it immediately then goes off, runs a handler and executes the code in
response. Alright?
Now eventually, to end my program, I get some sort of event that corresponds to
quit. Right?
Basically says, you're done. All right?
And then the program ends at that point. Okay?
So the primary difference here is that on, on the top my program just keeps executing
code forever. On the bottom here, I keep waiting forever
until events occur. This is a fundamentally different way of
thinking about programming. Okay.
To better on your stand the event running programming model we have to talk about
events, what are these events? Okay and there is a bunch of different
kinds of events and it really depends on what type of system you're running, what
the events of interests are. So we're going to focus today on the
events that you're going to see in this class that we're going to use.
All right and I'm going to break them down to four categories and see some input
events. Keyboard.
Events, mouse events and timer events. And in these categories there's actually
some subcategories. The types of input events might be
something like a button. Or a textbox input.
Right type of keyboard events you might see are key down.
Events, or key, up events, when you release the key.
On the mouse, you might see a click event or a drag event, and a timer is something
that just happens periodically. Right? No matter what.
Okay. So these are the different kinds of events
that you are going to see in our system as we build games.
You might push buttons to set up control, you might type things into a text box to
give information to the program. As you're controlling your game, if you're
moving something around in the game, you might use the key pad to control at the
arrow keys, and when you push them down you do one thing, when you release them
you do something else. On the mouse, you might click on the
elements in the screen and you might move them around some really.
So these are the kind of events that we're going to see in our system, and for each
event that you care about, so for instance, let's say, a button event.
You're going to then write some sort of a handler.
And you're not going to write one handler for all button events.
When you create a button in your system you write a handler that handles that
particular button. Okay?
So most of the time your system, as we said, will be sitting around waiting and
when something happens, like a button gets pushed, then you go off and you'll run the
handler. So, let's take a look at our first event
driven program. Here it is, you can see it's pretty short.
It's only fourteen lines including blank lines and comments.
So, we are going to be able to walk through the entire program and it's
hopefully, we will get a good understanding of what's happening.
Now, we don't know how to build the user interface yet, and most of the events that
I have talked about have to deal, do with the user interface, clicking, buttons and
moving the things like that. So, we are just going to look at a timer
event. The timer events are critical for any
event driven program, as we've said most of the time the event driven program is
waiting, doing nothing Thing. So unless you have a timer event that
fires periodically, your program can't do anything unless the user does it.
Does some action. So instead of waiting for the user to
perform an action, we are just going to have the timer fire.
And then we'll do something on our own. Okay?
Now. Let's look at the code.
Alright, so if I get to the first line that's not a comment, you can see on line
four that we are importing simple GUI What's simple GUI?
Well, Simple GUI is a Python module that we've written for you to allow you to
build interactive applications in Python. And in a future lesson, we'll cover Simple
GUI in much more depth. For now, I don't wanna get into it.
We're just going to mostly ignore it, and I'll just give you the pieces of
information that you need, okay? Next, we're going to define an event
handler. And this event handler, I'm going to call
it Tick. You can call it anything you want.
But it takes, it's a function that takes no argument, arguments, and it does
something silly. All it does is print the word tick to the
console. Okay?
Next, on line eleven, I'm going to actually register the handler.
So this is where simple GUI comes into play.
I'm going to call a function in the simple GUI module called create timer and.
As the name implies, this going to create a timer.
The first argument is the number of milliseconds that you want to occur
between each time the timer fires. Alright, so I put 1,000 here, that means
the timer event is going to occur once every second.
The second argument is the function that you would like to call or the handler that
you would like for this timer event. And I give it tick, so this is the
function tick that we're going to execute, right.
Then finally on line fourteen. We call timer.start.
This starts the timer running. Okay.
So let's run this, and let's see what happens.
'Kay, tick. So hopefully you can see that it's
printing tick about once every second. And this is exactly what I want to happen,
right? I told it that every 1000 milliseconds you
should fire an event, that event occurs, the tick function then runs, it prints to
the console. Now.
You're going to notice something here, I can't stop this program.
There's no [laugh] kind of stuff stop event here, so it's going to keep printing
tick forever. All right, the way that I can stop this is
actually hit the reset button and code sculptor.
Now my program is done. All right, I want to point out one
additional thing about what's happening here.
You'll notice that after I call timer.start on line fourteen.
The program ends. Okay?
There's no more code here. The program is done.
Alright? This is a key to event driven programs,
where they just seem to end. That's when you go into that wait state.
Alright? And hopefully, I've already convinced you
that the program works, because you saw that, that tick was happening.
But after the program ends, you go into that wait state.
And then you start waiting for events to occur.
And in this program. Those timer events are going to occur.
And then we run the tick handler. And it'll keep doing that forever.
So there's one final concept that we need to understand in order to completely
understand event driven programming and that is the event queue.
Alright, now there's nothing that you can do to stop two events from happening at
exactly the same time. For instance imagine a timer event fires
at exactly the same time that a user pushes a button.
Alright, so how do we handle that? Well the system handles it for you.
So internally there is something called an event queue and you have, you never see
this and you have no control over it. But it is basically taking events as they
happen and the system puts. These events in this cue so the click
event happens, the timer event happens, okay, a key down.
Event happens and so on. So as events happen in the system, the
system puts it into this event queue. Which you never see.
This all goes on behind our back. Now, remember your program is sitting
there waiting. For an event to happen.
So now what the system does is when your program is waiting, it looks in the event
queue. If it sees an event, so right now there's
a click event, it'll says, oh let's take this click event, take it out of here, and
let's figure out which handler to run. Now behind your back, automatically, it
then figures out the handler, then it runs the handler.
Now your code is actually running. Okay, when your code is done, you go back
to wait. The system then looks in the event queue.
It sees hey there's a timer here. I'll take that out.
Figure out what him or I should run now. And so on right.
And it'll keep doing this untill there are no events left in the queue.
At that point right the system will then say oh, there's nothing to do.
You will wait forever'till another event occurs, alright.
And you, you can't control the order this happens but it shouldn't matter right.
Your program should be written to respond to events and do what needs to happen when
those events occur. No matter what order they occur in
alright. And I wanna make one final point.
When this handler is running, nothing else can happen.
If more events happen, they just go into this internal event queue.
Alright? So while your handler is running, you
can't run and process any more events. So what this means is if you build a
handler that is really long or maybe has an infinite loop in it, even.
Then you're stopping all other events from being processed.
This is going to make your, your program or your game very unresponsive.
So just keep that in mind. Now you've seen the event driven
programming model. Iin this model you first write your
handler functions and then you register those functions so they will get executed
in response to some events. Your program then just ends.
At that point the system takes over. And while the system is running your
program is waiting most of the time. Whenever an event occurs it first gets put
in the event queue then the system pulls these events out of the event queue one at
a time and executes the appropriate handler.
This is why this is sometimes called the Hollywood Model of programming.
Don't call us, we'll call you. Right?
You don't get to decide when your functions get called and sent, instead,
the system calls your handler functions whenever the events actually occur.
Just like a Hollywood actor who goes to an audition is told not to call them back,
right? If they decide to choose him, or her,
they'll give them a call at that point. So you don't have any guarantee what order
your handler functions will run, you just know that if and when the events occur
your handler functions will in fact run. And this is how graphical user interfaces
are built, okay? When.
You pull down a menu and select an item or you push a button.
These are events that invoke event handlers,
Okay? And this is also how we are going to write
the interesting interactive games that we are going to write throughout the
semester. Now, I hope you have come to enjoy this
model as much as I do.
Ознакомьтесь с нашим каталогом
Присоединяйтесь бесплатно и получайте персонализированные рекомендации, обновления и предложения.
Coursera делает лучшее в мире образование доступным каждому, предлагая онлайн-курсы от ведущих университетов и организаций.
© Coursera Inc., 2018 Все права защищены.
