TNotifyEvents

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

[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 von Gyrospeter:

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]

Zitat von Codehunter:

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?

[Codehunter]

Zitat von Gyrospeter:

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

Kurze Antwort: Ja. Lange Antwort: Machs nicht.

[Gyrospeter]

Zitat von Codehunter:

Kurze Antwort: Ja. Lange Antwort: Machs nicht.

Ok

Zitat von Codehunter:

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 von Gyrospeter:

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 )