Autor Beitrag
Andreas Pfau
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 997



BeitragVerfasst: Fr 02.01.04 21:21 
Hallo,

ich habe da eine Klasse, die Daten verwalten soll. In Private sind einige Propertys, und wenn man die (in der Instanz) ändert, soll eine Prozedur aufgerufen werden. Geht ja ganz Prima: Ich weise der Property bei "Write" eine prozedur zu:
ausblenden Delphi-Quelltext
1:
2:
3:
4:
  TMorphProject = class
  public
   { ... }
    property Width: Word read FWidth write SetWidth;

SetWidth() ruft dann die besagte Änderungs-Prozedur auf.

So, jetzt soll aber noch eine Klasse als Property hinzukommen:
ausblenden Delphi-Quelltext
1:
2:
3:
4:
  TMorphProject = class
  public
   { ... }
    property Blending: TMorphBlending read FBlend write SetBlend;

TMorphBlending ist ebenfalls eine Klasse mit Propertys.

Nun das Problem: Wenn ich eine Property in der Property "Blending" ändere, wird SetBlend() NICHT aufgerufen. Also kann ich nicht auf Änderungen reagieren.

Ich habe da jetzt nur eine GANZ triviale Lösung gefunden:
ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
  TMorphBlending = class
  private
    FOnChange: TProcedureOfObject;
  public
    constructor Create(OnChange: TProcedureOfObject);

Nun ruft TMorphBlending bei Änderungen die Methode OnChange() auf, und TMorphProject reagiert darauf.

Wie kann man das noch machen? Es geht so... aber haben die Borland-Developer da einen Mechanimus vorgesehen, der mir diese Umstände erspart? Oder wie macht ihr so was?

_________________
Life is a bad adventure, but the graphic is really good!
UC-Chewie
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 531

WinXP
D5 Ent
BeitragVerfasst: Fr 02.01.04 23:16 
Du musst die Änderung bei einem Objekt als Property über das "Child"-Objekt regeln. Bei einem Aufruf von ParentObject.ChildObject.Property := SetProperty wird die read-Prozedur für ChildObject aufgerufen und die write-Prozedur für ChildObject.Property!

_________________
Egal wie dumm man selbst ist, es gibt immer andere, die noch dümmer sind
ErnestoChe
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 528

Win 2000 pro, CRUX 2.0
Delphi 6 Pers, Open K3
BeitragVerfasst: Sa 03.01.04 01:02 
Hi,

ich stimme UC-Chewie zu, möchte jedoch eine kurze Anmerkung hinzufügen. SetBlend würde nur aufgerufen werden, wenn das TMorphBlending-Objekt der TMorphProject-Klasse auf ein anderes TMorphBlending-Objekt zeigen würde. Z.B. so:

ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
var
  morph: TMorphProject;
  OtherBlending: TMorphBlending;

//..................

morph.Blending := OtherBlending;


MFG

- Ernesto -
Andreas Pfau Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 997



BeitragVerfasst: Sa 03.01.04 14:01 
Hallo,

ich habe kein wort verstanden... was soll ich machen? Könnt ihr mir mal 'nen Codefetzen schicken?

EDIT: Hier nochmal, was ich genau will:
ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
6:
TClass1 = class
private
  FSomething: TClass2;
  SetSomething(Value: TClass2);
public
  property Something: TClass2 read FSomething write SetSomething;

Soweit klar. Wenn ich schreibe:
ausblenden Delphi-Quelltext
1:
Class1.Something := MySomething;					

wirt TClass1.SetSomething() aufgerufen. Das will ich ja auch. Wenn iach aber schreibe:
ausblenden Delphi-Quelltext
1:
Class1.Something.Property1 := 123;					

wird TClass1.SetSomething() NICHT aufgerufen. Soll es aber...

_________________
Life is a bad adventure, but the graphic is really good!
UC-Chewie
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 531

WinXP
D5 Ent
BeitragVerfasst: Sa 03.01.04 14:47 
Dann musst du SetSomething als write-Prozedur der Property Property1 von TClass2 definieren...

_________________
Egal wie dumm man selbst ist, es gibt immer andere, die noch dümmer sind
Andreas Pfau Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 997



BeitragVerfasst: Sa 03.01.04 15:06 
Hallo,

logisch - aber es soll doch TClass1 darauf reagieren! TClass1 ist die "Hauptklasse", die alle Daten verwaltet, und die muss mitbekommen, wenn sich in TClass2 was ändert...

Ich habe ja schon eine Idee, dass TClass1 an TClass2 eine Prozedur übergibt, die TClass2 bei Änderungen aufruft. Meine Frage war halt - geht so was nicht einfacher bzw. gibt es in Delphi da keinen besonderen Meachnismus für?

_________________
Life is a bad adventure, but the graphic is really good!
ErnestoChe
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 528

Win 2000 pro, CRUX 2.0
Delphi 6 Pers, Open K3
BeitragVerfasst: Sa 03.01.04 19:56 
Hi,

ich kenne da keinen einfachen Mechanismus. Aber so wie UC-Chewie es beschrieben hat ist es auch nicht allzu schwierig.

Ich geb dir mal ein kleines Beispiel wie ich das mache: ich hab mal eine Komponente geschrieben, die eine Eigenschaft hat, die wiederum ein Klassen-Objekt ist. Sobald sich in der Eigenschaft eine Eigenschaft änderte, sollte meine Komponente neu gezeichnet werden. Ich habe das so gelöst, dass dem Konstruktor der Eigenschaft ein Zeiger auf meine Komponente übergeben wurde und innerhalb der Set-Methoden dieser Eigenschaft wurde dann die Repaint-Methode meiner Komponente aufgerufen.

Das ist eigentlich die gängigste Methode dies zu lösen.

MFG

- Ernesto -
Andreas Pfau Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 997



BeitragVerfasst: Sa 03.01.04 20:49 
Hallo,

danke für den Tipp! Ich habe jetzt den Constructor der Unterklasse so definiert:
ausblenden Delphi-Quelltext
1:
constructor Create(AOwner: TObject);					

Nun kann diese Klasse bei Änderungen eine Methode in der Hauptklasse aufrufen - also so, wie du es beschreiben hast, denke ich mal.

Schade, dass sich das die Delphi-Developer nichts einfallen lassen haben, aber, na ja, wir sind ja auch alle Coder. Vielen Dank mal, so mache ich es dann :D

_________________
Life is a bad adventure, but the graphic is really good!