Note: The NO_BACKGROUND, NO_FOCUS, NO_MERGE_PAINTS,
and NO_REDRAW_RESIZE styles are intended for use with Canvas.
They can be used with Composite if you are drawing your own, but their
behavior is undefined if they are used with subclasses of Composite other
than Canvas.

Note: The CENTER style, although undefined for composites, has the
same value as EMBEDDED which is used to embed widgets from other
widget toolkits into SWT. On some operating systems (GTK), this may cause
the children of this composite to be obscured.

This class may be subclassed by custom control implementors
who are building controls that are constructed from aggregates
of other controls.

Constructor Detail

Composite

Constructs a new instance of this class given its parent
and a style value describing its behavior and appearance.

The style value is either one of the style constants defined in
class SWT which is applicable to instances of this
class, or must be built by bitwise OR'ing together
(that is, using the int "|" operator) two or more
of those SWT style constants. The class description
lists the style constants that are applicable to the class.
Style bits are also inherited from superclasses.

Parameters:

parent - a widget which will be the parent of the new instance (cannot be null)

Method Detail

changed

Clears any data that has been cached by a Layout for all widgets that
are in the parent hierarchy of the changed control up to and including the
receiver. If an ancestor does not have a layout, it is skipped.

Parameters:

changed - an array of controls that changed state and require a recalculation of size

checkSubclass

The SWT class library is intended to be subclassed
only at specific, controlled points (most notably,
Composite and Canvas when
implementing new widgets). This method enforces this
rule unless it is overridden.

IMPORTANT: By providing an implementation of this
method that allows a subclass of a class which does not
normally allow subclassing to be created, the implementer
agrees to be fully responsible for the fact that any such
subclass will likely fail between SWT releases and will be
strongly platform specific. No support is provided for
user-written classes which are implemented in this fashion.

The ability to subclass outside of the allowed SWT classes
is intended purely to enable those not on the SWT development
team to implement patches in order to get around specific
limitations in advance of when those limitations can be
addressed by the team. Subclassing should not be attempted
without an intimate and detailed understanding of the hierarchy.

getChildren

Returns a (possibly empty) array containing the receiver's children.
Children are returned in the order that they are drawn. The topmost
control appears at the beginning of the array. Subsequent controls
draw beneath this control and appear later in the array.

Note: This is not the actual structure used by the receiver
to maintain its list of children, so modifying the array will
not affect the receiver.

layout

public void layout()

If the receiver has a layout, asks the layout to lay out
(that is, set the size and location of) the receiver's children.
If the receiver does not have a layout, do nothing.

Use of this method is discouraged since it is the least-efficient
way to trigger a layout. The use of layout(true)
discards all cached layout information, even from controls which
have not changed. It is much more efficient to invoke
Control.requestLayout() on every control which has changed
in the layout than it is to invoke this method on the layout itself.

This is equivalent to calling layout(true).

Note: Layout is different from painting. If a child is
moved or resized such that an area in the parent is
exposed, then the parent will paint. If no child is
affected, the parent will not paint.

ERROR_THREAD_INVALID_ACCESS - if not called from the thread that created the receiver

layout

public void layout(boolean changed)

If the receiver has a layout, asks the layout to lay out
(that is, set the size and location of) the receiver's children.
If the argument is true the layout must not rely
on any information it has cached about the immediate children. If it
is false the layout may (potentially) optimize the
work it is doing by assuming that none of the receiver's
children has changed state since the last layout.
If the receiver does not have a layout, do nothing.

It is normally more efficient to invoke Control.requestLayout()
on every control which has changed in the layout than it is to invoke
this method on the layout itself. Clients are encouraged to use
Control.requestLayout() where possible instead of calling
this method.

If a child is resized as a result of a call to layout, the
resize event will invoke the layout of the child. The layout
will cascade down through all child widgets in the receiver's widget
tree until a child is encountered that does not resize. Note that
a layout due to a resize will not flush any cached information
(same as layout(false)).

Note: Layout is different from painting. If a child is
moved or resized such that an area in the parent is
exposed, then the parent will paint. If no child is
affected, the parent will not paint.

Parameters:

changed - true if the layout must flush its caches, and false otherwise

ERROR_THREAD_INVALID_ACCESS - if not called from the thread that created the receiver

layout

public void layout(boolean changed,
boolean all)

If the receiver has a layout, asks the layout to lay out
(that is, set the size and location of) the receiver's children.
If the changed argument is true the layout must not rely
on any information it has cached about its children. If it
is false the layout may (potentially) optimize the
work it is doing by assuming that none of the receiver's
children has changed state since the last layout.
If the all argument is true the layout will cascade down
through all child widgets in the receiver's widget tree, regardless of
whether the child has changed size. The changed argument is applied to
all layouts. If the all argument is false, the layout will
not cascade down through all child widgets in the receiver's widget
tree. However, if a child is resized as a result of a call to layout, the
resize event will invoke the layout of the child. Note that
a layout due to a resize will not flush any cached information
(same as layout(false)).

It is normally more efficient to invoke Control.requestLayout()
on every control which has changed in the layout than it is to invoke
this method on the layout itself. Clients are encouraged to use
Control.requestLayout() where possible instead of calling
this method.

Note: Layout is different from painting. If a child is
moved or resized such that an area in the parent is
exposed, then the parent will paint. If no child is
affected, the parent will not paint.

Parameters:

changed - true if the layout must flush its caches, and false otherwise

all - true if all children in the receiver's widget tree should be laid out, and false otherwise

layout

Forces a lay out (that is, sets the size and location) of all widgets that
are in the parent hierarchy of the changed control up to and including the
receiver. The layouts in the hierarchy must not rely on any information
cached about the changed control or any of its ancestors. The layout may
(potentially) optimize the work it is doing by assuming that none of the
peers of the changed control have changed state since the last layout.
If an ancestor does not have a layout, skip it.

It is normally more efficient to invoke Control.requestLayout()
on every control which has changed in the layout than it is to invoke
this method on the layout itself. Clients are encouraged to use
Control.requestLayout() where possible instead of calling
this method.

Note: Layout is different from painting. If a child is
moved or resized such that an area in the parent is
exposed, then the parent will paint. If no child is
affected, the parent will not paint.

Parameters:

changed - a control that has had a state change which requires a recalculation of its size

layout

Forces a lay out (that is, sets the size and location) of all widgets that
are in the parent hierarchy of the changed control up to and including the
receiver.

The parameter flags may be a combination of:

SWT.ALL

all children in the receiver's widget tree should be laid out

SWT.CHANGED

the layout must flush its caches

SWT.DEFER

layout will be deferred

When the changed array is specified, the flags SWT.ALL
and SWT.CHANGED have no effect. In this case, the layouts in the
hierarchy must not rely on any information cached about the changed control or
any of its ancestors. The layout may (potentially) optimize the
work it is doing by assuming that none of the peers of the changed
control have changed state since the last layout.
If an ancestor does not have a layout, skip it.

When the changed array is not specified, the flag SWT.ALL
indicates that the whole widget tree should be laid out. And the flag
SWT.CHANGED indicates that the layouts should flush any cached
information for all controls that are laid out.

The SWT.DEFER flag always causes the layout to be deferred by
calling Composite.setLayoutDeferred(true) and scheduling a call
to Composite.setLayoutDeferred(false), which will happen when
appropriate (usually before the next event is handled). When this flag is set,
the application should not call Composite.setLayoutDeferred(boolean).

Note: Layout is different from painting. If a child is
moved or resized such that an area in the parent is
exposed, then the parent will paint. If no child is
affected, the parent will not paint.

Parameters:

changed - a control that has had a state change which requires a recalculation of its size

ERROR_THREAD_INVALID_ACCESS - if not called from the thread that created the receiver

setLayoutDeferred

public void setLayoutDeferred(boolean defer)

If the argument is true, causes subsequent layout
operations in the receiver or any of its children to be ignored.
No layout of any kind can occur in the receiver or any of its
children until the flag is set to false.
Layout operations that occurred while the flag was
true are remembered and when the flag is set to
false, the layout operations are performed in an
optimized manner. Nested calls to this method are stacked.