Keine Frames unter Firemonkey

[Uwe Raabe]

Zitat von bernau:

Weis nicht, ob ihr wirklich das Potential von Frames ausgenutzt habt.

Den Eindruck hatte ich bei einigen Antworten allerdings auch.

[neo4a]

Zitat von Uwe Raabe:

ach nee, das gibt es in FMX ja gar nicht.

Der FMX- Vorläufer vgScene kennt z.B. noch ein TvgFrame als weitere TLayout-Komponente, konnte mit mit einem Property eine vgScene-Maske in den interaktiven Edit- Mode versetzen, Videos abspielen (wie in animierten DVD-Menüs) etc. Was ich damit sagen will: FMX zeigt derzeit längst noch nicht alles und man kann damit wohl nicht viel mehr machen, als das, was die Demos zeigen.

Mit den Styles allerdings bekommen wir Entwickler ein Konzept in die Hand, mit dem wir mehr als nur Farbe und Font eines Controls beeinflussen können: Im Prinzip ist es sogar egal, wie das Ausgangs-Control aussieht. Man kann über ein TLabel per Styles 10 Edit-Boxen bereit stellen und ein Memo-Feld lediglich zum Darstellen einer Grafik umstylen. Abseits dieser sinnfreien Verwendung habe ich z.B. in einer Zelle des StringGrids 2 Edit-Controls untergebracht. Hier musste ich allerdings vgScene beim Keyboard-Handling und beim Hittest in die Sourcen greifen, aber es funktioniert. Da Styles ja DFM-like nur Text-Definitionen sind, lässt sich das leicht übertragen. Nur mit DesignTime-Support ist da nichts, das passiert (bei mir) alles im Code (insbesondere das Lesen/Setzen der Syle-Controls via BindingName).

Allerdings kann man ja Style-Dateien auch in der IDE nachladen, so dass einem die selbst-designten Control-Styles im Projekt und Formdesigner visuell zur Verfügung stehen.

[pixfreak]

Moin,

ich habe auch immer überlegt, lieber Frames oder eine Form.
Ich bin dazu übergegangen, lieber die Form mit ManualDock an eine PageControl zu heften. Das ist im Prinzip das gleiche Ergebnis wie bernau es oben beschrieben hat. Vor allem die Trennung in mehrere Units habe ich damit ebenfalls. Und mir bleibt noch die Möglichkeit, aus dem gedockten Form ganz schnell eine eigenständige zu machen...

Ok, geht ja auch mit Frames, aber dann brauche ich doch wieder eine "Träger"-Form.


VG Pixfreak

[Union]

Ich glaube dass wirlich 90% hier Frames mit Panels verwechseln. Richtig eingesetzt spart es einem irrsinnig Arbeit und hat nur sekundär etwas mit Layout zu tun.

[neo4a]

Zitat von Union:

Ich glaube dass wirlich 90% hier Frames mit Panels verwechseln.

Wenn man es schafft, das GUI von der Anwendungslogik zu trennen, ist das kein Fehler. BTW, wieviel genau meinst Du mit 90% von bisher 7 Postern in diesem Thread?

[Uwe Raabe]

Zitat von neo4a:

Zitat von Union:

Ich glaube dass wirlich 90% hier Frames mit Panels verwechseln.

Wenn man es schafft, das GUI von der Anwendungslogik zu trennen, ist das kein Fehler. BTW, wieviel genau meinst Du mit 90% von bisher 7 Postern in diesem Thread?

Na, eben alle bis auf einen und der halt zu 30%

[neo4a]

Zitat von Uwe Raabe:

Zitat von neo4a:

Zitat von Union:

Ich glaube dass wirlich 90% hier Frames mit Panels verwechseln.

Wenn man es schafft, das GUI von der Anwendungslogik zu trennen, ist das kein Fehler. BTW, wieviel genau meinst Du mit 90% von bisher 7 Postern in diesem Thread?

Na, eben alle bis auf einen und der halt zu 30%

Das willst Du aber noch einmal nach rechnen, oder?!

[bernau]

Zitat von neo4a:

Der FMX- Vorläufer vgScene kennt z.B. noch ein TvgFrame als weitere TLayout-Komponente, konnte mit mit einem Property eine vgScene-Maske in den interaktiven Edit- Mode versetzen, Videos abspielen (wie in animierten DVD-Menüs) etc. Was ich damit sagen will: FMX zeigt derzeit längst noch nicht alles und man kann damit wohl nicht viel mehr machen, als das, was die Demos zeigen.

Ich beschäftige mich grade mit FMX und finde es wirklich klasse. FMX kann viele Dinge, die ich bei der VCL vermisst habe. Damit kann ich aber fehlende Frames nicht schönreden.

Zitat von neo4a:

Der FMX- Vorläufer vgScene kennt z.B. noch ein TvgFrame als weitere TLayout-Komponente, konnte mit mit einem Property eine vgScene-Maske in den interaktiven Edit- Mode versetzen, Videos abspielen (wie in animierten DVD-Menüs) etc. Was ich damit sagen will: FMX zeigt derzeit längst noch nicht alles und man kann damit wohl nicht viel mehr machen, als das, was die Demos zeigen.

Mit den Styles allerdings bekommen wir Entwickler ein Konzept in die Hand, mit dem wir mehr als nur Farbe und Font eines Controls beeinflussen können: Im Prinzip ist es sogar egal, wie das Ausgangs-Control aussieht. Man kann über ein TLabel per Styles 10 Edit-Boxen bereit stellen und ein Memo-Feld lediglich zum Darstellen einer Grafik umstylen. Abseits dieser sinnfreien Verwendung habe ich z.B. in einer Zelle des StringGrids 2 Edit-Controls untergebracht. Hier musste ich allerdings vgScene beim Keyboard-Handling und beim Hittest in die Sourcen greifen, aber es funktioniert. Da Styles ja DFM-like nur Text-Definitionen sind, lässt sich das leicht übertragen. Nur mit DesignTime-Support ist da nichts, das passiert (bei mir) alles im Code (insbesondere das Lesen/Setzen der Syle-Controls via BindingName).

Allerdings kann man ja Style-Dateien auch in der IDE nachladen, so dass einem die selbst-designten Control-Styles im Projekt und Formdesigner visuell zur Verfügung stehen.

Auch das ist schön, daß FMX das kann. Aber auch hier gilt, es ersetzt keine Frames. Die Argumentation kommt mir vor, als wäre ich bei einem Autohändler und möchte einen 200PS-Motor und der Händler sagt, "Haben wir nicht, aber das Radio kann dafür viel mehr als beim Vorgänger."

[bernerbaer]

Ich hoffe, dass ich nicht zu den 90% gezählt werde, die Frames mit Panels verwechseln.

Trotzdem stellt sich mir hier die Frage, welche Vorteile bieten Frames gegenüber Forms?

So wie ich das beurteile:

Vorteile Frames:
- Einbettung zur Designzeit
- Einfachere Kommunikation zwischen Form und Frame

Nachteile Frames:
- funktioniert nicht in Firemonkey
- Keine Events wie OnCreate, OnDestroy, OnShow, OnHide, OnActivate, OnDeactivate oder OnKey...

Vorteile Form:
- Alle Events der Form vorhanden
- Jederzeit einsetzbar

Nachteile Form:
- Kommunikation zwischen ParentForm und eingebetteter Form muss evtl über Interfaces gelöst werden
- Einbettung erfolgt per Code

Fazit für mich: ich verwende Forms in Forms

[Phoenix]

Zitat von bernerbaer:

NachVorteile Form:
- Kommunikation zwischen ParentForm und eingebetteter Form muss evtl kann vernünftig über Interfaces gelöst werden

So siehts besser aus.