Event-Driven Programming - How does an event know when to occur?

Question

In the past few weeks I've been really into what happens "behind the scenes" in softwares, and there is something that really interests me - how does an event in Event-Driven Programming know when to occur?
Let me explain: Let's say we have a button in a GUI, how does the button know when it was pressed? Is there a loop that runs constantly and once it detects the button press it activates the event or is there a more efficient method?

Answer 1

There are two different models that may present themselves here:

1/ The library takes control of the "event loop" - intercepting user events, OS events, etc., and relies on a (user-defined) callback mechanism to deal with specific events: (keyboard, mouse, etc.)

2/ The user must manage the event loop: check for events, dispatch based on the event, and (typically) return to event loop.

It would be helpful if you could provide more specifics.

Answer 2

In the case of a button, and how it knows it was clicked, I can only speak from experience with Windows programming, though I'm pretty sure it can be extrapolated to cover other types of operating systems and windowing systems.

Windows, the operating system, will keep tabs on your input devices, such as your mouse. When it detects, or probably more appropriately, is told that you clicked on one of the mouse button, it records a lot of information and then goes searching for what to do with that information.

I am guessing here, but it probably gets told through an interrupt, something that pings the CPU and tells it something special just happened.

With the information the operating system record, such as which mouse, which button, and where the mouse pointer was at the time, is used to determine what happens with that information.

Specifically, Windows tries to find out which program, window, and component in that window should be told about the mouse click. When it has found out where the mouse click went, it puts a message into the message queue of the thread that owns that window.

A message queue is like a loop that runs constantly, but it will stop whenever nothing is happening, ie. when no messages are put into its queue. So the message that was created because you clicked your mouse is being put into the message queue of that thread, and the message queue gets that message and processes it.

A message queue loop looks somewhat like this:

Message msg;
while (GetNextMessage(out msg))
{
    ProcessMessage(msg);
}

Processing it here means that the thread figures out which internal component of the window the message should go to, and then calls a method on that component, giving it the message.

So basically your mouse click ends up being a normal method call on the button object.

That's all there is to it.

In .NET the method in question is named WndProc.

Now, what do we have event driven programming. What's the alternative?

Well, one thing you could do was create a new button class every time you need a new button in a window, embedding the code that should happen when you clicked the button inside that class.

This would get tiresome really quick, you would do the same thing over and over again, every time you need a new button.

In truth, the only thing that differs is what happens when you click the button.

So instead of creating a new button every time you need a new one in your program, let's make one button class that can do everything.

Except, how can that one class do everything? It can't, which is why, when the button is clicked, it needs some way of informing the owning program / window that it was clicked, so that whatever is specific to this button can be done.

And that's why events was created. You can create a generic button type that will signal to the outside world (outside of the button type) that specific things, "events" happen, and not care one bit about what actually happens.

Answer 3

Basically the way it works is that when you click the mouse button it generates a hardware interrupt that halts the currently executing thread and causes the OS to run a specific piece of code for handling that type of interrupt. In Windows this causes a message to be generated which is added to the event queue in a running application. At this point the thread that was interrupted to handle the hardware interrupt is resumed (or possibly some other thread). A GUI application essentially is constantly looping and checking for messages in this queue and when it gets one it will process it by doing something like check the x and y position of the mouse click to see if that is within the bounds of a button and if it is it will call some user specified code (the click event handler for that button). All of this is usually abstracted away to the point where you just supply the code that should be called when the button is clicked.