In general each change of a qooxdoo property fires an event (DataEvent). Of course, “firing” such an event only occurs if there has been at least one listener registered for the corresponding property. The name of these events follows the scheme: “change” + PropertyName. Valid event names for example are:

• changeElement
• changeDisplay
• changeValue

Each of these data events has a getter getData which returns the value of the property at the time the dispatch occured. It is better to use eventObject.getData instead of yourObject.getPropertyName as you might not want to use yourObject explicitly inside your event handler.

This is one of the things we really like about the qooxdoo property feature. It makes it easy to react to nearly any available change of an object just by adding an event listener.

You can get a list of all available properties of each qooxdoo object using our API reference. In the class documentation you will find the locally defined properties as well as the inherited ones.

• keydown: Fires when a key is press down. KeyIdentifier is set.
• keypress: Fires repeatedly while the key is held down. KeyIdentifier is set.
• keyinput: Fires repeatedly while the key is held down and the key is printable. CharCode is set.
• keyup: Fires when a key is press down. KeyIdentifier is set.

For a detailed description of key events look at Key Event Handling.

Please take a look at the Widget visibility.

• focusin: The focusin event occurs before a widget receives focus, for instance via a pointing device being moved onto an element or by tabbing navigation to the element.
• focus: The focusin event occurs after a widget has received focus, for instance via a pointing device being moved onto an element or by tabbing navigation to the element.
• focusout: The blur event occurs before an element loses focus either via the pointing device or by tabbing navigation.
• blur: The blur event occurs after an element lost focus either via the pointing device or by tabbing navigation.

The order of these focus events is the same as shown above and somewhat mimics the ideas of the W3C event model.

Image fires events to tell you about the success of loading the given resource. The event for a successful load is load. If the image cannot be found or is not available, Image fires an error event.

The Button (and some of the classes which inherit from it) fire an event execute on a mouse click or an ENTER key event (while the button has the focus).

Spinner fires a change event on each value change.

Iframe fires a load event after the source document has been loaded completely.

TextField and most other widgets which inherit from this class fire an input event while the user enters some text.

ComboBox fires a beforeInitialOpen event before the popup and the list are shown initially (because the user pressed the arrow or something else). This allows the list to be filled on the first open. This often reduces the execution time of your application main method as the calculation of the list contents is delayed.

The timer class fires an event for each interval. Not hard to guess the name of the event: it is just interval.

Command fires an execute event on each execution.

The SelectionManager fires changeSelection events.

RangeManager fires the change events on each modification of the min, max or value properties.

ImagePreloader fires events to tell you about the success of loading the given resource. The event for a successful load is load. If the image cannot be found or is not available, ImagePreloader fires an error event.

The preloader system ImagePreloaderSystem fires a single event after the list has loaded successfully. The name of the event fired is completed.