Zirkularen Bezug von zwei Forms wie vermeiden ?

[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...:-D)

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

Zitat von stahli (Beitrag 1104121)

Zeigst Du mal einen Screenshot?

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

Zitat:

Zitat von stahli (Beitrag 1104121)

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.

[Sir Rufo]

Zitat:

Zitat von himitsu (Beitrag 1104044)

[add]

Zitat:

Zitat von Sir Rufo (Beitrag 1104041)

Das funktioniert auch, aber mit der Gewissheit, dass die Referenz auf das Objekt nicht verändert werden kann

Ohne CONST geht es bei den Objekten genauso gut ... erzeugt genau den selben Code (ASM), ist etwas kürzer (Quellcode)
und sagt nicht "implizit" aus, daß da nichts verändert wird (Objektinhalt).

Keiner versteht mich :cry:

Ich spreche doch von dem Pointer auf das Objekt (eben halt die Referenz darauf), weil nur der wird übergeben.
Mit einem var Parameter signalisiere ich, das dieser übergebene Wert sich in der Procedere verändern kann (hier also der Pointer). Und bei einer Objekt-Referenz möchte man das nur in den seltensten Fällen.

Wenn der Objekt-Inhalt nicht geändert werden soll/darf, darum muss sich das Objekt selber kümmern.

[stahli]

Wir kommen etwas vom Thema ab, aber in gewisser Weise passt es ja schon noch...

Schönes Beispiel, Luckie.
Das Konzept wird nur recht aufwendig, wenn Du 50 Listen hast und manche Listen in mehreren Controls dargestellt werden sollen. Dann musst Du sehr viele Ereignisse verarbeiten. Das ist nicht kompliziert, aber nix für faule. :wink:

Mit einer data binding - Lösung sagt man einem Control nur: Zeig mal diese Liste an (es können auch 3 Controls an eine Liste gebunden werden) und den Rest regeln dann die Controls selbständig. Eines kann den Listenanfang anzeigen, eines mittendrin und eines das Ende. Die Listencontrols können dann selbst entscheiden, ob sie Navigationsschalter anzeigen oder nicht.

Die GUI-Anwendung muss dann viel weniger entscheiden.
Natürlich wäre es dann (wie bei meinen Controls) nicht mehr so leicht möglich, eine Consolenanwendung daraus zu machen. Die GUI ist unbedingt an einen gewissen Standard gebunden, um mit der Datenebene zusammen arbeiten zu können.
Dafür ist die Entwicklung damit sehr einfach:
1) ListBox auf die Form
2) Liste zuweisen
3) Property "NickName" definieren
...und schon wird eine Liste angegezeigt...

Zitat:

stahli
Luckie
RWarnecke

Je nach Einstellungen lässt die ListBox dann Einfügungen, Löschen, Drag&Drop etc. zu oder nicht.

Ein Screenshot aus meinem Projekt. Im Formular brauche ist kaum etwas regeln, das in die Projektdaten eingreift. Ich sage (weitestgehend) nur in den ListBox-Propertys, welche Listen in welcher Form angezeigt werden sollen und welche Bearbeitungen erlaubt sind.

EDIT: Das Vereins-Formular beinhaltet eine unsichtbare Komponente "TodFormCtrl", der ein Vereinsobjekt zugewiesen wird (das erfolgt wiederum automatisch - also Komponenten-intern, wenn der User in der MainForm auf einen Vereineintrag doppelklickt). Die Vereinskomponente kennt ihr zuständiges Formular, öffnet dieses und weist dem sich selbst zu. Das odFormCtrl reicht die Daten an alle weiteren Formularkomponenten durch, die sich die benötigten Property heraus suchen und diese anzeigen. Das alles benötigt keine Programmierung.