AS vs. MXML Komponente, unterschiedliches Verhalten bei resizing

[Michael Wittwer]

Grundsätzlich geht es darum, dass ich eine Problemstellung mit zwei unterschiedliche Ansätzen gelöst habe. Einmal als MXML Komponente und einmal als AS Komponente.

Das Szenario ist sehr simpel:
Ich habe einen container mit einem TileLayout, in diesem container werden beliebig viele Rechtecks-Komponenten hinzugefügt.

Über einen kleinen "layoutConfigurator" kann man die Eigenschaften des "TileLayouts" anpassen.

Wird nun die Breite angepasst (vergrössert) so sieht alles tiptop aus, wird die Breite verkleinert, so überlappen sich die Rechtecke bei der AS Version (columns = min. 2, rows = beliebig)

In der Sample Applikation welche im Anhang ist, sieht man die zwei container mit unterschiedlichem Verhalten. (Kein FlashBuilder oder FDT Projekt, nur sourcen)

Die zwei Bilder zeigen das layout wie es sein sollte und einmal mit dem Fehlverhalten. (Oben AS, unten MXML)

Die Mxml Variante funktioniert wie erwartet, bei der Actionscript Variante funktioniert es nicht wie erwartet.

Meine Frage an euch:
Was habe ich in der Actionscript Variante falsch gemacht?

[Omega Psi]

Hast du mal in der ActionScript Variante updateDisplayList nicht überschrieben? Kommentiere die mal aus.

[Michael Wittwer]

Danke für die schnelle Antwort.

Wenn ich das mache, ist die Komponente gar nicht mehr sichtbar...

[Omega Psi]

Hm, da scheinen aber auch ein paar Rahmen zu viel gezeichnet zu werden. Ich schaue mir das nachher noch mal an, wenn ich Zeit finde.

[Michael Wittwer]

Genau das ist mir auch aufgefallen, es scheint als würde die "Rect" Instanz zwar verkleinert aber die vorherige Grösse bleibt auch noch, was durch den zusätzlichen Rahmen sichtbar ist.

Danke für deine Mühe.

[Omega Psi]

Benutze mal für das Rect Contraints (bottom, left, right, top), so als Verhalten innerhalb der Group.

[Michael Wittwer]

Die Komponente verhält sich nach wie vor unverändert

[Omega Psi]

K, dann schaue ich nachher mal.

[Michael Wittwer]

perfekt, freue mich auf einen Lösungsansatz...

[Omega Psi]

Es kann sein, dass da noch etwas, mehr passieren muss. Ich hab selbst nur nicht zufriedenstellende Tests fahren können.

Später noch mal mehr.

[Michael Wittwer]

Danke für deine Mühe.
Kann mir das ganze immer noch nicht erklären und bin sehr an der Lösung des Problems interessiert, einfach als "lessons learned"

[Omega Psi]

Die Spark Primitive laufen auch unter dem Namen MXML Graphics. Ich hab mir mal den generierten Source Code angeschaut, konnte aber noch nichts entdecken.