SAM MORRELL


ASTROPHYSICIST

My Explanation of Event Driven Programming

February 22, 2010   |   Reading time: ~8 mins

Another geek / philosophy post for y’all now. In computing classes in college I get very, very frustrated at times because the way we are taught programming is very superficial. First problem, we are taught Visual Basic.net. I have a big problem with Visual Basic as a first language. Sure, it’s a really nice language, it’s got nice straightforward Object-Orientated Programming, simple memory management and it’s just the thing for someone with little experience with programming… but at the same time it has the reputation of being the one common use language that salutes a middle finger to common syntax. Nearly every other language, including the big ones such as C, C++, PHP and Javascript, all use similar syntax punctuated with plenty of braces and semi-colons. If someone coming from VB looked at that, they’d most likely be lost, like me.

But the main problem I have with computing is that it doesn’t really go in depth to how the framework works and how when you press a button it translates to a text box popping up on the screen. It’s true that most people in the class wouldn’t want or even need to know this but I’m a tricky person like that, so with this in mind I started thinking. If I had to make a GUI framework, how would I do it? How would I make that click translate to actions and things happening. With both a little knowledge and a little common sense I’ve come to write this post, for a little fun really.

So what are events and what is event driven programming, well it’s simple. Let me explain. You know on your computer when you click a button or select something from a menu to do something? Well, each of those things is an event, an event is basically something you do that triggers off something else, for example clicking a button which causes a dialog box to pop up or a picture to open, it’s all just events. What is event driven programming you ask? Well, that’s the art of putting these events into action, luckily for you almost everything nowadays makes it easy for you by doing all the ground work and having all of what I’m about to go through setup, so don’t let this article put your off programming, it really is a lot simpler than this to start off with. Let’s get started.

The Explanation

Let’s get started with the fun stuff. First of all you have to imagine that we have the average window with a button on it and a text box, lets keep this nice and simple. Let’s now imagine we have a tree of objects for this situation stemming from the application at the base of the tree. Each of these objects are just like the objects we’re used to in OOP, they have both public and private properties and methods.

Window Class-Diagram

As you see it seems nice and simple, the classes are nice and pre-written, they just work. But me being awkward I wanted to delve into how these objects implement the Event Driven nature that they have. We all know that when you click a button, something somewhere will happen, sometimes you have no idea what but it’s just shouting ‘click me!’ so you gotta do what you gotta do. First off I’ll take a page from the book of Apple’s Cocoa framework and implement ‘The Loop’. ‘What the hell is this?!’ I hear you asking, don’t worry I’ll get there soon. If we’re working from scratch we can’t just magically expect our procedural language to suddenly accept button presses so we have to do a little bit of innovating here, running under almost ever Mac application (well, probably nearly all apps in existence if truth be told) there’s one long loop running the show. I imagine it looks a little like this…

Presentation1

As you can see from the graphic, it really is a loop. Let me explain my madness a little. This loops is the ideal setup for ED (Event Driven) as it fits in nicely with procedural programming so the computer is happy but it appears to the user as though everything is happening as they click. What you have to do is think of the button as a sender of a message, the message has the address of an object it wants to send the message too and the instruction (in this case probably the method it wants the object to execute). This gets passed into a holding place, I picture it as a list personally, each object on the form having it’s own index in the list with which to post messages. When  the message gets sent it gets stored in this list, when the loop starts it runs a subroutine which checks for messages it’s received since the last loop, the next step is to then send these messages to their recipients, the objects on the other end. The loop then waits a little for any objects to send back messages with which the program has to act on before the window is sent to the graphics hardware to render it to the users screen.

I expect it’s at this point you’re wondering, why can we do this and still give the impression that everything is happening immediately as the user clicks? Good question I say, you have to bare in mind that the computer is a very fast machine, this is message sending stuff is relatively simple to it so it can do it very fast, many times per second in fact. Now, we must also bare in mind that most computer monitors nowadays update at a rate of 60Hz, meaning that a new picture is shown on the screen every 60th of a second, so the computer only has to run the loop 60 times per second to make it seem completely on-the-fly.

So that’s the loops explained, we can make it seamless by making it very fast, so the message sending is dealt with, but how about the events, how are they triggered.

Widnow_ClickMe

Now when I look at the window of our application There’s something that’s dying to be done. That button needs to be clicked! Now! But there’s one problem that I can think of, how do we know that it’s the button that’s been clicked?

Windows_3d-view

As the graphic above demonstrates, we know where the mouse is on the window, and we know that the mouse has clicked on the button but the problem is how do we get the computer to know that it’s there. Well, we know where the button is on the window (denoted by the location property of the button) and we know how big the button is (denoted by width and height property of the button), with a little simple maths this gives us the area in which the button can be clicked and something will happen. We can then use some simple logic on the computer’s part to search through the tree of objects that we had before. If we know that the click was inside the window we can then search inside the window object, if we know that the button is inside the windows object then we can check the properties of the button object to see if the mouse is in the range of values that would equate to the clickable area of the button, in this case it’s a big, fat yes! it’s at this point we can send a message into ‘the loop’ to trigger off our event.

Well, that’s a small insight into my twisted thinking of computers, personally I’ve enjoyed writing this, it’s been a rather complex article discussing some in depth stuff without a single line of code, just the way I like it. Let me know what you think and whether I should do more of this kind of thing in the future, and most importantly let me know where you are confused, I’ve tried my best not to get it wrong or make it too mad so someone with a moderate understanding of programming should get most of it, but one can never be too careful.

Thanks for reading and hope you’ve learnt a bit.

Leave a Reply

Your email address will not be published. Required fields are marked *

Comments

Sorry, there are currently no comments for this artcle. Why not start a conversation?