Event-Typen und warum deren Inhalte manchmal nicht stimmen

[himitsu]

ups

$if Declared() und nicht $if Defined()

[BAMatze]

jupp jetzt funktioniert es.

ist die FastMM4_Readme.txt = Anleitung?

Edit1: ok hab mich jetzt zumindest mal durch alle Anleitungen durchgewurschtelt, die ich hier gefunden hab und auch die Event-Log-Datei erstellt bekommen. Ich glaube gelesen zu haben, dass man diese von unten lesen soll und werde auch versuchen, mittels Auskommentieren, die Probleme zu finden und somit zu beseitigen. Bei einigen Speicherlecks steht ja auch glücklicher Weise drin, wo sie Auftreten, also die Unit.
Hänge mal die Log hier an, vieleicht kann ja mal jemand schauen, ob so ein Fehler drin ist (weiß ja nicht, ob man sowas auf einen Blick erkennt), der mir die Probleme bereitet, die zur Post-Topic gehören.

Vielen Dank
BAMatze

[Blup]

Ich vermute du hast nicht ganz verstanden was Uwe Raabe dir sagen wollte:
if Assigned(OnTischChange) then OnTischChange; FOnTischChange wird abgerufen und sofort ausgeführt.
Dann wird geprüft ob das nicht vorhandene Funktionsergebnis ungleich nil ist.
Sollte das der Fall sein, wird FOnTischChange erneut abgerufen und ausgeführt.

if Assigned(FOnTischChange) then FOnTischChange; Es wird geprüft ob FOnTischChange ungleich nil ist.
Sollte das der Fall sein, wird FOnTischChange ausgeführt.

Deshalb führt die erste Variante zur Zugriffsverletzung.

Unabhängig davon würde ich jedem Event immer den Sender mitliefern.

[BAMatze]

Ah ok dann werde ich die Variante auch nochmal testen am Montag. Wobei der Hinweis mit den Speicherlecks und so ja wie ich sehe auch berechtigt war.

Vielen Dank
BAMatze

[BAMatze]

Also hab heute mal beide Varianten nochmal durchprobiert, sowohl:

if assigned(OnTischChange) then OnTischChange; also auch

if assigned(FOnTischChange) then FOnTischChange; Bei beiden gibt der Debugger als Wert für FOnTischChange/ OnTischChange eine Zugriffsverletzung bei 00000000 aus. Sieht für mich aus, als wenn er sie gar nicht erzeugt. Hab nochmal direkt in die Komponente, in der ich dieses Event implementieren will geschaut und die dcu-Datei kontrolliert, ob sie im Verzeichnis liegt, wo Delphi drauf zugreift. Das scheint zu passen.

Kann es aber trotzdem sein, dass dort ein Problem mit dem Erzeugen des Events vorliegt?

BAMatze

Edit 1: Der Fehler hat sich gerade erledigt. Habe die Komponente nach dem Motto "keep it simple" in eine leere Form mal gezogen und und das Event getestet. Dort funktioniert es wunderbar. Darauf hin habe ich auch im großen Projekt nochmal die Procedure aus dem Objektinspektor und aus der Deklaration gelöscht. Alles kompilieren lassen, so dass die Event-Prozeduren auch wirklich weg waren und dann nochmal neu erzeugen lassen. Jetzt gibt es keine Probleme und das Event wird so erzeugt, wie ich das möchte. Bleibt eigentlich noch nur die Frage: Ist die Auslösung des Events mit OnTischChange (ist die published Variable) oder FOnTischChange (die private Variable)richtig, auf die OnTischChange eigentlich zurück greift? Denke mal FOnTischChange, sonst könnte man die private Variable ja ganz weg lassen, allerdings bin ich da überhaupt nicht sicher.

[Uwe Raabe]

Zitat von BAMatze:

Bleibt eigentlich noch nur die Frage: Ist die Auslösung des Events mit OnTischChange (ist die published Variable) oder FOnTischChange (die private Variable)richtig, auf die OnTischChange eigentlich zurück greift? Denke mal FOnTischChange, sonst könnte man die private Variable ja ganz weg lassen, allerdings bin ich da überhaupt nicht sicher.

Die (meiner Meinung nach) beste Art einen Event auszulösen ist eine eigene Methode (protected oder public), die das erledigt. Da das private Feld FOnTischChange (auf das man sicher nicht verzichten kann, da es den Methodenzeiger speichert!) wäre für abgeleitete Klassen nicht zugänglich - somit könnten diese den Event auch nicht auslösen. Daher:

Delphi-Quellcode:

procedure TTischSteuerung.TischChange;
begin
  if Assigned(FOnTischChange) then FOnTischChange;
end;

[BAMatze]

Das ist schonmal gut zu wissen. Meine Erfahrung besteht ja eigentlich nur daraus, dass ich einige Varianten hier aus der DP genommen hab, die ich gefunden (oder genannt bekommen) habe und dann ausprobiert (wobei meistens noch mindestens so viele Fehler aufgetreten sind, dass ich hier nochmal nachfragen musste). Habe dich jetzt so verstanden, dass ich meine Komponente wie folgt abändern sollte:

Delphi-Quellcode:

Type TTischsteuerung = class(TWinControl)
  private
    ...
    //Variablen für Events
    FOnTischChange: TOnTischChange;
    ...
  protected
    //Events
    // OnTischChange soll dem Programm die Möglichkeit geben alle Eigenschaften auf den
    // ausgewählten Tisch auszurichten.
    property OnTischChange: TOnTischChange read FOnTischChange write FOnTischChange;
    ...
  published
    ...
  public
    //alternativ könnte auch die property OnTischChange hier aufgeführt sein
    ...
end;

// Rest wie am Anfang des Threats, außer dass if assigned(OnTischChange) then OnTischChange; in if assigned(FOnTischChange) then FOnTischChange; geändert wird

[TheReaper]

Zitat von BAMatze:

Das ist schonmal gut zu wissen. Meine Erfahrung besteht ja eigentlich nur daraus, dass ich einige Varianten hier aus der DP genommen hab, die ich gefunden (oder genannt bekommen) habe und dann ausprobiert (wobei meistens noch mindestens so viele Fehler aufgetreten sind, dass ich hier nochmal nachfragen musste). Habe dich jetzt so verstanden, dass ich meine Komponente wie folgt abändern sollte:

Naja, falsch ist es nicht aber auch nicht wirklich richtig. Ich nutze immer eine do-Procedur um events zu triggern. Außerdem sollte Immer der Sender mit angegeben werden.

Delphi-Quellcode:

{$M+}

TOnTischChange = procedure(Sender: TObject) of object;

Type TTischsteuerung = class(TWinControl)
  private
    ...
    //Variablen für Events
    FOnTischChange: TOnTischChange;
    ...
  protected
    // die event auslöser
    procedure doTischChange;    
    ...
  published
    property OnTischChange: TOnTischChange read FOnTischChange write FOnTischChange;
    ...
  public
    //alternativ könnte auch die property OnTischChange hier aufgeführt sein
    ...
end;

procedure TTischsteuerung.doTischChange;
begin
  if Assigned(FOnTischChanged) then
    FOnTischChanged(self);
end;

procedure TTischsteuerung.foo
begin
  ...
  // Event(s) auslösen
  doTischChange;
  ...
end;

Das Ganze sieht erstmal etwas komplizierter aus aber es bringt viele Vorteile beim erweitern oder debuggen. Außerdem macht es Borland genauso.

[Optiplex]

möchte mich mal kurz hier einklinken, hoffe dass ich damit nicht gegen eine Regel verstoße.

warum verwendet ihr
TOnTischChange = procedure(Sender: TObject) of object; für den Event und nicht TNotifyEvent

Danke und Gruß Dieter

[TheReaper]

Zitat von Optiplex:

möchte mich mal kurz hier einklinken, hoffe dass ich damit nicht gegen eine Regel verstoße.

warum verwendet ihr
TOnTischChange = procedure(Sender: TObject) of object; für den Event und nicht TNotifyEvent

Danke und Gruß Dieter

Weil es hier nur um das Prinzip von Events geht und TNotifyEvent und ähnliches steht nicht zum Thema.