Home | All Classes | Main Classes | Annotated | Grouped Classes | Functions

Object Trees and Object Ownership

TQObjects organize themselves in object trees. When you create a TQObject with another object as parent, it's added to the parent's children() list, and is deleted when the parent is. It turns out that this approach fits the needs of GUI objects very well. For example, a TQAccel (keyboard accelerator) is a child of the relevant window, so when the user closes that window, the accelerator is deleted too.

The static function TQObject::objectTrees() provides access to all the root objects that currently exist.

TQWidget, the base class of everything that appears on the screen, extends the parent-child relationship. A child normally also becomes a child widget, i.e. it is displayed in its parent's coordinate system and is graphically clipped by its parent's boundaries. For example, when the an application deletes a message box after it has been closed, the message box's buttons and label are also deleted, just as we'd want, because the buttons and label are children of the message box.

You can also delete child objects yourself, and they will remove themselves from their parents. For example, when the user removes a toolbar it may lead to the application deleting one of its TQToolBar objects, in which case the tool bar's TQMainWindow parent would detect the change and reconfigure its screen space accordingly.

The debugging functions TQObject::dumpObjectTree() and TQObject::dumpObjectInfo() are often useful when an application looks or acts strangely.