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.

[Uwe Raabe]

Zitat:

Zitat von bernau (Beitrag 1126830)

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

Den Eindruck hatte ich bei einigen Antworten allerdings auch.

[neo4a]

Zitat:

Zitat von Uwe Raabe (Beitrag 1126781)

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:

Zitat von Union (Beitrag 1126865)

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:

Zitat von neo4a (Beitrag 1126867)

Zitat:

Zitat von Union (Beitrag 1126865)

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:

Zitat von Uwe Raabe (Beitrag 1126870)

Zitat:

Zitat von neo4a (Beitrag 1126867)

Zitat:

Zitat von Union (Beitrag 1126865)

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:

Zitat von neo4a (Beitrag 1126857)

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:

Zitat von neo4a (Beitrag 1126857)

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:

Zitat von bernerbaer (Beitrag 1126877)

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

So siehts besser aus.

[neo4a]

Zitat:

Zitat von bernau (Beitrag 1126876)

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:

Zitat von bernau (Beitrag 1126876)

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:

Zitat von pixfreak (Beitrag 1126858)

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:

Zitat von neo4a (Beitrag 1126867)

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:

Zitat von bernau (Beitrag 1126887)

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:

Zitat von bernerbaer (Beitrag 1126877)

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:

Zitat von neo4a (Beitrag 1126891)

Zitat:

Zitat von bernau (Beitrag 1126887)

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:

Zitat von neo4a (Beitrag 1126871)

Zitat:

Zitat von Uwe Raabe (Beitrag 1126870)

Zitat:

Zitat von neo4a (Beitrag 1126867)

Zitat:

Zitat von Union (Beitrag 1126865)

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:

Zitat von bernau (Beitrag 1126898)

Zitat:

Zitat von neo4a (Beitrag 1126891)

Zitat:

Zitat von bernau (Beitrag 1126887)

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:

Zitat von bernau (Beitrag 1126898)

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

[neo4a]

Zitat:

Zitat von bernau (Beitrag 1126898)

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

Ich wei0 nicht.

Zitat:

Zitat von bernau (Beitrag 1126898)

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.

Für Dich allein ist etwas viel Mühe, aber ich nehme den Auftrag an. Ich werde das mit DSharp umsetzen, damit wir alle etwas Neues lernen können.

[neo4a]

Zitat:

Zitat von Uwe Raabe (Beitrag 1126915)

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

Merkel: "Aber das ist doch wohl nicht Ihr Ernst, Herr Jauch".

[Uwe Raabe]

Zitat:

Zitat von neo4a (Beitrag 1126947)

Zitat:

Zitat von Uwe Raabe (Beitrag 1126915)

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

Merkel: "Aber das ist doch wohl nicht Ihr Ernst, Herr Jauch".

:gruebel:

[Stevie]

Zitat:

Zitat von neo4a (Beitrag 1126946)

Ich werde das mit DSharp umsetzen, damit wir alle etwas Neues lernen können.

Ick bin jespannt! 8-)

[implementation]

Also ich denke, statt jetzt in FMX Frames einzuführen, sollte Emba lieber Custom Controls vereinfachen :gruebel:

So einige Posts in diesem Thread sagen mir, dass es dafür immer noch keinen vernünftigen Support vom Formdesigner gibt.
Aus dem Visual Studio kenne ich es, dass dort
a) Man beim Erstellen des Controls selbst bereits den Designer nutzen kann (wie in D bei Frames)
b) Erstellte Controls gleich in der Liste verfügbar sind (wie in D bei Frames)
und deshalb braucht man dort keine Frames. Eben weil sich alles mit Custom Controls realisieren lässt.

Ich habe Delphi nach der Turbo verlassen und weiß nicht, wie es mit dem Designer dort aussieht, aber ich bin einfach davon ausgegangen, dass der auch verbessert wurde :shock:

Und nein, ich verwechsle Frames nicht mit Panels.
Eine Designerverbesserung würde Frames gänzlich überflüssig machen.

[neo4a]

Zitat:

Zitat von Uwe Raabe (Beitrag 1126954)

Zitat:

Zitat von neo4a (Beitrag 1126947)

Zitat:

Zitat von Uwe Raabe (Beitrag 1126915)

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

Merkel: "Aber das ist doch wohl nicht Ihr Ernst, Herr Jauch".

:gruebel:

Das war die Antwort der Kanzlerin auf ein Milchmädchenrechnung in Jauch's Talkshow.

[neo4a]

Zitat:

Zitat von Stevie (Beitrag 1126994)

Zitat:

Zitat von neo4a (Beitrag 1126946)

Ich werde das mit DSharp umsetzen, damit wir alle etwas Neues lernen können.

Ick bin jespannt! 8-)

Du glaubst wohl selbst nicht daran, oder?!

Im Anhang befinden sich die Quellen, sowie eine Exe. DSharp muss man nicht in der IDE installieren, wenn die Units im Suchpfad liegen.

[neo4a]

Zitat:

Zitat von bernau (Beitrag 1126898)

Zitat:

Zitat von neo4a (Beitrag 1126891)

Zitat:

Zitat von bernau (Beitrag 1126887)

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.

Aber du kannst es mir ja erklären.

Ich habe statt einer Erklärung eine Demo bereit gestellt, die zeigt, wie man recht elegant und konsequent View(Form) und Model(Datenklasse) trennt. Damit das Ganze nicht nur in Schönheit stirbt, muss nun noch der nächste Schritt folgen. Leider ist in meiner Demo noch eine harte Unit- Referenz vorhanden. Es ist zu prüfen, inwieweit sich der DSharp-Ansatz mit dem DI-Ansatz von Emballo verträgt und damit eine Modularisierung mit Hilfe von Interfaces und Dependency Injection möglich ist. DSharp hat auch etwas für das Mocking getan, so dass meine Demo auch für das UnitTesting fit gemacht werden könnte. Und zum Schluss machen wir noch eine weitere GUI mit FMX-Controls auf und zeigen damit einen weiteren Anwendungsfall.

Versteh mich nicht falsch. Mit reinen Delphi-Bordmitteln würde ich auch niemals so etwas umsetzen können. Aber die vorhandenen Frameworks bringen die anerkannten Design-Patterns halt auch in unsere Programmierwelt. Und - um mit strahlenden Siegern zu sprechen - das ist gut so.

[neo4a]

Zitat:

Zitat von Uwe Raabe (Beitrag 1126925)

Man muss hier zwischen Anwendungslogik, die tunlichst von der Eingabe getrennt werden sollte, und Eingabelogik unterscheiden.

Sorry, aber nein. Warum sollte man das nur tun?

Theorie:
Eingabelogik resp. Validierung ist doch immer ein Teil der Anwendungslogik.

Praxis:
genau eine GUI, eine Plattform, keine Unit-Tests, keine abstrakte Modularisierung und Programmierung nach RAD-Ansatz

Motivation zur Änderung der Praxis:
- testbarer Code, dann kommt der Rest von ganz allein (frei nach N.Hodge)

[Stevie]

Zitat:

Zitat von neo4a (Beitrag 1127011)

Zitat:

Zitat von Stevie (Beitrag 1126994)

Zitat:

Zitat von neo4a (Beitrag 1126946)

Ich werde das mit DSharp umsetzen, damit wir alle etwas Neues lernen können.

Ick bin jespannt! 8-)

Du glaubst wohl selbst nicht daran, oder?!

Haha, doch. Ich find es nur spannend zu sehen, wie sich aus einer "fixen Idee" so langsam etwas entwickelt, womit auch andere arbeiten und was nicht nur in der Theorie toll klingt (einen Vorwurf, den man sich als "Designpattern- und Prinzipienfundamentalist" von den "Konservativen" (achtung Ironie :D) oftmals vorwerfen lassen muss)