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