Arbeiten mit mehreren Forms, Vermeiden zirkulärer Referenz (XE7)

[wonkos2]

Guten Morgen allerseits,

wie gelange ich über das Drücken eines Knopfes auf eine neue Form (altes Design)? Ich muß Variablen aus Form A in Form B übernehmen, Form B aus Form A aus heraus aufrufen/erzeugen (FormB.Show). Die Anweisung Application.CreateForm(TFormB, FormB) habe ich versucht, sowohl im Hauptprogramm als auch über den Prozeduraufruf eines Knopfes in FormA aufzurufen - beides ohne Erfolg.

Hat jemand dazu eine Idee bitte?

[DeddyH]

Das klingt für mich ein wenig wirr. Sofern ich das richtig verstanden habe wäre es IMO das Einfachste, FormB ein paar Properties zu spendieren. FormA muss dazu FormB kennen, aber nicht umgekehrt. Nun kann FormA auf FormB zugreifen, diese Properties mit seinen eigenen Werten belegen und es anzeigen. Sauberer wäre natürlich eine strikte Trennung von Logik und Darstellung, aber das würde den Rahmen dieses Threads sprengen.

[baumina]

Noch eine nicht so schöne, aber schnelle Lösung ist es unterhalb von implementation die uses-Liste zu führen

Delphi-Quellcode:

unit FormB;

interface 

// ...
implementation

uses FormA;

[p80286]

Zitat:

Zitat von DeddyH (Beitrag 1292772)

Sauberer wäre natürlich eine strikte Trennung von Logik und Darstellung, aber das würde den Rahmen dieses Threads sprengen.

Warum?
Nur weil kein Unterschied zwischen der Logik/Daten und der Darstellung gemacht wird, gibt es überhaupt solche Fragestellungen.

Mein Vorschlag wäre übrigens so etwas wie eine "Daten-Unit" die von beiden Forms aus erreichbar ist.

Gruß
k-H

[Luckie]

Was DeddyH meint: http://michael-puff.de/Programmierun...tauschen.shtml

[DeddyH]

Exakt!

[wonkos2]

Zitat:

Zitat von baumina (Beitrag 1292774)

Noch eine nicht so schöne, aber schnelle Lösung ist es unterhalb von implementation die uses-Liste zu führen

Delphi-Quellcode:

unit FormB;

interface 

// ...
implementation

uses FormA;

Danke für den Tip! Das frißt der Compiler erstaunlicherweise ohne Mucken, aber Form B wird trotzdem nicht angezeigt. Den Knopf habe ich als
Ereignisprozedur hinzugefügt. High noon, was tun?

@DeddyH : Danke für das Beispiel, ich fürchte aber unter XE7 muß das etwas anders aussehen. Mit Create(Nil) bekomme ich kein ordentliches Handle.
Ich habe es auch schon mit Create(self) probiert, ebenso ohne Erfolg.

Grüße,

wonkos2

[DeddyH]

Zeig doch mal Deinen Code. Der Owner hat ja mit Handles nichts zu tun.

[wonkos2]

Zitat:

Zitat von DeddyH (Beitrag 1292788)

Zeig doch mal Deinen Code. Der Owner hat ja mit Handles nichts zu tun.

Danke, habe es selbst hinbekommen. :)

[himitsu]

Und der Nächste, mit dem selben Problem, weiß jetzt natürlich ganz genau, wie du es gelöst hast, wenn er in 1-2 Jahren diesen Beitrag in der SuFu entdeckt. :thumb: :roll:

[wonkos2]

Zitat:

Zitat von himitsu (Beitrag 1292825)

Und der Nächste, mit dem selben Problem, weiß jetzt natürlich ganz genau, wie du es gelöst hast, wenn er in 1-2 Jahren diesen Beitrag in der SuFu entdeckt. :thumb: :roll:

OK, dann will ich mal beschreiben, was ich gemacht habe: Der Hinweis, meine FormA (also die primäre) unterhalb der unteren Uses-Klausel, nämlich innerhalb der implementation unterzubringen, hat meine zirkuläre Referenz aufgelöst. Jetzt muß ich nur noch das Variablenproblem lösen, dann bin ich einen Schritt weiter. OK?

[Luckie]

Und was spricht gegen die Lösung von DeddyH und mir? Anstatt so ein Gewurstelt mit den uses Klauseln?

[DeddyH]

Ja eben. Auch wenn der Compiler jetzt zufrieden ist, bleibt ja die Tatsache, dass sich beide Formulare gegenseitig kennen müssen.

[himitsu]

Zitat:

Zitat von DeddyH (Beitrag 1292886)

bleibt ja die Tatsache, dass sich beide Formulare gegenseitig kennen müssen.

Besser nicht!

Einer bietet Schnittstellen (Funktionen/Events/Property) an und der Andere benutzt sie, ohne daß Ersterer weiß wer/was er ist, bzw. ob es ihn überhaupt gibt.


Nur so ist es wiederverwendbar, austauschbar, wartbar, ...

[DeddyH]

Genau darum geht es Luckie und mir doch, wurde aber nicht umgesetzt.

[himitsu]

Zitat:

Zitat von DeddyH (Beitrag 1292890)

Genau darum geht es Luckie und mir doch, wurde aber nicht umgesetzt.

Ups, falsch gelesen verstanden. :oops:

Zusammen mit der übersehenen Antwort von wonkos2, ergibt es mehr Sinn.

Zitat:

hat meine zirkuläre Referenz aufgelöst.

Nicht aufgelöst, sondern nur abgeschwächt.

Und das Abschwächen kann böse Nachwirkungen haben. (Initialisierungsreihenfolge)
Besser möglichst alle Units nur im Interface einbinden.

[Sir Rufo]

Auf die ganz billige Art und Weise löst man das mit einem DataModule.

Dort sind die Daten und die Forms zeigen die Daten an. Schon kennen die Forms nur noch das DataModule und nicht mehr sich selber untereinander.

[stahli]

@wonkos2

Damit Du vielleicht besser verstehst, was die Profis meinen: Man solle z.B. den Kunden-Vornamen nicht in EditVorname.Text speichern.
Wenn Du eine Rechnung druckst, muss sonst der Reportgenerator Deine Formularinstanz kennen.

Die Daten und die Geschäftslogik sind daher besser in eigenen Klassen aufgehoben oder hilfsweise in einem Datenmodul.

Die Formulare sind eigentlich nur eine Schnittstelle für den Anwender.

Du kannst natürlich Dein Projekt mit den Daten und Geschäftslogik in Formularen umsetzen, aber wenn Du später Dein Projekt mal ausbauen willst wirst Du dann erhebliche Probleme bekommen.