Keine Frames unter Firemonkey

[neo4a]

Zitat von bernau:

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

Ich wei0 nicht.

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.

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 von Uwe Raabe:

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 von neo4a:

Zitat von Uwe Raabe:

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

[Stevie]

Zitat von neo4a:

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

Ick bin jespannt!

[implementation]

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

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

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

[neo4a]

Zitat von Uwe Raabe:

Zitat von neo4a:

Zitat von Uwe Raabe:

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

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

[neo4a]

Zitat von Stevie:

Zitat von neo4a:

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

Ick bin jespannt!

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

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 von Uwe Raabe:

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 von neo4a:

Zitat von Stevie:

Zitat von neo4a:

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

Ick bin jespannt!

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 ) oftmals vorwerfen lassen muss)