TNotifyEvents

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

[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

[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

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