Zirkularen Bezug von zwei Forms wie vermeiden ?

[Luckie]

Also wenn ich auf zirkulare Referenzen stoße bei mir im Code, dann ist das für mich ein Zeichen, dass mein Konzept nicht stimmt.

[Klaus01]

.. ein Ansatz könnte das Observer-Pattern sein.

Grüße
Klaus

[RWarnecke]

Zitat von Luckie:

Also wenn ich auf zirkulare Referenzen stoße bei mir im Code, dann ist das für mich ein Zeichen, dass mein Konzept nicht stimmt.

Ok, da Du meinst dass das Konzept nicht stimmt, ist die Frage, wie Du hier vorgehen würdest ? Ich möchte in der Form1 im oberen Teil des Fensters eine Buttonleiste haben. Diese Buttons sollen einmal aktiviert und deaktiviert werden Aufgrund der Aktionen im restlichen Teil des Fensters. Zudem sollen die Buttons die Eingaben in den einzelnen Formularen auch verarbeiten. Dazu kenne ich drei Möglichkeiten :

• MDI
• Frames
• Forms

Bei allen drei Möglichkeiten habe ich zirkulare Bezüge bei der oben beschriebenen Aufteilung. Ich möchte auch nicht auf jedem Formular, eine eigene Buttonleiste setzen, da ich sonst für über 20 Formulare immer die gleichen Funktionen schreiben. Wo sollen da die Fehler in meinem Konzept sein ?

[Luckie]

Zitat von RWarnecke:

Ich möchte auch nicht auf jedem Formular, eine eigene Buttonleiste setzen, da ich sonst für über 20 Formulare immer die gleichen Funktionen schreiben.

Wie so das? Lagere den redundanten Code in eine separate Unit aus und rufe den Code aus den Formularen aus auf.

[stahli]

@Rolf
Zeigst Du mal einen Screenshot?
Sollen die Buttons im Hauptformular liegen und verschiedene Zustände (auch aus weiteren Formularen) anzeigen (ähnlich den Ribbons)?

Kreuzbezüge innerhalb der implementations-Abschnitte sind sicherlich kein Problem. Dafür sind sie ja u.a. gedacht.

Die Frage ist, ob man überhaupt irgendwann Button-Eigenschaften (oder andere Controleigenschaften wie Visible o.ä.) auswerten sollte.
if ButtonTest.Enabled ... ist zwar machbar, aber eine Trennung von Daten und GUI sollte man bestenfalls dort schon umsetzen.
Für kleine, schnelle Projekte ist das kein Problem, aber für größere Projekte sollte man Daten+Geschäftslogik von der GUI ordentlich trennen (je nach weiteren Ansprüchen und Umgebung). Die GUI präsentiert dann nur Daten und Zustände und schiebt Änderungen, Berechnungen, speichern, Laden usw. an. Die Daten- und Geschäftslogik greift aber nie auf Eigenschaften der GUI zu.

Man könnte also mit einer Variablen bzw. Property "TestEnabled" arbeiten, diese irgendwo speichern und laden und bei jeder Wertänderung, die Darstellung des/der zugehörigen Buttons anpassen. Useraktionen ändern wiederum dann den Propertyinhalt (wie in einer DBCheckBox z.B.).

Um die Verbindung einfach zu gestalten, gibt es unterschiedliche Herangehensweisen. Vorhandene Controls müssen dazu quasi an eine Eigenschaft gebunden werden -> Werbung für die Konkurenz

[Jumpy]

Zitat von stahli:

@Rolf
Die GUI präsentiert dann nur Daten und Zustände und schiebt Änderungen, Berechnungen, speichern, Laden usw. an. Die Daten- und Geschäftslogik greift aber nie auf Eigenschaften der GUI zu.

Das versteh ich jetzt nicht. Wenn die GUI alles in eine Unit auslagert, dann steht doch in den Events nur noch sowas wie:

TGUI.Button1_OnClick(...)
begin
RufeProzedurMachwasAusDerLogikUnitAuf
end;

Dazu muss die Logikunit aber irgendwo im Uses-Block stehen, oder?

Umgekehrt ergibt eine Berechnung in der Logik-Unit, dass jetzt in der GUI 3 Buttons Enabled werden müssen. Um auf diese zuzugreifen, muss doch einem Uses-Block die GUI stehen. Hab ich dann nicht wieder genau die zirkuläre Referenz?

[stahli]

Zitat von Jumpy:

Zitat von stahli:

@Rolf
Die GUI präsentiert dann nur Daten und Zustände und schiebt Änderungen, Berechnungen, speichern, Laden usw. an. Die Daten- und Geschäftslogik greift aber nie auf Eigenschaften der GUI zu.

Das versteh ich jetzt nicht. Wenn die GUI alles in eine Unit auslagert, dann steht doch in den Events nur noch sowas wie:

TGUI.Button1_OnClick(...)
begin
RufeProzedurMachwasAusDerLogikUnitAuf
end;

Dazu muss die Logikunit aber irgendwo im Uses-Block stehen, oder?

Korrekt

Zitat von Jumpy:

Umgekehrt ergibt eine Berechnung in der Logik-Unit, dass jetzt in der GUI 3 Buttons Enabled werden müssen. Um auf diese zuzugreifen, muss doch einem Uses-Block die GUI stehen. Hab ich dann nicht wieder genau die zirkuläre Referenz?

Nein. Es muss eine Möglichkeit geben, dass die GUI informiert wird. Wenn Deine Daten+Logik z.B. in einem Package liegen, muss das in sich vollständig funktionieren. Es müssen alle Daten definiert sein und alle Prozeduren ausführbar sein. Irgendwo sind dann bestimmte Ergebnisse abzufragen.

Wenn dann z.B 3 Button zu schalten sind, kann die DatenUnit 3 Variablen Button1..3 verwalten, die erst mal nil sind.
Die GUI kann dann im OnCreate ihre eigenen Button zuweisen:
DatenUnit.Button1 := Form1.Button1;
DatenUnit.Button2 := Form1.Button2;
DatenUnit.Button3 := Form1.Button3;
Nun kann die DatenUnit die GUI steuern, ohne diese zu kennen. Wenn bzw. so lange keine GUI-Controls zugewiesen wurden, muss die DatenUnit tolerieren, dass die 3 Button noch nil sind.

So ist das wunderbar übersichtlich und man kann später auch recht einfach an den Formularen etwas ändern, ohne die Berechnungen dabei berührt werden. Man hat halt keine Berechnungen in OnClick-Behandlungen z.B.

Noch besser handelbar wird das Ganze, wenn die DatenUnit nicht 3 Button-Variablen, hält, die dann von der GUI zugeweisen werden, sondern wenn man den Controls einfach sagen kann: Zeige Du mal die Einschaft SOWISO an. Dann muss natürlich eine Verfahrensweise vorhanden sein, die sich um eine solche Verbindung und gegenseitige Änderungsinformationen kümmert.
Aber die DatenUnit kennt dann zur Compilezeit NICHT die Formularunits (GUI).

Uff, jetzt bin ich nicht mal sicher, ob ich das verstehen würde...

[Luckie]

Selbst das würde ich nicht so lösen, weil da hat man ja wieder eine Verknüpfung von Daten und Oberfläche. Denn was machst du, wenn ein vierter Button dazu kommt? Dann bist du wieder an der Daten Unit am rumfummeln. Statte die Daten Unit mit Ereignissen aus, die du dann in der Oberfläche zuweisen und darauf reagieren kannst.

[RWarnecke]

Danke erstmal für eure vielen Antworten.

@stahli :

Zitat von stahli:

Zeigst Du mal einen Screenshot?

Siehe Anhang. Es ist jetzt nur das Hauptformular und ein Adressformular. Da sollen aber noch weitere folgen.

Zitat von stahli:

Sollen die Buttons im Hauptformular liegen und verschiedene Zustände (auch aus weiteren Formularen) anzeigen (ähnlich den Ribbons)?

Ja, nicht nur ähnlich den Ribbons, es sollen Ribbons sein.

Edit:
Das Speichern, Laden und Ändern der Daten übernehmen entsprechende Klassen, die über die GUI angesteuert werden. Zusätzlich sind noch Events vorhanden, die dann die Datenbankoperationen ausführen.

[stahli]

Ich sehe da kein Problem, wenn Du Deinen Unterformularen Deine MainForm im Implementationsteil bekannt gibst.
Lediglich über Package-Grenzen hinweg würde ich das vermeiden.