Hallo,

ich habe eine Klasse, zu der ich ein Setup Form erstellen möchte.
Das Setup Form soll in eine eigene Unit, damit es die Klassenunit nicht zu unübersichtlich macht.

Das ganze soll etwa so aussehen:

zusammenfalten · markieren

Delphi-Quellcode:

uses SetupForm;


TMyRecord = record
  a,b,c: string;
  list = array of string;
end;

TMyList = array of TMyRecord;

TMyClass = class(TObject)
  fVar1 : bolean;
  fVar2 : integer;
  fList : TMyList;
  fSetupForm: TSetupForm;
  private
    constructor Create;
    destruktor Destroy; override;
    // weitere Methoden und Eigenschaften...
  public
    procedure Setup;
    // weitere Methoden und Eigenschaften...
end;

implementation

procedure TMyClass.Setup;
begin
  fSetupForm := TSetupForm.Create;
  fSetupForm.Show;
end;

Dem Setup-Form würde ich gern eine Kopie der aufrufenden TMyClass Instanz mitgeben, damit dort alle Änderungen eingetragen werden können. Wenn dann das Setup Form mit OK geschlossen wird, möchte ich die Daten aus der Kopie übernehmen, ansonsten verwerfen.
Das Problem ist nur, dass ich keine Kopie mitgeben kann. Denn sowie ich im Public Bereich (oder sonst wo) des Formulars ein entsprechendes Feld einfüge, muss die TMyClass Unit in die uses Liste der Setup-Unit aufgenommen werden. Dann bekomme ich jedoch einen Fehler wegen überkreuzender Unit-Bezüge.
Es ginge höchstens mit einem uses im Implementation Teil der Setup Unit. Dann müsste ich mit einer globalen Instanzkopie arbeiten, was ich unbedingt vermeiden möchte.

Habe hier im Forum auch schon gelesen, dass man in solch einem Fall besser mit Eventhandlern arbeiten sollte. Das Setup Fromular sollte die Datenstruktur also gar nicht kennen. Wenn ich das mache, blase ich die Klassenunit aber so stark auf, dass ich letztendlich doch alles in eine Unit hätte packen können.

Kann mir jemand einen Tip geben, wie ich mein PRoblem lösen kann?

Viele Grüße,
Stefan.

tja, dann bleiben dir nur 2 Möglichkeiten

- entweder sortierst du die Definitionen so um, daß bei einer Unit die Einbindung in den Implementationsteil kann

- oder du legst dir eine weitere Unit an, wo die Definitionen reinwandern und bindest diese überall ein,
dann kann ebenfalls bei einer Unit die Einbindung der Anderen in die Implementation rutschen.


Problem ist, daß im Interface deklarierte Units vor der "Aufrufenden" compiliert werden
und wenn sich beide Units dort gegenseitig aufrufen, dann soll jeweils die Andere vorher abgearbeitet werden, was ja wohl nicht geht (Einer muß der Erste sein).

Mir ist gerade noch eine andere Möglichkeit eingefallen. Möglicherweise eine nicht besonders saubere Lösung aber es funktioniert scheinbar. Den Typ Pointer kannte ich so eigentlich noch nicht. Habs einfach mal so hingeschrieben und compiliert. Der Compiler meldet keinen Fehler und erste Tests führen zu keinen Problemen.

zusammenfalten · markieren

Delphi-Quellcode:

TMyClass = class(TObject)
  fVar1 : bolean;
  fVar2 : integer;
  fList : TMyList;
  fSetupForm: Pointer; // TSetupForm; <--- duch den Typ Pointer kann muss die Setup Unit nicht mehr in der uses Liste stehen.
  private
    constructor Create;
    destruktor Destroy; override;
    // weitere Methoden und Eigenschaften...
  public
    procedure Setup;
    // weitere Methoden und Eigenschaften...
end;

implementation

uses SetupForm;

procedure TMyClass.Setup;
begin
  fSetupForm := TSetupForm.Create;
  TSetupForm(fSetupForm).Show;
end;

Ist gegen diese Vorgehensweise etwas einzuwenden?

Nimm statt Pointer dann eher TObject ... ist verständlicher und kommt auf's Selbe raus.
Selbst wenn man keinen Vorfahren angibt, nimmt Delphi automatisch TObjekt als Vorfahre ... da dieses Vorfahre aller Objekte/Klassen ist, kann man ihm auch alles zuweisen.


und Objekte sind halt Records mit Pointer drauf

Warum nicht so:

zusammenfalten · markieren

Delphi-Quellcode:

procedure TMyClass.Setup;
var f:TSetupForm;
begin
  f := TSetupForm.Create(nil);
  try
    f.MyObject := self;
    f.ShowModal;
  finally
    f.Free;
  end;
end;

ShowModal scheint mir für einen Setup-Dialog das Richtige zu sein.
Damit braucht man auch die Referenz auf das Formular nicht dauerhaft im Objekt speichern.

Interfaces lösen das Problem der Kreuzbezüge (Crossreference), wobei hier u.U. auch Design Flaw vorliegt.

man kann auch ganz böse sein

markieren

Delphi-Quellcode:

procedure TMyClass.Setup;
begin
  with TSetupForm.Create(self) do
    try
      MyObject := self;
      ShowModal;
    finally
      Free;
    end;
end;

Zitat von himitsu:

man kann auch ganz böse sein

Einsperren.
Sofort.

Zitat von himitsu:

Nimm statt Pointer dann eher TObject ... ist verständlicher und kommt auf's Selbe raus.

Ok, habe ich jetzt gemacht. Funktioniert auch immer noch genause.

Zitat von sx2008:

ShowModal scheint mir für einen Setup-Dialog das Richtige zu sein.
Damit braucht man auch die Referenz auf das Formular nicht dauerhaft im Objekt speichern.

Ja, im Prinzip sieht das so erstmal besser aus (so hatte ich es auch anfangs gemacht).
Das löst zwar mein hier beschriebenes Problem, ich möchte den Setup Dialog aber nicht modal anzeigen lassen.
Für den Benutzer wäre es weniger komfortabel.

@alzaimir: Interfaces kenne ich noch nicht. Ich werd mal nachsehen, was es damit auf sich hat.


Ich verstehe aber nicht, was an himitsus code "böse" sein soll.... (ist doch alles ok so, oder übersehe ich was?)

[OT]

Zitat von changlee:

Ich verstehe aber nicht, was an himitsus code "böse" sein soll.... (ist doch alles ok so, oder übersehe ich was?)

Das 'With'-Schlüsselwort ist verpönt, auch wenn es Schreibarbeit spart.

markieren

Delphi-Quellcode:

procedure TMyClass.Setup;
begin
  with TSetupForm.Create(self) do
    try
      MyObject := self;
      ShowModal;
    finally
      Free;
    end;
end;

Hier stellen sich zwei Fragen;
1. Welches 'ShowModal' wird aufgerufen, das von 'TMyClass' (wenn des diese Methode hätte), oder die der anonymen Instanz von TSetupForm?
2. Welches 'Free' wird aufgerufen?

Das erschließt sich dem Betrachter nicht. Es ist zwar irgendwie klar, aber führt zu Mißverständnissen und schwer zu findenden Fehlern (wenn z.B. Deine TSetupForm gar keine Methode ,'ShowModal' hätte, z.B. weil die etwas anders heißt), dafür aber TMyClass.

Zugegeben, in diesem konkreten Beispiel ist der Code gar nicht böse, aber als Regel gilt: "'With' ist böse". Es spricht nichts dagegen, mit 'With' zu arbeiten, aber da muss man dann genau wissen, was man tut.
[/OT]
Aber der Thread hier dreht sich nicht um dieses, sondern um ein anderes Thema.