Loading...
 

Attach

Attach

Attach(Objektname[, Widget],  Flags[, Abstand])
Parameters
Parameters Description Optional?
Object name Window object Not optional
Widget Widget (default: current window) Optional
Flags any number of the flags listed below At least one
Distance Distance to widget or window in Minicells Optional, default is 0

Creates a connection between a window object and a window or other widget, whereby the window object remains attached to the desired window edge when the window size is changed. Flags allowed are LEFT, RIGHT, BOTTOM, TOP, OPPOSITE, STRETCH and OFF. The following parameter gives the distance to the window edge or widget in minicells.

Several directional flags can also be combined in one attachment.

Attach(LEFT, RIGHT, TOP, BOTTOM, STRETCH, 5)

is equivalent to:

Attach(LEFT, STRETCH, 5)
Attach(RIGHT, STRETCH, 5)
Attach(TOP, STRETCH, 5)
Attach(BOTTOM, STRETCH, 5)
Flags
Flag Description
LEFT Attaching the left edge of the widget.
RIGHT Attack the right edge of the widget.
BOTTOM Attaching the bottom edge of the widget
TOP Attaching the upper edge of the widget.
OPPOSITE

Attached to the opposite side of the target widget.

STRETCH

If the position of the attachment target changes, the widget is not moved but resized.
Note: STRETCH can only be applied to a widget within a plane and an axis. If several
widgets are STRETCH-attached on the same plane on the same axis, then only one STRETCH-attachment
when resizing the parent widget.

OFF

In derived widgets: removes previous attachments in all basic widgets (see link).

Layouting Mechansimus

Note: The following section applies only to the native layouting mechanism. In MorphIT, the attachments are translated into CSS rules. More information on this can be found at: MorphIT Layouting.

Example:

Window(Layout4, 0,0,1000, 300, "Layout 4") { Group(g1, 0, 0, 1000, 300, "columns") { Group(g11, 0, 0, 200, 100, "left") Group(g12, 250, 0, 200, 100, "right") Attach(g11, LEFT, TOP, BOTTOM, STRETCH, 10) Attach(g12, TOP, RIGHT, BOTTOM, STRETCH, 10) Attach(g11, g12, RIGHT, OPPOSITE, 10) } Attach(g1, TOP,LEFT,RIGHT,BOTTOM,STRETCH, 10) //Fill complete window }

233631 the evaluation order of the attachment mechanism was revised internally. The result is as follows:

New attachment calculation (per dimension)

Explanation of the picture: Green arrows indicate the attachments for group g11, blue arrows the attachments for group g12. The numbers on the arrows indicate the order in which they are evaluated by the layouting mechanism. An s(tretch) at the number indicates that the size of the widget is changed in this direction. If two arrows have the same number, then no fixed order of evaluation is defined for these attachments. The spacing of the group is smaller towards the top than towards the bottom because the title and frame of the parent group are subtracted from the spacing.

The order in which the attachments are evaluated is determined as follows:

  1. The attachments and constraints are split by dimension (horizontal/vertical)1 and the following steps are performed separately for both dimensions (horizontal, then vertical).
  2. The attachments and constraints are collected in groups per widget they describe.
  3. The parent window and all widgets without attach statements are marked as fully layouted.
  4. If all attachments of a widget refer only to fully layouted widgets, then:
    1. First the attachments of the widget without STRETCH are evaluated.
    2. Then the attachments of the widget with STRETCH are evaluated.
    3. Then the contraints of the widget evaluated
    4. Then the widget is marked as fully layouted
  5. Step 4 is repeated until all attaches have been processed.
  6. If step 4 does not find any possible widgets before all widgets have been marked as complete, then the layout contains a cyclic dependency and an error is reported.

This sorting ensures that Zinc's layouting mechanism requires only one pass for each valid layout to be evaluated and that the attachments can be specified in the source code in any order. For performance reasons, this sorting of the attachments is not carried out with each resize, but once when the window is opened.

1= An attachment definition such as Attach(widget, TOP, LEFT, RIGHT, BOTTOM, STRETCH) is automatically split into the following two definitions: Attach(widget, TOP, BOTTOM, STRETCH) and Attach(widget, LEFT, RIGHT, STRETCH).

Old layouting mechanism

Until Dll version 233631, the processing order of the attachments was defined in a much simpler way, which leads to the following result in the code example above (and the problem with Move described below):
Attachments

Explanation of the image: Green arrows indicate the attachments for group g11, blue arrows indicate the attachments for group g12. The numbers on the arrows indicate the order in which they are evaluated by the layouting mechanism. An s(tretch) on the number indicates that the size of the widget is changed in this direction. The spacing of the group is smaller towards the top than towards the bottom, because the title and frame of the parent group are subtracted from the spacing.

Note: If the window is opened for the first time and not resized by hand, the left group has a significantly larger distance to the left edge due to the evaluation order of the attaches. For the correct construction of this layout, 2 passes of the attach mechanism are necessary (i.e. a subsequent resize of the window).

The order in which the attachments are evaluated is defined as follows:

  1. All attachments in which the widgets are attached to their parent widget (in the order in which they appear in the source code)
  2. All attachments in which the widgets are attached to other widgets at the same level (in the order in which they appear in the source code)

In most cases you don't have to worry about the processing of the attachments, because the rules ensure that regardless of the order of the attachments in the source code, the layout will work in most cases. The rules are important when widgets are moved or enlarged interactively at runtime.

If, for example, the group g12 (right) is moved to the left by Move, the result will not meet the expectations, because the left group (g11) is simply moved out to the left, as you can see in the next picture:

Attachments2

This problem is caused by the order in the attachment evaluation. After moving group g12 to the left, the attachments are evaluated as follows

  1. Attach(g11, LEFT, TOP, BOTTOM, STRETCH, 10): Since the group itself has not been moved to the left, up and down and still has the same distance to the parent group, nothing happens here.
  2. Attach(g12, TOP, RIGHT, BOTTOM, STRETCH, 10): Because the group g12 has been moved to the left, the distance of the right margin to the parent group is no longer correct. The STRETCH-flag enlarges the group to the right as desired.
  3. Attach(g11, g12, RIGHT, OPPOSITE, 10): The attachment target (left edge of group g12) has changed, so now the right edge of group g11 is realigned. However, since no STRETCH is specified here, the whole group is moved to the left as a result, which causes the group to be moved out of the window on the left.

The problem can be solved by rewriting the attachments as follows:

Attach(g11, TOP, BOTTOM, STRETCH, 10) Attach(g11, LEFT, 10) Attach(g12, TOP, RIGHT, BOTTOM, STRETCH, 10) Attach(g11, g12, RIGHT, OPPOSITE, STRETCH, 10)