Keine Frames unter Firemonkey

[bernau]

Im Firemonkey-Sammelthread wurde es kurz angesprochen (Ja, ich habe die Suche verwendet), aber ich finde dieses Thema so Elementar, daß ich daraus einen eigenen Thread mache.

In Firemonkey gibt es keine Frames!

Für mich, der Firemonkey klasse findet, ein herber Rückschlag. Ich verwende extensiv Frames. Nun wollte ich testweise ein VCL-Programm auf FMX umstellen, und nun das.

Wird es für FMX irgendwann Frames geben? Wenn nein, dann wird von mir FMX bis auf weiteres ausgesetzt.

[Phoenix]

Wieso sollte das Fehlen von Frames ein Problem sein?
Firemonkey basiert auf Composition, das heisst Du kannst im Prinzip alles was Du als Frame machen würdest als eigenes Control zusammenstellen.

[Uwe Raabe]

Zitat:

Zitat von Phoenix (Beitrag 1126760)

Wieso sollte das Fehlen von Frames ein Problem sein?
Firemonkey basiert auf Composition, das heisst Du kannst im Prinzip alles was Du als Frame machen würdest als eigenes Control zusammenstellen.

Kannst du das mal etwas genauer erläutern? Wenn ich das richtig verstehe, kann ich mit dem FMX-Designer doch immer nur ein vollständiges Form erstellen. Oder gibt es da eine Möglichkeit, irgendwie ein Teilform zu erstellen und dieses dann sowohl mehrfach ein einem anderen Form, als auch gleichzeitig in unterschiedlichen Forms zu instanzieren. Dieses ist immerhin ein wesentlicher Vorteil von Frames: einmal Design und Code, mehrfach verwenden. Änderungen an einer Stelle, Auswirkungen in allen Instanzen.

[implementation]

In vielen anderen Frameworks gibt es auch keine Frames, und man kommt dort auch zurecht.
Wieso? Weil man es auch gleich als Control realisieren kann.

Du baust dir nen Custom Control und erstellst darauf, was du benötigst, wie bei 'nem Frame auch.
Da ich XE2 nicht habe, kann ich allerdings wenig dazu sagen, inwiefern dir der Formdesigner bei der Gestaltung der Controls hilft.
Aber hinterher das Draufpacken aufs Form dürfte unproblematisch sein.

[neo4a]

Zitat:

Zitat von implementation (Beitrag 1126771)

In vielen anderen Frameworks gibt es auch keine Frames, und man kommt dort auch zurecht.
Wieso? Weil man es auch gleich als Control realisieren kann.

Genau. Beim FMX realisiert man das mittels Styles. Dazu definiert man ausgehend von einem TLayout alle benötigten Elemente und weist den Resourcen-Namen dem FMX-Control im Onjektinspektor zu. Das Witzige dabei ist, dass mit dieser Methode ein TLabel und ein TEdit danach identisch aussehen (können).

Problematisch wird es dann in der Praxis: Kann ich im Code die Elemente eines Styles noch per BindingName ansprechen, wird es spätestens beim Keyboard-Handling etwas ... unhandlich.

[Uwe Raabe]

Zitat:

Zitat von implementation (Beitrag 1126771)

In vielen anderen Frameworks gibt es auch keine Frames, und man kommt dort auch zurecht.

Ach, was?

Zitat:

Zitat von implementation (Beitrag 1126771)

Wieso? Weil man es auch gleich als Control realisieren kann.

Du baust dir nen Custom Control und erstellst darauf, was du benötigst, wie bei 'nem Frame auch.
Da ich XE2 nicht habe, kann ich allerdings wenig dazu sagen, inwiefern dir der Formdesigner bei der Gestaltung der Controls hilft.
Aber hinterher das Draufpacken aufs Form dürfte unproblematisch sein.

Verstehe ich das richtig? Ich erzeuge ein CustomControl - ach nee, das gibt es in FMX ja gar nicht. Aber egal, ich erzeuge ein was-auch-immer, packe da meine Controls drauf, verdrahte die Events und speichere das als eigene Unit ab. Damit ich das ganze auch im Formulardesigner verarbeiten kann, muss ich dieses neue zusammengesetzte Control aber erst in ein Design-Time Package packen und in der IDE installieren. Das muss ich jetzt für alle meine 312 Frames meines einen Projekts machen und sie auch gleich wieder deinstallieren, wenn ich das Projekt wechsele.

Kommt noch erschwerend hinzu, daß es einfach keine Designer-Unterstützung für solche zusammengebastelten Controls gibt. Alles in allem ist das bei Weitem kein Ersatz für Frames. Wie es aussieht, kann man sich in XE2 mit FireMonkey von einem modularen Aufbau eines Forms in seiner bisherigen Inkarnation durch Frames wohl verabschieden. Bleibt nur (ohne es getestet zu haben), die "Frames" in eigenen FMX-Forms in einem Layout zu designen und dann das Layout zur Laufzeit in das Zielform zu transferieren. Eine eher halbherzige Lösung. Warten wir mal auf XE3.

Übrigens: das mit den Styles habe ich nicht so richtig verstanden. Vielleicht könnte ja mal jemand ein konkretes Beispiel zeigen: Wie portiert man ein VCL-Frame, das eine Addresse mittels mehrerer Labels und Edits inklusive Eingabehilfen und Plausibilitätsprüfung bereitstellt nach FMX, so daß ich

a) in einem Form mehrere Adressen bearbeiten kann (= mehrere "FMX-Frame"-Instanzen)
b) in mehreren Forms dieses "FMX-Frame" verwenden kann

Würde mich wirklich interessieren, wie man sowas macht.

[bernerbaer]

Ich besitze zwar Firemonkey nicht (XE2 getestet und für mich als noch nicht produktiv einsatzfähig befunden), aber sollte es nicht wie bei Delphi möglich sein, Forms in Forms einzubetten?

Ich weiss nicht mehr ob es Delphi5 war, als Frames eingeführt worden sind, jedenfalls waren Frames damals noch unbrauchbar, so dass ich vollständig auf den Einsatz von Frames verzichtet habe und stattdessen jeweils Forms in Panels, Pagecontrols, ... einbinde. Vermutlich funktionieren heute Frames in Delphi problemlos, doch mit meinem Ansatz von Form in Forms bin ich bis heute so gut gefahren, dass ich keinen Grund sehe Frames einzusetzen.

[Stevie]

Zitat:

Zitat von bernerbaer (Beitrag 1126792)

aber sollte es nicht wie bei Delphi möglich sein, Forms in Forms einzubetten?

So isses.

[bernau]

Zitat:

Zitat von Phoenix (Beitrag 1126760)

Wieso sollte das Fehlen von Frames ein Problem sein?
Firemonkey basiert auf Composition, das heisst Du kannst im Prinzip alles was Du als Frame machen würdest als eigenes Control zusammenstellen.

Schön gesagt. Und wie soll das funktionieren?

[bernau]

OK. Bevor ich jedem einzeln antworte, mach ich das mal in einem Beitrag.

Weis nicht, ob ihr wirklich das Potential von Frames ausgenutzt habt. Wahrscheinlich kommen daher so aussagen wie "Braucht man nicht, in anderen Frameworks gibt's das ja auch nicht".

Es geht nicht darum, ein Label und ein Edit auf ein Frame zu setzen und damit ein neues Control zu erzeugen. Es geht darum, komplexe Forms mit mehreren (Page-Control"-Seiten in logische Einheiten aufzuteilen und diese Einheiten dann zur Desingzeit in ein Form zusammen zu führen. Ich habe lieber 5 mittlere Units als eine Monsterunit. (Bitte jetzt nicht mit dem Argument kommen, ich solle mein Design mal überdenken).

Weis nicht, ob das Form in Form zur Designzeit geht. Mit Frames geht das wunderbar.