Keine Frames unter Firemonkey

[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.

[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.

[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:

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?

Wenn man eine Form hat, auf dem viele Controlls sind, diese auch gegenseitige Abhängigkeiten haben, dann muss die Logik leider auf das Form. Ist ja nicht so, daß wir alle nur Adressverwaltungen programmieren, bei dem einige DBEdit auf dem Form sitzen und einfach mit der Datenbank verknüpft werden.

[neo4a]

Zitat von bernau:

Wenn man eine Form hat, auf dem viele Controlls sind, diese auch gegenseitige Abhängigkeiten haben, dann muss die Logik leider auf das Form.

Nein. Besonders dann nicht, wenn Du Unit-Tests durchführen willst.

[bernau]

Zitat von 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

Ist aber immer noch aufwändiger als bei der Verwendung von Frames. Wenn du aus dem gedockten Form eine eingenständige Form machst, ohne eine Trägerform, dann musst du auf der Form ggf. Komponenten (OK-Button, Abbruch-Button) setzten, die du in gedockter Ansicht wieder ausblenden musst.

Einfaches Beispiel: Meine Software kann man in einem großen Konfigurationsdialog alle Parameter des Programms einstellen. Dazu gibt es eine Form mit einem Pagecontrol. Auf jeder Page sitzt ein Frame. Auf jedem Frame werden die Eigenschaften eines Programmteils eingestellt. Ich habe aber auch die Möglichkeit aus jedem Programmteil den zuständigen Konfigurationsdialog mit einem Fenster und dem einen eingebettetetn, bereits in der Hauptkonfiguration verwendeten Frame aufzurufen. Damit kann der anwender genau den Programmbereich einstellen, in dem er sich befindet, ohne von den Einstelungsmöglichkeiten anderer Programmteile verwirrt zu werden. Ob nun großer Konfigurationsdialog oder kleiner Konfigurationsdialog, die OK/Abbruchbuttons sind auf der Trägerform. Würde ich keine Trägerform verwenden, dann müssten diese Buttons auf dem Frame (bzw. bei dir auf der Form) in der großen Konfiguration ausgeblendet werden.