Window-owning controls and non-window-owning controls

Controls are similar to windows in the window server, in that they are bounded areas of the screen, and are user interface elements. However, a control is not synonymous with a window, as a control may take up the whole of a window’s area, or may take up only part of it. For this reason, controls are divided into two types: window-owning controls, and non-window-owning controls.

Window-owning controls have the same size and position as a window in the window server. They may overlap each other, and may be moved around the screen within the bounds of their parent window. Dialogs, menus, toolbars and top-level controls are typically window-owning controls.

The majority of controls are non-window-owning controls. A non-window-owning control’s extent typically covers only part of a window on the screen: usually it is one of a number of controls within a larger compound control which acts as a container.

Examples of non-window-owning controls include command buttons, edit windows, and labels.

A non-window-owning control must be contained in a window-owning control at some point in the run-time control hierarchy . For this reason, non-window owning controls are also called lodger controls, because they lodge inside another control’s window.

Non-window-owning controls give greater efficiency: they require fewer resources in the window server, and result in fewer process switches. They can also result in faster redrawing and faster initialisation of compound controls, because a compound control and all its non-window-owning components can be drawn with a single flush to the window server.

All controls have an associated window, whether they are window-owning or not. For window-owning controls, their associated window is the window they own. For non-window-owning controls, their associated window is the window owned by the nearest window-owning control above them in the control hierarchy.