Basic Concepts - Events

GUI programming is different to videogame programming. In videogames, everything is driven by the vertical blank. Each time the screen redraws the code needs to do something. By contrast, GUI programming is event-driven. If the user isn't manipulating the screen - isn't dragging windows or clicking buttons - the GUI doesn't need to do anything.

Events turn the control of a GUI-based application upside-down. In games, we need to check all of our sprites to see if they have collided with something, and if so, we need to run a piece of code that processes the collision. The onus is on the program to check if something has happened every time the screen refreshes. In GUI-based applications, it works the other way around. We don't need to check if a button has been clicked or a window has been dragged - the gadgets automatically *tell* us when those events have happened. This is called an "event system".

Woopsi's Events

Woopsi implements a fairly simple event system. Each gadget can contain an instance of an "EventHandler" class, which defines a specific set of functions that are executed when an event occurs. The appropriate function is executed for each different type of event.

Events currently implemented in Woopsi are:

Not every gadget will fire every event. The "value changed" event only makes sense for textboxes, radio buttons, and so on. Windows do not have their values changed, since they do not store an internal value to change.

User Actions

User actions are detected by the main Woopsi class and distributed through the gadget hierarchy to any relevant gadgets. They are distributed differently depending on the nature of the action. Clicks, for example, are routed to the gadget that was clicked; the clicked gadget then raises a "clicked" event that can be processed by an EventHandler. Conversely, lid opening or closing is sent to all gadgets so that they can perform any halt operations.

User actions are distributed through the Woopsi hierarchy like this: