TNotifyEvents

[Gyrospeter]

Guten Morgen,

ich hoffe ich bin hier im richtigen Unterforum.

Da mein Ausbilder momentan nicht da ist und auch erst zum Ende der Woche kommt, sollte ich mich mit TNotifyEvents beschäftigen.

Ich habe schon in die Delphi-Hilfe geschaut, Google genutzt und auch hier im Forum gestöbert, allerdings prangern immer noch ein paar dicke Fragezeichen über meinem Kopf.

Es wäre schön wenn sich jemand erbarmt und mir das anhand einfacher Beispiele oder eines einfachen Textes erklären würde.

Vielen Dank.


Edit: Wieso steht da Delphi-Version 5 da oben? Ich hab es garnicht ausgewählt! Aber falls es jemandem hilft, ich nutze XE2

[Luckie]

Was hast du denn für konkrete Frage? Hast du Code, zu dem du Fragen hast? Erwartest du jetzt, dass dir hier jemand ein Tutorial schreibt?

[Gyrospeter]

Ehrlich gesagt wäre ein Tutorial nicht schlecht :D

Zum Beispiel habe ich gelesen, dass NotifyEvents nur für Prozeduren aber nie für Funktionen verwendet werden. In einem anderen Beispiel wird diese Aussage wieder revidiert.

Oder, wie und wann wende ich diese Events richtig an. Wann ist der bestmögliche Zeitpunkt?

Was hat es denn damit auf sich zu tun bzw. was ist damit konkret gemeint? Also mit diesem Abschnitt aus der Delphi-Hilfe?

"Verschachtelte Prozeduren und Funktionen (Routinen, die in anderen Routinen deklariert sind), können nicht als prozedurale Werte verwendet werden. Dasselbe gilt für vordefinierte Prozeduren und Funktionen (Standardroutinen). Wenn Sie eine Standardroutine wie Length als prozeduralen Wert verwenden wollen, müssen Sie die Routine gewissermaßen "verpacken":"

function FLength(S: string): Integer;
begin
Result := Length(S);
end;

[Luckie]

Da findet sich mit Google bestimmt was.

[DeddyH]

Was ist denn eigentlich genau gemeint? Es gibt den Typen TNotifyEvent, das ist eine Methode (Procedure) mit einem Sender-Parameter vom Typ TObject. Aber irgendwie glaube ich nicht, dass es darum geht.

[Luckie]

Zitat:

Zitat von DeddyH (Beitrag 1455102)

Was ist denn eigentlich genau gemeint? Es gibt den Typen TNotifyEvent, das ist eine Methode (Procedure) mit einem Sender-Parameter vom Typ TObject. Aber irgendwie glaube ich nicht, dass es darum geht.

Ich dachte auch erst an ein Icon im Tray (wie man früher so schön sagte. :-D).

[Gyrospeter]

Zitat:

Zitat von DeddyH (Beitrag 1455102)

Was ist denn eigentlich genau gemeint? Es gibt den Typen TNotifyEvent, das ist eine Methode (Procedure) mit einem Sender-Parameter vom Typ TObject. Aber irgendwie glaube ich nicht, dass es darum geht.

Sorry, genau das ist gemeint. Wie gesagt, mein Kopf ist voller Fragezeichen was das angeht...

Das ist doch der Methodenzeiger der in der Delphi-Hilfe unter Prozedurale Typen steht?!

[Luckie]

Der Event OnButtonClick ist zum Beispiel vom Typ TNotifyEvent. Von dem Typ muss die Prozedur sein, die ausgelöst werden soll, wenn man auf eine Schaltfläche klickt. Was ist jetzt dein Verständnisproblem?

http://docs.embarcadero.com/products...n_OnClick.html

[Gyrospeter]

Das habe ich schon verstanden, allerdings wann schreib ich denn eigene Events. Wann macht es am meisten Sinn diese zu schreiben und zu benutzen und vor allem wie am besten selbst schreiben?

[Luckie]

Na ja, wann du sie brauchst. Wenn bei einem Klick auf eine Schaltfläche was passieren soll, dann brauchst du ein Ereignis, welches den Code ausführt, der bei dem Klick ausgeführt werden soll. Und der Code muss in einer Methode vom Typ TNotifyEvent stehen.

[Neutral General]

Was einige Anfänger z.B. öfter mal fragen ist wie sie von ihrem Form2 einen Wert oder eine Komponente auf Form1 ändern können.
Eine der eleganteren Möglichkeiten ist ein Event in Form2 zu erstellen, für das Form1 einen Eventhandler schreibt.

Beispiel (Mehr oder weniger Pseudocode):

Angenommen ein Image auf Form1 soll angezeigt werden (Visible = true) wenn der Benutzer in Form2 auf einen Button klickt.
(Ist natürlich ein sehr künstliches Beispiel):

Unit2:

Delphi-Quellcode:

type
  TForm2 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
    ...
  private
    FOnShowImageButtonClick: TNotifyEvent;
  public
    property OnShowImageButtonClick: TNotifyEvent read FOnShowImageButtonClick write FOnShowImageButtonClick;
  end;

implementation

procedure TForm2.Button1Click(Sender: TObject);
begin
  if Assigned(FOnShowImageButtonClick) then 
    FOnShowImageButtonClick(Self);
end;

Unit1:

Delphi-Quellcode:

type
  TForm1 = class(TForm)
    Image1: TImage;
    procedure FormCreate(Sender: TObject);
    ..
  private
    procedure ShowImageButtonEventHandler(Sender: TObject);  
  public 
    { Public-Deklarationen }
  end;

implementation

procedure TForm1.ShowImageButtonEventHandler(Sender: TObject);
begin
  Image1.Visible := true;
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  Form2.OnShowImageButtonClick := ShowImageButtonEventHandler; // Form2 muss natürlich schon existieren
end;

Du kannst auch ein bisschen weiter gehen und deine eigenen Event-Typen definieren.
Angenommen du willst durch eine Aktion in Form2 eine Progressbar in Form1 steuern.

(Abgewandeltes Beispiel von oben):

Unit2:

Delphi-Quellcode:

type
  TMyProgressEvent = procedure(Sender: TObject; AProgressValue: Integer) of object; // of object bedeutet dass der Eventhandler eine Methode einer Klasse sein muss.
                                                                                    // ohne das wird als Eventhandler nur eine normale Proceure was normalerweise nicht gewünscht ist
  TForm2 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
    ...
  private
    FOnProgress: TMyProgressEvent;
  public
    property OnProgress: TMyProgressEvent read FOnProgress write FOnProgress;
  end;

implementation

procedure TForm2.Button1Click(Sender: TObject);
var i: Integer;
begin
  for i:= 0 to 100 do
  begin
    if Assigned(FOnProgress) then 
      FOnProgress(Self, i);
    sleep(100); // Nur zum Testen ein bisschen Verzögerung/Arbeit simulieren
  end;
end;

Unit1:

Delphi-Quellcode:

type
  TForm1 = class(TForm)
    Progressbar1: TProgressbar;
    procedure FormCreate(Sender: TObject);
    ..
  private
    procedure ProgressEventHandler(Sender: TObject; AProgressValue: Integer);  
  public 
    { Public-Deklarationen }
  end;

implementation

procedure TForm1.ProgressEventHandler(Sender: TObject; AProgressValue: Integer);
begin
  Progressbar1.Position := AProgressValue;
  // Folgende Zeilen nur zur Demonstration. Ansonsten sollte man mit Application.ProcessMessages sparsam sein (Zeichnet u.a. die Progressbar neu)
  Application.ProcessMessages; 
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  Form2.OnProgress := ProgressEventHandler; // Form2 muss natürlich schon existieren
end;

Anmerkung: Das sind jetzt natürlich blöde Beispiele. Man würde in den Fällen nicht zwangsweise für alles ein Event machen. Alternativ könnte man das Image bzw. die Progressbar auch (z.B. im Konstruktor) an Form2 übergeben und Form2 setzt die Werte dann direkt. Events sind vor allem in den Fällen interessant wo 1 oder mehrere Objekte (Form1, ...) auf eine Aktion eines anderen (Form2) reagieren müssen/wollen. Wenn Form3 z.B. auch Form2 aufrufen würde und dem OnProgressEvent ein Eventhandler zuweist der den aktuellen Fortschritt in einem Memo ausgibt, dann wäre ein Event gerechtfertigt weil es dann nicht mehr hilft Form2 im Konstruktor eine Progressbar zu übergeben, weil das Form3 nichts bringen würde.
Ich hoffe meine Erklärung ist nicht zu verwirrend :D

[Gyrospeter]

Das erste Beispiel habe ich verstanden und macht auch Sinn.

Warum sollte bzw. muss ich dann im zweiten Beispiel einen eigenen Event-Typen definieren? Wann macht sowas am meisten Sinn?

Vielen Dank schon mal und sorry für die dummen Fragen. Leider steige ich bei dem Thema Events sehr langsam hinterher...

[Neutral General]

Weil ein TNotifyEvent folgendermaßen definiert ist:

Delphi-Quellcode:

type
  TNotifyEvent = procedure(Sender: TObject) of object;

Das bedeutet einem TNotifyEvent kann man (bis auf den Sender) keine weiteren Werte übergeben.
Wenn du dem Handler des Events zusätzliche Daten zur Verfügung stellen willst (wie z.B. den ProgressValue im 2. Beispiel) musst du einen eigenen Typ definieren mit den Parametern die du zusätzlich übergeben willst:

Delphi-Quellcode:

type
  TMyProgressEvent = procedure(Sender: TObject; AProgressValue: Integer) of object; // Wir wollen AProgressValue zusätzlich mitgeben. Also brauchen wir einen eigenen Typen, weil TNotifyEvent das nicht unterstützt.

[Codehunter]

Zuerst mal würde ich mich von dem Schlagwort TNotifyEvent verabschieden. Das führt hier in die Irre. Du suchst nach einem Tutorial über Eventhandler. TNotifyEvent ist ein Eventhandler unter vielen. Oder genauer gesagt die Deklaration eines Eventhandler-Typen. Ich weiß, noch mehr Fragezeichen :-)

Ein recht gutes Tutorial kommt von Embarcadero selbst.

Und um deine andere Frage zu beantworten: Die große Mehrheit der Eventhandler sind Prozeduren. Allerdings können technisch gesehen genauso gut auch Funktionen verwendet werden.

Zitat:

Zitat von Gyrospeter (Beitrag 1455111)

Warum sollte bzw. muss ich dann im zweiten Beispiel einen eigenen Event-Typen definieren? Wann macht sowas am meisten Sinn?

Außer zu Lernzwecken? Grundsätzlich solltest du immer erst schauen ob es für deinen jeweiligen Bedarf nicht schon passende Eventhandlertypen gibt.

Eventhandler sind nützlich, wenn du eine Klasse schreibst und diese in einer separaten Unit liegt. Wenn deine Klasse eine Prozedur in deinem Hauptprogramm aufrufen soll, muss sie ja wissen welche und muss sie auch erreichen können. In schlecht programmierten Codes entstehen bei sowas Kreuzbezüge bzw. zirkuläre Referenzen. Das heißt, die Unit1 bindet Unit2 ein und Unit2 bindet Unit1 ein. Die haben mich schon viele graue Haare gekostet.

Guter Code lagert Klassen in separate Units aus und weist keine zirkulären Referenzen auf. Um das zu erreichen, sind Eventhandler ein guter Weg.

[Gyrospeter]

Warum funktioniert das zb. nicht?

Code:

type
  TForm1 = class(TForm)
    Button1: TButton;
    Button2: TButton;
    Button3: TButton;
    Memo1: TMemo;
    procedure Button1Click(Sender: TObject);
    procedure Button2Click(Sender: TObject);
    procedure Button3Click(Sender: TObject);

  private
    { Private-Deklarationen }
    FOnEvent: TNotifyEvent;
  public
    { Public-Deklarationen }
    property OnEvent: TNotifyEvent read FOnEvent write FOnEvent;
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}


{ TForm1 }

procedure TForm1.Button1Click(Sender: TObject);
begin
  Memo1.Lines.Add ('Button 1 pressed');

  if Assigned(FOnEvent) then
    FOnEvent(Self);
end;


procedure TForm1.Button2Click(Sender: TObject);
begin
  Memo1.Lines.Add ('Button 2 pressed');
end;


procedure TForm1.Button3Click(Sender: TObject);
begin
  if Assigned(FOnEvent) then
  begin
    Memo1.Lines.Add ('Nothing assigned');
    FOnEvent := nil;
  end
  else
    FOnEvent := Button2Click;
end;

end.

Zitat:

Zuerst mal würde ich mich von dem Schlagwort TNotifyEvent verabschieden. Das führt hier in die Irre. Du suchst nach einem Tutorial über Eventhandler. TNotifyEvent ist ein Eventhandler unter vielen. Oder genauer gesagt die Deklaration eines Eventhandler-Typen. Ich weiß, noch mehr Fragezeichen

Ein recht gutes Tutorial kommt von Embarcadero selbst.

Und um deine andere Frage zu beantworten: Die große Mehrheit der Eventhandler sind Prozeduren. Allerdings können technisch gesehen genauso gut auch Funktionen verwendet werden.

Danke, lese ich mir mal durch.

[Gyrospeter]

Zitat:

Zitat von Codehunter (Beitrag 1455115)

Außer zu Lernzwecken? Grundsätzlich solltest du immer erst schauen ob es für deinen jeweiligen Bedarf nicht schon passende Eventhandlertypen gibt.

Eventhandler sind nützlich, wenn du eine Klasse schreibst und diese in einer separaten Unit liegt. Wenn deine Klasse eine Prozedur in deinem Hauptprogramm aufrufen soll, muss sie ja wissen welche und muss sie auch erreichen können. In schlecht programmierten Codes entstehen bei sowas Kreuzbezüge bzw. zirkuläre Referenzen. Das heißt, die Unit1 bindet Unit2 ein und Unit2 bindet Unit1 ein. Die haben mich schon viele graue Haare gekostet.

Guter Code lagert Klassen in separate Units aus und weist keine zirkulären Referenzen auf. Um das zu erreichen, sind Eventhandler ein guter Weg.

Aber dafür hab ich doch die Public properties in den Units und kann dann dort auf die Methoden zugreifen oder nicht? :roll::?:

[Codehunter]

Zitat:

Zitat von Gyrospeter (Beitrag 1455119)

Aber dafür hab ich doch die Public properties in den Units und kann dann dort auf die Methoden zugreifen oder nicht? :roll::?:

Kurze Antwort: Ja. Lange Antwort: Machs nicht.

[Gyrospeter]

Zitat:

Zitat von Codehunter (Beitrag 1455122)

Kurze Antwort: Ja. Lange Antwort: Machs nicht.

Ok :D

Zitat:

Zitat von Codehunter (Beitrag 1455122)

Delphi-Quellcode:

procedure TForm1.Button3Click(Sender: TObject);
begin
  //if Assigned(FOnEvent) then // FALSCH HERUM!
  if not Assigned(FOnEvent) then 
  begin
    Memo1.Lines.Add ('Nothing assigned');
    FOnEvent := nil;
  end
  else
    FOnEvent := Button2Click;
end;

Funktioniert leider nicht. Denn ich will ja Button2 ausgeben wenn es Assigned ist. Im Optimalfall natürlich Button 1 und 2...

[Codehunter]

Zitat:

Zitat von Gyrospeter (Beitrag 1455123)

Funktioniert leider nicht. Denn ich will ja Button2 ausgeben wenn es Assigned ist. Im Optimalfall natürlich Button 1 und 2...

Ja deswegen hab ich das oben wieder rausgenommen. Ich hatte den Gedankengang nicht verstanden. Dein Code ist verwirrend weil du versuchst innerhalb der selben Klasse (TForm1) mit den Eventhandlern dieser Klasse zu hantieren. Also quasi sich selbst an den Haaren aus dem Sumpf ziehen ;-)

[Medium]

Sieh Event-Handler als Verweis auf eine Prozedur, und Event-Typen als Beschreibung, welche Parameter diese Prozedur haben muss.

Die Grundidee ist, dass du eine Prozedur aufrufen kannst, ohne zu wissen wie diese heißt und wo sie her kommt. Für dich ist nur wichtig, welche Parameter hinein gehen. Was nachher genau aufgerufen wird, bestimmt ein anderer Teil des Programmes, an dem einem Handler eine konkrete echte Prozedur zugewiesen wird.

Delphi-Quellcode:

type
  TMyEvent = procedure(Wert1: Integer; Wert2: String) of object;

  TMyClass = class
  private
    FOnMyEvent: TMyEvent;
    procedure DoSomething;
  public
    property OnMyEvent read FOnMyEvent write FOnMyEvent;
  end;

implementation

procedure TMyClass.DoSomething;
begin
  // mache irgendwas, wobei etwas passiert was MyEvent auslösen soll
  if Assigned(FOnMyEvent) then
    FOnMyEvent(123, 'Foo');
end;

Delphi-Quellcode:

type
  TForm1 = class(TForm)
  private
    MyObject: TMyClass;
    procedure MyEventHandler(Wert1: Integer; Wert2: String);
  end;

implementation

procedure TForm1.OnCreate(Sender: TObject);
begin
  MyObject := TMyClass.Create;
  MyObject.OnMyEvent := MyEventHandler; // <-- ab jetzt ist der Aufruf von FOnMyEvent() oben in TMyClass identisch mit einem Aufruf von MyEventHandler() in TForm1
end;

procedure TForm1.MyEventHandler(Wert1: Integer; Wert2: String);
begin
  ShowMessage('Es ist etwas passiert! Und zwar: '+IntToStr(Wert1)+' und '+Wert2); // Ausgabe wenn TMyClass.OnMyEvent() wie oben aufgerufen wird: "Es ist etwas passiert! Und zwar: 123 und Foo"
end;

Der große Vorteil ist, dass TMyClass hierdurch Prozeduren aus anderen Klassen aufrufen kann, ohne die Klasse, deren Herkunft oder sonst irgend etwas zu wissen. Man kann einfach dynamisch irgend eine Prozedur zuweisen - sie muss nur dieselben Parameter haben. Und das stellt man am besten sicher, indem man einen Typ "procedure() of object" nimmt, der diese sog. Signatur typsicher festlegt. TNotifyEvent ist lediglich solch ein Typ, und besagt "irgend eine Prozedur (die einem Objekt zugeordnet ist), die einen Parameter vom Typ TObject hat". Mehr nicht.

Das ganze MUSS nichtmals nur für Events genutzt werden. Das Konzept ist generell verwendbar, bietet sich aber für Events sehr an. (Genau genommen sind "Events" auch nur eine lose Definition, kein eigenständiges Konzept der Sprache an sich. Es sind einfach Methodenzeiger, die aufgerufen werden, wenn dies semantisch als ein Ereignis interpretiert werden kann. Man kann Methodenzeiger auch anders einsetzen. Hier wird's aber etwas philosophischer :D )

[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.

[TurboMagic]

Zitat:

Zitat von Jumpy (Beitrag 1455186)

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.

Glaube ja. Delphi selbst bietet mit TMessage-irgendwas in FMX auch inzwischen eine Observer-Pattern Umsetzung an.

[generic]

Wer noch ein Einstieg in die Thematik braucht, ich hab da mal 20 Minuten drüber gequatscht:
https://www.delphipraxis.net/203143-...unktionen.html