Zirkularen Bezug von zwei Forms wie vermeiden ?

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