Zirkularen Bezug von zwei Forms wie vermeiden ?

[RWarnecke]

Hallo zusammen,

ich habe zwei Formulare Form1 und Form2. Wenn ich jetzt bei Form2 das Parent auf Form1 setze, wird mir ja Form2 in Form1 angezeigt. Wenn jetzt Form2 bestimmte Elemente wie z.B. Buttons steueren soll (z.B. Aktivieren und Deaktivieren) muss ich ja einen zirkularen Bezug der beiden Units herstellen.

Kann ich das auch nich irgendwie anders realisieren ? Mir schwebt da zum Beispiel vor mit Messages oder bestimmten Events. Nur leider habe ich dazu keinen Denkansatz, was hier am besten ist.

Gruß
Rolf

[Sir Rufo]

Du kannst die beiden Units kreuzweise im implementation Teil eintragen, dann tun die sich auch nichts :)
Problematisch wird es nur im Interface Teil

[RWarnecke]

Hallo Sir Rufo,

danke für Deine Antwort. Mir ist gerade aufgefallen, ich habe noch etwas vergessen bei meiner Ausführung. :oops: Die Buttons sollen auch bestimmte Aktionen in der Form2 steuern. Deswegen der zirkulare Bezug.

[himitsu]

Nur wenn du im Implenentations-Teil Deklarationen der anderen Unit benötigst oder in Initialisation/Finalization was von drüben verwendest, muß diese Unit in Implementation importiert werden.
Ansonten kann man sie halt auch erst in Implementation importieren und dort gibt es keine Probleme mit zirkulären Referenzen (für den Compiler).

[ConnorMcLeod]

Mach eine dritte Unit mit Hilfsfunktionen, die die Komponenten und Werte als Parameter hat.

[himitsu]

Zitat:

Zitat von ConnorMcLeod (Beitrag 1104001)

Mach eine dritte Unit mit Hilfsfunktionen, die die Komponenten und Werte als Parameter hat.

Bzw. gleich die ganze Logik dort rein.

Der Button und der Aufruf aus der anderen Unit/Form rufen dann einfach direkt die gewünschte Funktion auf. :stupid:

[RWarnecke]

Zitat:

Zitat von ConnorMcLeod (Beitrag 1104001)

Mach eine dritte Unit mit Hilfsfunktionen, die die Komponenten und Werte als Parameter hat.

Die Idee hört sich interessant an. Nur kann ich mir noch nicht vorstellen, wie ich das Aktivieren oder Deaktivieren eines Buttons über eine dritte Hilfsunit steuern kann. Ich müsste in der Hilfsunit für jede Aktion die ich machen möchte eine eigene Procedure schreiben.

Zitat:

Zitat von himitsu (Beitrag 1104003)

Zitat:

Zitat von ConnorMcLeod (Beitrag 1104001)

Mach eine dritte Unit mit Hilfsfunktionen, die die Komponenten und Werte als Parameter hat.

Bzw. gleich die ganze Logik dort rein.
Der Button und der Aufruf aus der anderen Unit/Form rufen dann einfach direkt die gewünschte Funktion auf. :stupid:

Ähm, da komme ich mal wieder nicht mit. Ich habe doch die Buttons in der Form1, wie soll ich denn die Logik der Komponenten in die Hilfsunit auslagern. Das einzigste was ich mir gerade vorstellen kann, wäre die Komponenten (Buttons u.s.w.) zur Laufzeit zu erstellen. Liege ich da mit meiner Vorstellung richtig ?

[ConnorMcLeod]

Delphi-Quellcode:

procedure tuwas(var AButton: TButton);
begin
  AButton.Caption := 'helloworld';
end;

procedure tuwasanderes(var AButton: TButton; const AText: string);
begin
  AButton.Caption := 'helloworld';
  AButton.Hint    := AText;
end;

So einfach ist das.

[Sir Rufo]

äh, wozu übergibst du die Objekt-Referenz als var Parameter?

Das wäre ja ein Hinweis, dass in der Procedere die Objekt-Referenz verändert werden könnte.

[ConnorMcLeod]

Eben drum. Das ist ja der Sinn der ganzen Übung.

[Sir Rufo]

Zitat:

Zitat von ConnorMcLeod (Beitrag 1104039)

Eben drum. Das ist ja der Sinn der ganzen Übung.

Und wo wird da die Referenz verändert? :gruebel:

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

Delphi-Quellcode:

procedure tuwas( const AButton: TButton );
begin
  AButton.Caption := 'helloworld';
end;

procedure tuwasanderes( const AButton: TButton; const AText: string );
begin
  AButton.Caption := 'helloworld';
  AButton.Hint := AText;
end;

[himitsu]

Ups, der Post hatte sich wohl irgendwie verlaufen :shock:
Nja, bevor ich den dort drüben löschen lass...

Zitat:

Die Logik steuert deine Forms.

Code:

LogicUnit
  interface
    uses Unit1, Unit2; 

Unit1 und Units2
  implementation
    uses LogicUnit;

In der Logik werden die Fenster erstellt und verwaltet (wie z.B. das Enablen/Diablen von Buttons).

Die Forms können sich jetzt an die Logik wenden und diese bitten etwas zu machen, wie z.B. eine Funktionalität abzuschalten (und damit auch den Button zu disablen)


PS: Wenn man ganz krank ist, dann bekommt man auch mehrere Forms in eine Unit rein.
Nur der Formdesigner mag sowas nicht unbedingt, aber Compiler und Debugger ist sowas vollkommen egal.

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

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

Zitat von Luckie (Beitrag 1104090)

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:

Zitat von RWarnecke (Beitrag 1104101)

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.

Delphi-Quellcode:

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:

Zitat von stahli (Beitrag 1104121)

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

Zitat von Jumpy (Beitrag 1104125)

Zitat:

Zitat von stahli (Beitrag 1104121)

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

Zitat von Jumpy (Beitrag 1104125)

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