Keine Frames unter Firemonkey

[neo4a]

Zitat von bernau:

Damit kann ich aber fehlende Frames nicht schönreden.

Du hast aber schon verstanden, das FMX noch nicht im vollen Umfang verfügbar ist?! BTW, das Schönreden überlasse ich der Kanzlerin.

Zitat von bernau:

Aber auch hier gilt, es ersetzt keine Frames.

Meine Antwort bezog sich auf einen Aspekt der Styles-Frage von Uwe und hatte in der Tat nichts mit Deinen vermissten Frames zu tun. Und wenn Du z.B. MaskEdit brauchst: nicht bei FMX suchen, sondern bei VCL bleiben. David I. bestätigte zuletzt den Delphi-Support solange es Windows gibt.

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

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

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

Die zugehörigen Methoden (constructor create...) kannst du aber sehr wohl überschreiben. Musst halt statt einem Doppelklick auf dem Objektinspektor die eine zeile Code hinzufügen.



Fazit für mich: Die Vorteile von Frames überwiegen.

[bernau]

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

OK. Vieleicht bin ich nicht erfahren genug. Aber du kannst es mir ja erklären.

Folgende Vorgabe:
Ich habe eine Combobox. Je nachdem welcher Wert in dieser CB ausgewählt wird, wird eine zweite CB mit Daten gefüllt. Aus dieser wird wieder ein Eintrag ausgewählt. Je nach Wert wird eine dritte CB gefüllt und ggf. 3 weitere Edits eingeblendet. Diese Edits dürfen nur mit Zahlen gefüllt werden, di, je nachdem welcher Eintrag in der CB ausgewählt wurde, einen bestimmten Werteberreich nicht überschreiten darf.

Das ist jetzt eine recht simple Vorgabe. Aber wo, wenn nicht innerhalb der Form soll diese Logik untergebracht werden. Ich lerne immer wieder gerne dazu. Erkläre es mir.

[Uwe Raabe]

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

Gerne!

90% von 7 = 6,3
Alle bis auf einen = 6
30% von einem = 0,3
6 + 0,3 = 6,3

An dem Wahrheitsgehalt dieser Größe wage ich allerdings zu zweifeln.

[Stevie]

Zitat von bernau:

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

OK. Vieleicht bin ich nicht erfahren genug. Aber du kannst es mir ja erklären.

Folgende Vorgabe:
Ich habe eine Combobox. Je nachdem welcher Wert in dieser CB ausgewählt wird, wird eine zweite CB mit Daten gefüllt. Aus dieser wird wieder ein Eintrag ausgewählt. Je nach Wert wird eine dritte CB gefüllt und ggf. 3 weitere Edits eingeblendet. Diese Edits dürfen nur mit Zahlen gefüllt werden, di, je nachdem welcher Eintrag in der CB ausgewählt wurde, einen bestimmten Werteberreich nicht überschreiten darf.

Das ist jetzt eine recht simple Vorgabe. Aber wo, wenn nicht innerhalb der Form soll diese Logik untergebracht werden. Ich lerne immer wieder gerne dazu. Erkläre es mir.

Zum Beispiel mit dem MVVM pattern - ja, das erfordert einiges an Umdenken für den "klassischen Delphi Entwickler" und ist auch in alten Delphi Versionen nicht mal so ebend machbar. Aber auch in der Vergangenheit gab es schon Pattern, wie MVC oder MVP, mit denen man die GUI und die Businesslogik trennen konnte.

[Uwe Raabe]

Zitat von bernau:

Folgende Vorgabe:
Ich habe eine Combobox. Je nachdem welcher Wert in dieser CB ausgewählt wird, wird eine zweite CB mit Daten gefüllt. Aus dieser wird wieder ein Eintrag ausgewählt. Je nach Wert wird eine dritte CB gefüllt und ggf. 3 weitere Edits eingeblendet. Diese Edits dürfen nur mit Zahlen gefüllt werden, di, je nachdem welcher Eintrag in der CB ausgewählt wurde, einen bestimmten Werteberreich nicht überschreiten darf.

Das ist jetzt eine recht simple Vorgabe. Aber wo, wenn nicht innerhalb der Form soll diese Logik untergebracht werden. Ich lerne immer wieder gerne dazu. Erkläre es mir.

Du hast das schon richtig gelöst. Man muss hier zwischen Anwendungslogik, die tunlichst von der Eingabe getrennt werden sollte, und Eingabelogik unterscheiden. Die Datenklasse ist für die Anwendungslogik zuständig und wird (zumindest bei mir) nicht mit Plausibilitätsprüfungen der Eingaben oder Eingabehilfen (z.B. Füllen von Comboboxen) belastet. Manchmal habe ich für die Eingabelogik eine separate Klasse, aber oft lohnt der Aufwand nicht und dann löse ich das eher pragmatisch als dogmatisch. In die Eingabelogik gehört zum Beispiel auch das dynamische Füllen der Hints oder das Sperren bzw. Freigeben einzelner Controls abhängig vom Kontext und vorherigen Eingaben. Diese Sachen macht man meistens besser im Form.

Das Schlimmste, was ich mal gesehen habe, waren Form- bzw. Control-Events, die in den Datenklassen implementiert und zur Laufzeit verdrahtet wurden. Wenn dort dann so Sachen wie CheckBoxClick oder EditChange auftauchen, läuft etwas so richtig verkehrt.

[Alaitoc]

Es kommt halt immer drauf an ob sich der Aufwand lohnt.

Bei einem Suchdialog von mir hab ich z.B. auch das MVC benutzt. Dort konnte man immer bestimmte Suchfilter einstellen, wobei die Views sich noch um Validierung gekümmert haben und die Daten danach per Controller an die Models übergeben wurden. Wobei ich dort manche Ereignisse noch über das Befehls-Pattern geregelt habe, weil ich dort z.B. über den Delete-Button vom View den View und das Model freigeben wollte. Damit es da aber keine Zugriffsverletzung gab, musste ich dafür sorgen das der Befehl erst ausgeführt wird, wenn der Zugriff auf dem View beendet wurde.

Die Anwendungslogik selbst, also z.B. das Generieren des SQL-Befehls aus den Filtern, wurde dann nur mit den Models durchgeführt und fand völlig unabhägig von den Views statt.

Also auch soweit wie möglich und soweit wie nötig alles voneinander getrennt

MfG Alaitoc