Program Inputs and Events

A program that never receives anything from outside itself can only ever do the one fixed thing its code says. Input is what makes a program useful: a number to calculate with, a click to react to, a photo to filter. Whatever form input arrives in on the outside, tactile taps, sound waves, images, typed text, it gets converted into the same kind of thing on the inside: data represented as bits, stored in variables the program can check and act on.

Events are how most interactive programs actually receive input. The system is always watching for things like a mouse click, a key press, or a sensor reading. The instant one happens, the system packages it as an event with details attached, such as which key, or the x and y position of the click, and hands it to a small block of code called an event handler that's registered to respond to exactly that kind of event. The handler runs, maybe updates a variable or redraws part of the screen, then control returns to waiting.

This is why event-driven programs don't run top to bottom like a sequential list of instructions. Instead the program sits idle until an event fires, runs the matching handler, then goes back to waiting, possibly for years across many different events arriving in any order. This connects forward to how programs produce output: once an event handler processes input, the next question is always what the program does with that data and what it shows or sends back out.