Lade...
 

Anhängen

Attach

Attach(Objektname[, Widget],  Flags[, Abstand])
Parameter
Parameter Beschreibung Optional?
Objektname Windowobjekt Nicht optional
Widget Widget (Default: aktuelles Fenster) Optional
Flags beliebig viele der nachfolgend angegebenen Flags Mindestens eins
Abstand Abstand zum Widget oder Fenster in Minicells Optional, default ist 0

Erstellt eine Verbindung zwischen einem Windowobjekt und einem Fenster oder einem anderen Widget, wobei bei der Änderung der Fenstergröße das Windowobjekt am gewünschten Fensterrand befestigt bleibt. Als Flags sind LEFT, RIGHT, BOTTOM, TOP, OPPOSITE, STRETCH und OFF erlaubt. Der darauf folgende Parameter gibt den Abstand zum Fensterrand oder Widget in Minicells.

Es können auch mehrere Richtungs-Flags in einem Attachment kombiniert werden.

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

ist äquivalent zu:

Attach(LEFT, STRETCH, 5)
Attach(RIGHT, STRETCH, 5)
Attach(TOP, STRETCH, 5)
Attach(BOTTOM, STRETCH, 5)
Flags
Flag Beschreibung
LEFT Linken Rand des Widgets attachen.
RIGHT Rechten Rand des Widgets attachen.
BOTTOM Unteren Rand des Widgets attachen
TOP Oberen Rand des Widgets attachen.
OPPOSITE

Attached an die gegenüberliegende Seite des Zielwidgets.

STRETCH

Ändert sich die Position des Attachment-Ziels, dann wird das Widget nicht verschoben, sondern in der Größe angepasst.
Achtung: STRETCH kann innerhalb einer Ebene und einer Achse nur auf ein Widget angewandt werden. Sollten mehrere
Widgets auf der gleichen Ebene in der gleichen Achse STRETCH-Attached sein, dann wird sich nur ein STRETCH-Attachment
beim Resizen des Parent-Widgets durchsetzen.

OFF

In abgeleiteten Widgets: entfernt vorangegangene Attachments in allen basis Widgets (siehe Link).

 

Layouting Mechansimus

Hinweis: Der folgende Abschnitt gilt nur für den nativen Layouting-Mechanismus. In MorphIT werden die Attaches in CSS-Regeln übersetzt. Mehr Informationen dazu gibt es unter: MorphIT Layouting.

Beispiel:  

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 wurde die Auswertungsreihenfolge des Attachment-Mechanismus intern überarbeitet. Das Ergbnis sieht wie folgt aus:

New attachment calculation (per dimension)

Erklärung zum Bild: Grüne Pfeile geben die Attachments für die Gruppe g11 an, blaue Pfeile die Attachments für die Gruppe g12. Die Zahlen an den Pfeilen geben an, in welcher Reihenfolge sie vom Layouting-Mechanismus ausgewertet werden. Ein s(tretch) an der Zahl gibt an, dass in diese Richtung die Größe des Widgets verändert wird. Haben zwei Pfeile die gleiche Zahl, dann ist keine feste Reihenfolge der Auswertung für diese Attachments definiert. Der Abstand der Gruppe ist nach oben hin kleiner, als nach unten, weil der Titel und Rahmen der Parent-Gruppe von dem Abstand abgezogen werden.

Die Reihenfolge in der die Attachments ausgewertet werden, wird wie folgt bestimmt:

  1. Die Attachments und Constraints werden nach Dimension (horizontal/vertikal) aufgeteilt1 und die folgenden Schritte werden für beide Dimensionen getrennt durchgeführt (horizontal, dann vertikal).
  2. Die Attachments und Contraints werden pro Widget, welches sie beschrieben, gruppiert aufgesammelt.
  3. Das Parent-Fenster und alle Widgets ohne Attach-Anweisungen werden als vollständig gelayouted markiert.
  4. Falls sich alle Attachments eines Widgets nur auf vollständig gelayoutete Widgets beziehen, dann werden:
    1. Zuerst die Attaches des Widgets ohne STRETCH ausgewertet
    2. Dann die Attaches des Widgets mit STRETCH ausgewertet
    3. Dann die Contraints des Widgets ausgertet
    4. Dann wird das Widget als vollständig gelayouted markiert
  5. Schritt 4 wird solange wiederholt, bis alle Attaches verarbeitet wurden.
  6. Sollte Schritt 4 keine möglichen Widgets finden, bevor alle Widgets als vollständig markiert wurden, dann enthält das Layout eine zyklische Abhängigkeit und es wird ein Fehler gemeldet.

Diese Sortierung stellt sicher, dass der Layouting-Mechanismus von Zinc für jedes gültige Layout nur einen Durchlauf für die Auswertung benötigt und die Attachments im Sourcecode in beliebiger Reihenfolge angegeben werden können. Aus Performance-Gründen wird diese Sortierung der Attaches nicht bei jedem Resize vorgenommen, sondern einmalig beim Öffnen des Fensters.

1= Eine Attachment-Definition, wie Attach(widget, TOP, LEFT, RIGHT, BOTTOM, STRETCH) wird hierfür automatisch aufgeteilt in die folgenden zwei Definitionen: Attach(widget, TOP, BOTTOM, STRETCH) und Attach(widget, LEFT, RIGHT, STRETCH).

Alter Layouting-Mechanismus

Bis Dll-Version 233631 war die Verarbeitungsreihenfolge der Attaches deutlich einfacher definiert, was bei dem Codebeispiel oben zu dem folgenden Ergebnis führt (und dem unten beschriebenen Problem mit Move):
Attachments

Erklärung zum Bild: Grüne Pfeile geben die Attachments für die Gruppe g11 an, blaue Pfeile die Attachments für die Gruppe g12. Die Zahlen an den Pfeilen geben an, in welcher Reihenfolge sie vom Layouting-Mechanismus ausgewertet werden. Ein s(tretch) an der Zahl gibt an, dass in diese Richtung die Größe des Widgets verändert wird. Der Abstand der Gruppe ist nach oben hin kleiner, als nach unten, weil der Titel und Rahmen der Parent-Gruppe von dem Abstand abgezogen werden.

Hinweis: Wird das Fenster zum ersten Mal geöffnet und nicht von Hand resized, dann hat die linke Gruppe aufgrund der Auswertungsreihenfolge der Attaches einen deutlich größeren Abstand zum linken Rand. Für den korrekten Aufbau dieses Layouts sind 2 Druchläufe des Attach-Mechanismus notwendig (also ein nachträgliches Resize des Fensters).

Die Reihenfolge in der die Attachments ausgewertet werden, ist wie folgt festgelegt:

  1. Alle Attachments, in denen die Widgets an ihr Parent-Widget attached sind (in der Reihenfolge wie sie im Source-Code vorkommen).
  2. Alle Attachments, in denen die Widgets an andere Widgets auf der gleichen Ebene attached sind (in der Reihenfolge wie sie im Source-Code vorkommen).

In den meisten Fällen muss man sich über die Verarbeitung der Attachments keine Gedanken machen, da die Regeln dafür sorgen, dass unabhängig von der Reihenfolge der Attachments im Source-Code das Layout in den meisten Fällen funktioniert. Wichtig sind die Regeln, wenn Widgets interaktiv zur Laufzeit verschoben oder vergrößert werden. 

 

Wird beispielsweise die Gruppe g12 (right) per Move nach links verschoben, dann wird das Ergebnis nicht den Erwartungen entsprechen, denn die linke Gruppe (g11) wird einfach nach links rausgeschoben, wie man im nächsten Bild erkennen kann:

Attachments2

Dieses Problem wird durch die Reihenfolge in der Attachment-Auswertung verursacht. Nachdem die Gruppe g12 nach links verschoben wurde, werden die Attachments wie folgt ausgeweret

  1. Attach(g11, LEFT, TOP, BOTTOM, STRETCH, 10): Da die Gruppe selbst nicht verschoben wurde in immer noch den gleichen Abstand nach link, oben und unten zur Parent-Gruppe hat, passiert hier nichts.
  2. Attach(g12, TOP,  RIGHT, BOTTOM, STRETCH, 10): Da die Gruppe g12 nach links verschoben wurde, stimmt der Abstand des rechten Rands zur Parent-Gruppe nicht mehr. Durch das STRETCH-Flag wird die Gruppe wie gewünscht nach rechts vergrößert.
  3. Attach(g11, g12, RIGHT, OPPOSITE, 10): Das Attachment-Ziel (linker Rand von Gruppe g12) hat sich verändert, also wird jetzt der rechte Rand der Gruppe g11 neu ausgerichtet. Da hier kein STRETCH angegeben ist, wird aber die gesamte Gruppe als Ergebnis nach links verschoben, was dazu führt, dass die Gruppe links aus dem Fenster herausgeschoben wird.

Das Problem lässt sich lösen, indem die Attachments wie folgt umgeschrieben werden:

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