Arbeiten mit mehreren Forms, Vermeiden zirkulärer Referenz (XE7)

[wonkos2]

Zitat von himitsu:

Und der Nächste, mit dem selben Problem, weiß jetzt natürlich ganz genau, wie du es gelöst hast, wenn er in 1-2 Jahren diesen Beitrag in der SuFu entdeckt.

OK, dann will ich mal beschreiben, was ich gemacht habe: Der Hinweis, meine FormA (also die primäre) unterhalb der unteren Uses-Klausel, nämlich innerhalb der implementation unterzubringen, hat meine zirkuläre Referenz aufgelöst. Jetzt muß ich nur noch das Variablenproblem lösen, dann bin ich einen Schritt weiter. OK?

[Luckie]

Und was spricht gegen die Lösung von DeddyH und mir? Anstatt so ein Gewurstelt mit den uses Klauseln?

[DeddyH]

Ja eben. Auch wenn der Compiler jetzt zufrieden ist, bleibt ja die Tatsache, dass sich beide Formulare gegenseitig kennen müssen.

[himitsu]

Zitat von DeddyH:

bleibt ja die Tatsache, dass sich beide Formulare gegenseitig kennen müssen.

Besser nicht!

Einer bietet Schnittstellen (Funktionen/Events/Property) an und der Andere benutzt sie, ohne daß Ersterer weiß wer/was er ist, bzw. ob es ihn überhaupt gibt.


Nur so ist es wiederverwendbar, austauschbar, wartbar, ...

[DeddyH]

Genau darum geht es Luckie und mir doch, wurde aber nicht umgesetzt.

[himitsu]

Zitat von DeddyH:

Genau darum geht es Luckie und mir doch, wurde aber nicht umgesetzt.

Ups, falsch gelesen verstanden.

Zusammen mit der übersehenen Antwort von wonkos2, ergibt es mehr Sinn.

Zitat:

hat meine zirkuläre Referenz aufgelöst.

Nicht aufgelöst, sondern nur abgeschwächt.

Und das Abschwächen kann böse Nachwirkungen haben. (Initialisierungsreihenfolge)
Besser möglichst alle Units nur im Interface einbinden.

[Sir Rufo]

Auf die ganz billige Art und Weise löst man das mit einem DataModule.

Dort sind die Daten und die Forms zeigen die Daten an. Schon kennen die Forms nur noch das DataModule und nicht mehr sich selber untereinander.

[stahli]

@wonkos2

Damit Du vielleicht besser verstehst, was die Profis meinen: Man solle z.B. den Kunden-Vornamen nicht in EditVorname.Text speichern.
Wenn Du eine Rechnung druckst, muss sonst der Reportgenerator Deine Formularinstanz kennen.

Die Daten und die Geschäftslogik sind daher besser in eigenen Klassen aufgehoben oder hilfsweise in einem Datenmodul.

Die Formulare sind eigentlich nur eine Schnittstelle für den Anwender.

Du kannst natürlich Dein Projekt mit den Daten und Geschäftslogik in Formularen umsetzen, aber wenn Du später Dein Projekt mal ausbauen willst wirst Du dann erhebliche Probleme bekommen.