. 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.
