Auf "überliegende" Klasse zugreifen ?

[Olli73]

Hast du den Code gekürzt oder sieht der wirklich so aus?

Denn darin gibt es keine Konstruktoren und diese werden auch nicht aufgerufen (um die Instanzen/Objekte zu erstellen).

Gruß,
Olli

[stiftII]

Hey
Ja der Code ist stark vereinfacht, beim Originalcode blickt man vermutlich nicht so gut durch.

Ja hatte vergessen .create aufzurufen. Habs aber schon reineditiert

Muss man beim Konstruktor irgendwas beachten, damit auf "FMainClass" von "TUsefullclass" zugegriffen werden kann ?

[Olli73]

Ohne genau zu wissen, was du vorhast, kann dir keiner Tipps geben, wie du das sauber aufbauen kannst.

Aber grundsätzlich:

Du musst beide Objekte erstellen (create) und die Werte für FMainClass und UseFullClass entsprechend zuweisen (die müssen auf das jeweils andere Objekt, das du erstellst, zeigen).

Gruß,
Olli

[Dejan Vu]

Nee, mach das nicht. Wenn A eine Eigenschaft von B ist, soll A keine Kenntnis von B haben. Wenn man so anfängt, sollte man es gleich sein lassen. denn 'A' könnte ja auch mal eine Eigenschaft von C sein, was aber nun nicht mehr wegen der Abhängigkeit zu B geht. Nee, nee.

Wenn die sich was zu sagen haben, dann soll 'A' ein Event bereitstellen, an das B sich hängen kann.
Und wenn 'A' etwas wissen muss, was auch 'B' weiß, dann soll 'B' das 'A' gefälligst mitgeben, z.B. so

Delphi-Quellcode:

Type
  TClassA = Class
  private
    fInfo : TInfo; 
  public
    constructor Create (info : TInfo);
  end;

  TClassB = Class
  private
    FA: TClassA;
    FInfo : TInfo;
  public
    Constructor Create;
  end;

Constructor TClassB.Create;
Begin
   Finfo := TInfo.Create;
   FA := TClassA.Create(FInfo);
End;

[DeddyH]

Habbich doch gesacht, nur kürzer

[stiftII]

Danke nochmal.

Zitat:

Ohne genau zu wissen, was du vorhast, kann dir keiner Tipps geben, wie du das sauber aufbauen kannst.

Okay dann versuch ichs mal zu erklären . Es soll ein Programm werden welches Pokertische verwaltet. Und es arbeitet mit einer Hauptklasse die 3 Threads aufruft.. So in Etwa:

Delphi-Quellcode:

    TMainClass = class
      ID:integer;
      UsefulThreadA:TUsefulThreadA;
      UsefulThreadB:TUsefulThreadB;
      UsefulThreadC:TUsefulThreadC;
      protected
        constructor Create;
    end;

Nun findet UsefulThreadA eine ID heraus und soll sie TMainClass übergeben. Sobald die Information zur Verfügung steht starten UsefulThreadB und UsefulThread C.

Also müssen UsefulThreadB und C wissen, was in TMainClass(.id) steht.

Zitat:

Wenn die sich was zu sagen haben, dann soll 'A' ein Event bereitstellen, an das B sich hängen kann.
Und wenn 'A' etwas wissen muss, was auch 'B' weiß, dann soll 'B' das 'A' gefälligst mitgeben, z.B. so

Das sieht echt super aus, ich glaube ich schreibe das ganze Programm etwas um und mache es dann so, dass ich die ID vorher hole und dann UsefulThreadB und UseFulThreadC im Constructor bei TMainClass mit übergebe.

Wobei ich glaube das das auch nicht optimal ist, da ich dann UsefulThreadA extern von meiner TMainClass hätte. Aber so würde es natürlich funktionieren.

Danke für eure Eingebungen

[Olli73]

Zitat von stiftII:

Danke nochmal.
Okay dann versuch ichs mal zu erklären . Es soll ein Programm werden welches Pokertische verwaltet. Und es arbeitet mit einer Hauptklasse die 3 Threads aufruft.. So in Etwa:

Delphi-Quellcode:

    TMainClass = class
      ID:integer;
      UsefulThreadA:TUsefulThreadA;
      UsefulThreadB:TUsefulThreadB;
      UsefulThreadC:TUsefulThreadC;
      protected
        constructor Create;
    end;

Nun findet UsefulThreadA eine ID heraus und soll sie TMainClass übergeben. Sobald die Information zur Verfügung steht starten UsefulThreadB und UsefulThread C.

Also müssen UsefulThreadB und C wissen, was in TMainClass(.id) steht.

Wenn das ganze auch noch in Threads ablaufen soll, darfst du sowieso nicht einfach aus dem Thread heraus auf MainClass zugreifen. Dann musst du das ganze mittels Synchronize und/oder CriticalSections absichern...

Gruß,
Olli

[stiftII]

Hey danke für den Comment.
Ich benutze dafür CriticalSections. Wobei ich gelesen habe, dass es bei Lesezugriffen eigentlich keine Speicherverletzungen gibt.

Werds wohl jetzt so in etwa machen wie Dejan Vu beschrieben hat.

Allerdings schade, dass ich die andere Möglichkeit (Die ich zugegebenermaßen nicht ganz verstehe) nicht verwenden kann.

Programmcode sieht da so aus:
Falls mal jemand schauen mag warum das eine Zugriffsverletzung gibt.

Delphi-Quellcode:

unit Unit1;

{$mode objfpc}{$H+}

interface

uses
  Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, StdCtrls;

type

  { TForm1 }

  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
    procedure FormCreate(Sender: TObject);
  private
    { private declarations }
  public
    { public declarations }
  end;

  TMainClass = class;

    TUseFulClass = class
      private
        FMainClass: TMainClass;
      public
        function DoSomething:boolean;
    end;

    TMainClass = class
      usefulinfos:string;
      UsefulClass:TUsefulClass;
      protected
        constructor Create;
    end;



var
  Form1: TForm1;
  MainClass:TMainClass;

implementation

{$R *.lfm}

   { TForm1 }
constructor TMainClass.Create;
begin
    UsefulClass := TUseFulClass.Create;
    //UsefulClass.FMainClass := TMainClass.Create;  // Macht ja nicht so viel Sinn
end;

   procedure TForm1.Button1Click(Sender: TObject);
   begin
     MainClass := TMainClass.Create;
     MainClass.usefulinfos:= 'Very useful Infos';
     Mainclass.usefulClass.DoSomething;
   end;

procedure TForm1.FormCreate(Sender: TObject);
begin

end;

   function Tusefulclass.DoSomething:Boolean;
   begin
      //Access Violation
      Form1.Caption:= fmainClass.usefulinfos;


   end;


end.

[Olli73]

Zitat von stiftII:

Delphi-Quellcode:

constructor TMainClass.Create;
begin
    UsefulClass := TUseFulClass.Create;
    //UsefulClass.FMainClass := TMainClass.Create;  // Macht ja nicht so viel Sinn
end;

Delphi-Quellcode:

constructor TMainClass.Create;
begin
    UsefulClass := TUseFulClass.Create;
    UsefulClass.FMainClass := self;  // aber das hier Würde zumindest funktionieren, auch wenn es etwas unschön ist, wie du an den anderen Kommentaren siehst
end;

Edit: Etwas besser wäre es, wenn du TUseFullClass einen entsprechenden Constructor mit Parameter "Owner" (bzw. "MainClass") hinzufügst und denn so aufrufst: UsefulClass := TUseFulClass.Create(self);

[stiftII]

Hey, das funktioniert ja wunderbar .

Danke nochmal für die Ausführungen