TNotifyEvents

[Codehunter]

Zitat:

Zitat von Medium (Beitrag 1455127)

Das ganze MUSS nichtmals nur für Events genutzt werden. Das Konzept ist generell verwendbar, bietet sich aber für Events sehr an.

Richtig! Irgendwo in der guten alten Delphi-5-Hilfe gab es da mal den schönen Satz "Event-Handler sind Methodenzeiger". Wenn man so will wurden Methodenzeiger nur für die Ereignisbehandlung "missbraucht" und mit dem Objektinspektor in der IDE grafisch aufbereitet. Wenn man davon ausgeht erschließt sich einem der eigentliche Zweck des Ganzen nicht unbedingt. Ich weiß noch gut wie ich mich damals damit geplagt habe bis ich das verstanden hatte. Bei mir war der Anlass des Ganzen, dass ich selber grafische Komponenten schreiben wollte. Die D5-IDE war damals alles andere als gutmütig wenn man ein unsauber programmiertes Package installiert hat.

Insofern kann ich die Verwirrung von Gyrospeter gut verstehen. Aber irgendwo fängt jeder mal klein an :-)

[Gyrospeter]

Jetzt habe ich es tatsächlich wirklich begriffen :D

Nochmal eine kleine Frage zu den Event-Typen. Das heißt wenn ich in anderen Units Prozeduren habe, die ich in meiner MainUnit verwenden will, unabhängig von den Klassen der anderen Units, dann verwende ich die Event-Typen dafür.
Und wenn es zum Eventhandler kommt, dann ist dem ja völlig egal wer oder was das Ereignis auslöst. Er verarbeitet es nur weiter?!

[Codehunter]

Zitat:

Zitat von Gyrospeter (Beitrag 1455131)

Nochmal eine kleine Frage zu den Event-Typen. Das heißt wenn ich in anderen Units Prozeduren habe, die ich in meiner MainUnit verwenden will, unabhängig von den Klassen der anderen Units, dann verwende ich die Event-Typen dafür.

Genau anders herum. Du hast in der Mainunit eine Prozedur, die du von der Klasse aus aufrufen willst. Die Klasse liegt in einer separaten Unit. Hierarchisch steht die Mainunit über der anderen Unit. Deshalb gehören in sauberen Quellen die Namen der übergeordneten Units niemals in den Uses-Abschnitt einer Unter-Unit. Wenn du das immer beachtest, ergibt sich die Notwendigkeit eines Eventhandlers von ganz allein wenn es soweit ist :-)

Zitat:

Zitat von Gyrospeter (Beitrag 1455131)

Und wenn es zum Eventhandler kommt, dann ist dem ja völlig egal wer oder was das Ereignis auslöst. Er verarbeitet es nur weiter?!

Genau. Es kann durchaus sein, dass ein und der selbe Eventhandler mit mehreren Event-Properties ganz unterschiedlicher Klasseninstanzen verknüpft ist. Du kannst ja z.B. deinem Button2 auch im OnClick den Eventhandler Button1Click zuweisen. Dann machen beide Buttons das selbe.

[Medium]

Zitat:

Zitat von Codehunter (Beitrag 1455132)

Genau. Es kann durchaus sein, dass ein und der selbe Eventhandler mit mehreren Event-Properties ganz unterschiedlicher Klasseninstanzen verknüpft ist. Du kannst ja z.B. deinem Button2 auch im OnClick den Eventhandler Button1Click zuweisen. Dann machen beide Buttons das selbe.

Soweit ich weiß geht allerdings das umgekehrte nicht in Delphi: Dass ein Button mehrere Handler aufrufen kann. Das nennt sich dann Multicasting (Edit: Oder Delegates? In C# hießen die so meine ich. Lange her.)

[Gyrospeter]

Ich denke vom Grundprinzip her, hab ich es verstanden, oder? :roll::?:

Unit1

Code:

type
  TForm1 = class(TForm)
    Button1: TButton;
    Memo1: TMemo;
    procedure FormCreate(Sender: TObject);
    procedure Button1Click(Sender: TObject);
    procedure FormDestroy(Sender: TObject);

  private
    { Private-Deklarationen }
    MyObject: TMyClass;

    procedure MyEventHandler(z: Integer);
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}


{ TForm1 }

procedure TForm1.Button1Click(Sender: TObject);
begin
  MyObject.Addition;
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  MyObject := TMyClass.Create;
  MyObject.OnMyEvent := MyEventHandler;
end;


procedure TForm1.FormDestroy(Sender: TObject);
begin
 MyObject.Free;
end;

procedure TForm1.MyEventHandler(z: Integer);
begin
  Memo1.Lines.Add(IntToStr(z));
end;

end.

Unit2

Code:

type
  TMyEvent = procedure (z: Integer) of Object;

  TMyClass = class
  private
    FOnMyEvent: TMyEvent;

  public
    property OnMyEvent: TMyEvent read FOnMyEvent write FOnMyEvent;
    procedure Addition;
  end;


implementation

uses
  Notify;

{ TMyClass }

procedure TMyClass.Addition;
var i,j,z: Integer;
begin
  i := 4;
  j := 3;

  z := j + i;

  if Assigned(FOnMyEvent) then
    FOnMyEvent(z);
end;

end.

[Neutral General]

Jo das sollte so passen. :thumb:

[Gyrospeter]

Vielen Dank an alle die mir dabei geholfen haben :)

[Codehunter]

@Gyrospeter: 100 Punkte 8-)

Zitat:

Zitat von Medium (Beitrag 1455140)

Soweit ich weiß geht allerdings das umgekehrte nicht in Delphi: Dass ein Button mehrere Handler aufrufen kann. Das nennt sich dann Multicasting (Edit: Oder Delegates? In C# hießen die so meine ich. Lange her.)

Das ist richtig. In Javascript heißt es Propagation und eine ziemlich nervige Krankheit. Bei jQuery löst ein stopPropagation so manches Problem ^^ Ich habe sowas bei Bedarf in Delphi immer über Messages gelöst. Das gilt dann aber nur für VCL und Win32/64.

EDIT: Wobei mir gerade die folgende Idee kommt (Papiertheorie!):

Delphi-Quellcode:

type
  TNotifyEvents = TArray<TNotifyEvent>;

  TMyClass = class(Irgendwas)
  private
    FEvents: TNotifyEvents;
  protected
    procedure DoEvents;
  public
    property Events: TNotifyEvents read FEvents write FEvents;
  end;

implementation

procedure TMyClass.DoEvents;
var
  LEvent: TNotifyEvent;
begin
  for LEvent in FEvents do begin
    if Assigned(LEvent) then begin
      LEvent(Self);
    end;
  end;
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  FMyClass.Events := [Eventhandler1, Eventhandler2, Eventhandler3];
end;

[Jumpy]

Das geht dann in Richtung Observer-Pattern (richtiges Pattern?). Es wird eine Liste mit Methodenzeigern verwaltet und die wird dann abgeklappert und alle dort registrierten Methoden aufgerufen.

[Codehunter]

Groß was anderes machen die Delegations ja auch nicht. Nur dass die Prozedurkette automatisch generiert wird.