Zirkularen Bezug von zwei Forms wie vermeiden ?

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

[Jumpy]

@stahli: Danke und UffUff. Aber hab's verstanden, da sehr ausführlich. Die Logik kann die GUI zur Laufzeit "steuern", ohne sie zur Design-Time zu kennen, da die GUI ihr dazu die Mittel gibt, sprich von "aussen" Variablen in der Logik-Unit (geht ja, den GUI kennt Logik) füllt und zwar mit Referenzen auf sich selbst (bzw. auf ihre Objekte, z.B. Buttons).

@Luckie: Du gehst einen Schritt weiter (wie ich das verstehe) und gibst der Logik-Unit nicht die Möglichkeit, die GUI zu steuern. Stattdessen feuert die Logik-Unit "einfach" Events ab. Da die GUI die Logik-Unit kennt, kann sie diese Events "abfangen", sprich ihnen Funktionen zuweisen. D.h. die GUI steuert sich wieder selbst, abhängig von Nachrichten/Ereignissen, die sie von der Logik-Unit bekommt.
Das passt sinngemäß (wenn ichs noch richtig zusammenbekomme) zu dem, was in der Schule über die "ideale" OOP gesagt wurde: Der klassische Programmablauf aus der strukturierten Programmierung, wird ersetzt durch Objekte die sich Nachrichten schicken. Naja so in etwa war die Aussage.

Dann noch als letzte Frage von meiner Seite. Wie kommen die Daten ins Spiel, denn eigentlich ist es je ein flotter Dreier aus GUI-Logik-Daten. Wer hat/kennt/steuert die Daten?
(Hoffe meine Fragerei ist noch in Topic und nervt nicht zusehr, aber wie heißt es in der Sesamstrasse: Wer nicht fragt bleibt dumm...)

[stahli]

@Luckie

Das ist richtig. So rum (GUI meldet Controls an) oder so rum (GUI meldet Ereignisse an) ist eigentlich relativ egal.
Wesentlich ist, dass sich die GUI erst zur Laufzeit bei der Datenebene anmeldet und von dort über Änderungen informiert wird.

Ich selbst weise meinen Controls nur die gewünschten Eigenschaftsnamen als Text zu (z.B. "Tournament.Sport.DisciplineList[3].Name"). Zur Laufzeit wird dann per RTTI das vierte Item einer DisciplineList z.B. einem Edit zugewiesen und dessen Property Name dort zu Bearbeitung dargestellt.

Die Datenebene braucht dann überhaupt nix von einer GUI zu wissen. Sie informiert lediglich ganz allgemein, wenn es etwas neues gibt und meine Controls suchen sich dann die passenden Objekte und Propertys "automatisch" zur Anzeige und ggf. Bearbeitung heraus.
Das setzt voraus, dass die Datenobjekte und sichtbaren Controls aufeinander abgestimmt sind, aber das lässt sich durch kleine Erweiterungen von Standardcontrols realisieren.

Das o.g. "data binding" von Stevie ist eine allgemeinere Lösung (analog zum .NET), die nicht eine bestimmte Datenbasis voraussetzt.


@Jumpy
Die Geschäfts-und Datenebene sollte eben vollständig autonom sein. In meinem Fall bilde ich alles in Objekten ab, die wiederum Objekte enthalten. Die Datenmengen halten sich in Grenzen, dadurch geht das. Durch Getter und Setter und Methoden können komplexe Vorgänge gut abgebildet werden. Wenn in den Daten Änderungen erfolgt sind, gibt es eine Info an die GUI, wodurch sich alle Controls neu darstellen. Das ist alles. Ob es eine GUI gibt und was die mit der Info anstellt, ist der Datenebene wurscht.
Die Daten werden in meinem Fall in einer XML-ähnlichen Struktur gespeichert und geladen. Aber da kann natürlich grundsätzlich auch eine Datenbank oder Internetverbindung dran hängen.
Aber es ist natürlich erst mal einfacher, wenn ich zur Laufzeit alle Daten im Speicher halten kann.

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

[Luckie]

Ein Beispiel. Nehmen wir eine einfache Liste für irgendwas. Wir schreiben uns ein Ereignis, wenn etwas hinzugefügt wird, wir schreiben uns ein Ereignis, wenn etwas gelöscht wird, wir schreiben uns ein Ereignis, wenn die Liste voll ist und wir schreiben uns ein Ereignis, wenn die Liste leer ist nach dem Löschen. Jetzt haben wir zwei Schaltflächen auf unserer Oberfläche, eine zum Hinzufügen und eine zum Löschen. Wenn wir jetzt auf die Ereignisse in der Oberfläche reagieren, können wir entsprechend die Schaltflächen aktivieren und deaktivieren. Genauso können wir es machen, wenn in der Liste navigiert wird. Sind wir am Ende angekommen wird ein Ereignis ausgelöst, welches signalisiert, dass dies der letzte Eintrag ist und wir können die "Vor" Schaltfläche deaktivieren.

Wenn jetzt dein Chef ankommt und sagt: "Nee du, das ist mir nicht freaking genug, ich will eine Konsolenanwendung." dann schreibst du eben eine Konsolenanwendung und brauchst in der Daten- bzw. Logikunit nichts ändern.