Northern IrelandSoftware Systems DevelopmentSyllabus dot point

What is event driven programming, and how do events, event handlers and the event loop drive an application?

The event driven paradigm - events, event handlers, the event loop, event-driven versus procedural programming, and the roles of the operating system and the program.

A CCEA A-Level Software Systems Development answer on the event driven paradigm: what events and event handlers are, how the event loop dispatches them, and how event-driven programming differs from procedural programming.

Generated by Claude Opus 4.812 min answerUpdated 2026-06-16

Reviewed by: AI editorial process; not yet individually human-reviewed

Have a quick question? Jump to the Q&A page

Jump to a section

What this dot point is asking
The answer
Examples in context
Try this

What this dot point is asking

CCEA wants you to explain the event driven paradigm: what an event is, what an event handler does, how the event loop waits for and dispatches events, and how event driven programming differs from procedural programming. You should describe the cooperation between the operating system (which detects raw input) and the program (which responds), and recognise why this model suits graphical applications. Definitions and the procedural contrast are examined directly.

The answer

Events and event handlers

Events can be raised by the user (clicks, key presses), by the system (a timer tick, a window resize) or by the program itself. The handler is "wired" to its event, so clicking the "Save" button runs the save button's click handler and nothing else.

The event loop

The operating system detects raw input (a physical click or keypress) and notifies the application; the application's event loop turns that into a high-level event and calls the right handler. The program is therefore mostly reactive: idle until something happens.

Event driven versus procedural programming

The defining contrast is who controls the flow:

In procedural programming, the program follows a fixed sequence of instructions the programmer set in advance, calling procedures in order and prompting the user for data when needed. The program drives.
In event driven programming, the user (or system) drives: the user chooses which control to use and when, and the program reacts by running the relevant handler. There is no single fixed path through the code.

Event driven programming suits graphical user interfaces (GUIs), where a window may offer many buttons, fields and menus that can be used in any order.

Worked example: tracing event flow in a simple form

A form with two buttons

A window has a text box txtName, a "Greet" button and a "Clear" button. Describe what happens, in terms of events and handlers, when the user types a name and clicks "Greet", then "Clear".

step The program reaches the event loop and waits

After the form loads, the program enters its event loop and sits idle. No handler runs until the user does something.

step The user types and clicks "Greet"

Each keystroke raises a key event on txtName, updating its Text. Clicking "Greet" raises a click event; the event loop dispatches it to the Greet button's click handler:

on btnGreet.Click:
    lblOut.Text = "Hello " + txtName.Text

The handler reads the text box and updates a label, then returns to the loop.

step The user clicks "Clear"

A click event is raised on "Clear"; its handler runs:

on btnClear.Click:
    txtName.Text = ""
    lblOut.Text  = ""

After it completes, control returns to the event loop, which waits again. The user could have clicked the buttons in the opposite order; the program would simply have run the handlers in that order, because the user controls the flow.

Examples in context

Example 1. A desktop calculator. Each digit and operator button has a click handler. The user presses buttons in any order they like; the program reacts to each click, building the expression. There is no fixed sequence, the calculator simply waits in its event loop and responds, which is exactly why a GUI calculator is written in an event driven style rather than a procedural one.

Example 2. A timed quiz. A timer control raises a tick event every second, and its handler decreases a countdown and updates a label. Meanwhile button click handlers record answers. Several event sources (the timer and the buttons) feed the same event loop, and the program responds to whichever fires, showing system-raised and user-raised events together.

Try this

Q1. Define the term event and give two examples. [2 marks]

Cue. An event is an action or occurrence the program detects; examples include a button click, a key press, a mouse move or a timer tick.

Q2. State what an event handler is and when its code runs. [2 marks]

Cue. An event handler is a block of code wired to a particular event; its code runs only when that event occurs.

Q3. State the key difference between procedural and event driven programming in terms of control of flow. [2 marks]

Cue. Procedural code follows a fixed sequence the program controls; event driven code reacts to the user, who controls the order by triggering events.

Exam-style practice questions

Practice questions written in the style of CCEA exam questions on this dot point, with worked answer explainers. The year tag is the paper they imitate, not the source.

CCEA 20196 marksExplain what is meant by event driven programming, and describe the difference between event driven and procedural programming.

Show worked answer →

Event driven programming is a style in which the flow of the program is determined by events, such as a button being clicked, a key being pressed or a timer firing. The program waits in an event loop, and when an event occurs the matching event handler (a block of code) runs in response. The order in which code runs depends on the order the user (or system) triggers events, not on a fixed sequence written by the programmer.

Procedural programming, by contrast, follows a predetermined sequence of instructions from start to finish, calling procedures in an order the programmer fixed in advance. The program controls the flow; the user supplies data when asked.

The key difference is who controls the flow: in procedural code the program drives and prompts the user step by step, whereas in event driven code the user drives, choosing what to do and when, and the program reacts. Event driven programming suits graphical user interfaces, where many controls can be used in any order.

Markers reward a correct definition of event driven programming (flow controlled by events handled by handlers), the procedural contrast (fixed sequence the program controls), and the who-controls-the-flow distinction.

CCEA 20214 marksDescribe the role of the event loop in an event driven program, and explain what happens when an event is triggered.

Show worked answer →

The event loop is a continuous loop, running in the background, that waits for events and dispatches them. While idle the program sits in this loop doing nothing visible, ready to respond.

When an event is triggered, for example the user clicks a button, the event is placed in an event queue. The event loop takes the event from the queue, identifies which control raised it and which event it was, and calls the associated event handler (the code written to respond to that event). The handler runs to completion, then control returns to the loop, which waits for the next event.

So the cycle is: wait, detect an event, queue it, dispatch it to its handler, run the handler, return to waiting. This lets a single program respond to many possible inputs in any order.

Markers reward describing the loop as continuously waiting for and dispatching events, the queue and handler mechanism, and the return to waiting after the handler completes.

Related dot points

Sources & how we know this

CCEA GCE Software Systems Development specification — CCEA (2016)