Gleiche Variablen-Namen

[Delbor]

Hi zusammen

@ Jumpy

Zitat:

Das heißt eigentlich nur, das du es im Interface-Teil anders deklarierst als im Implementaion-Teil!

Ups - da hab ich jetzt nicht daran gedacht!
Ich habe mich hierauf gestützt - von Namensgleicheit ist hier nicht die Rede.
Ein Zitat daraus:

Zitat:

In beiden Fällen müssen im Aufruf Parameter übergeben werden, die in der Reihenfolge und im Typ den in der Parameterliste der Routine angegeben Parametern entsprechen

Also müsste der Zielparameter an z.B. erster Stelle vom Typ des Quellparameters sein, auch wenn er anders heisst.

Als ich versuchte, den Namen des übergeben Listen-Parameters zu ändern und Delphi meckerte wegen unterschiedlicher Deklaration, dachte ich allerdings an die Deklaration des Events und nicht an diejenige der Empfängerroutine. Und da müssen in der Deklaration und in der Implementierung nicht nur Reihenfolge und Tip stimmen, sondern auch die Parameterbezeichner.

@Uwe Raabe

Zitat:

Entschuldige, aber das ist Blödsinn! Die Deklaration eines Events ist die Stelle, an der die Parameternamen festgelegt werden.

Sorry, aber ich fürchte, du hast mich fallsch verstanden. Um es mal anders auszudrücken:

Delphi-Quellcode:

procedure Tfoo.xxx
begin
  GetNamen(Strasse, Hausnummer)
end

function Getnamen(Street, Number)
Begin
  End
End;

Natürlich müssen die Deklarationen jeder der beiden Methoden dabei gleich lauten und die Reihenfolge und Typen der Parameter übereinstimmen.

Interessant ist jetzt: Im Datenmodul Heisst die Liste jetzt anders. Trotzdem gibts die beiden schon gepostetn Fehlermeldungen. Andrerseits funktioniert folgendes problemlos:

Delphi-Quellcode:

procedure TDMLSQLite.DoPathListEvent(Sender: TObject;
  const FOrdner: String; const FPathlist: TStringList);
begin
//  FFileList.AddStrings (FPathlist);   //<<=== löst die bekannten Fehlermeldungen aus
  SQLiteTestMain.LBxPathlist.Items.AddStrings(FPathlist);   //<<== Kein Problem
end;

@Sherlock:

Zitat:

Auf mich will ja keiner hören... seufz.

Ich guck mir deinen Beitrag gleich nochmal an!

Gruss
Delbor

[haentschman]

Hallöle...

Zitat:

Entschuldige, aber das ist Blödsinn! Die Deklaration eines Events ist die Stelle, an der die Parameternamen festgelegt werden.

...was Uwe meint ist, das der Name Schall und Rauch ist. Der kann meinetwegen auch MeinGelbesBlubb heißen. Wichtig ist der Inhalt.
Schreib mal die Eventdeklaration.

[Delbor]

Hi Sherlock

Zitat:

Ich schieße mal kurz unsachlich dazwischen: Wenn Du schon so einen Namen wie FPathList für ein Feld wählst, warum nicht auch aPathList für ein Argument? Zumindest wäre dann die Namensverwirrung im Titel sinnvoll aufgelöst

Der Grund ist:
Nenne ich den übergebenen ListenParameter im Empfänger AList, muss er auch bei der Eventdeklaration so heissen. Ich habe im Frame die Deklaration der Liste mal probeweise nach Public verschoben. Das hatte jedoch keine Auswirkungen - wenn, dann hätte ich erwartet, dass von den angesprochenen 2 Fehlermeldungen eine ausbleibt.

Gruss
Delbor

[haentschman]

Zitat:

Nenne ich den übergebenen ListenParameter im Empfänger AList, muss er auch bei der Eventdeklaration so heissen.

...korrekt.

Über welche Fehlermeldungen reden wir? Screenshot.

[Delbor]

Hi Haentschman
Die ist:
TPathListEvent = procedure(Sender:TObject; const FOrdner: String; const FPathlist: TStringList) of Object; Und wie gesagt: eine Gui-Ausgabe funktioniert nach wie vor tadellos. Entweder; es liegt an der Empfängermethode oder schlicht daran, dass ich versuche, Objekte zu übergeben.

Gruss
Delbor

[haentschman]

Fehlermeldung?

IST Stand:
Event:

Delphi-Quellcode:

TPathListEvent = procedure(Sender:TObject; const FOrdner: String; const FPathlist: TStringList) of Object;
.

EventHandler: ?
Auslösen des Events: ?

siehe Beispiel Aviator...http://www.delphipraxis.net/1370782-post40.html

[Delbor]

Hi Heantschman

Ups! ich dachte, ich hätte die monströsen Dinger schon gepostet, konnte sie allerdings jetzt gerade nicht wiederfinden. Die sind:
---------------------------
Benachrichtigung über Debugger-Exception
---------------------------
Im Projekt SQLiteTestProject.exe ist eine Exception der Klasse $C0000005 mit der Meldung 'access violation at 0x007e007d: read of address 0x0000007c' aufgetreten.
---------------------------
und
---------------------------
Im Projekt SQLiteTestProject.exe ist eine Exception der Klasse EAccessViolation mit der Meldung 'Zugriffsverletzung bei Adresse 007E007D in Modul 'SQLiteTestProject.exe'. Lesen von Adresse 0000007C' aufgetreten.
---------------------------
Anhalten Fortsetzen Hilfe
---------------------------

Ich hab in der Zeile, in der die Zuweisung stattfindet, einen Haltepunkt, die erste Fehlermeldung erscheint, wennn ich mit F8 weiterzusteppen versuche, und die zweite, wenn ich die erste mit Fortsetzen weggeklickt habe.

Gruss
Delbor

[Delbor]

Hi Haentschman

Der Auslöser des Events ist, wenn der Filesearcher seine Dateisuche beendet hat:

Delphi-Quellcode:

procedure TPathFinderFrame.FileSearcher1ExecuteComplete(Sender: TObject);
begin
  if Assigned(FCurrentNode) then
    FCurrentNode.Expand(false);
  if Assigned(FOnPathListEvent) then
    FOnPathListEvent(Sender, FOrdner, FPathlist);
end;

Der Eventhandler:

Delphi-Quellcode:

procedure TDMLSQLite.DoPathListEvent(Sender: TObject;
  const FOrdner: String; const FPathlist: TStringList);
begin
//  FFileList.AddStrings (FPathlist);
  SQLiteTestMain.LBxPathlist.Items.AddStrings(FPathlist);
end;

Gruss
Delbor

[haentschman]

Hänge das Testprojekt mal an... Bevor wir weiter raten.

Ich tippe darauf das beim Absenden des Events FPathlist: TStringList (das F kommt aus dem Original) nil (0x0000007c) ist.

Wo erzeugst du die FPathlist: TStringList Instanz?

[Aviator]

Zitat von haentschman:

Ich tippe darauf das beim Absenden des Events FPathlist: TStringList (das F kommt aus dem Original) nil (0x0000007c) ist.

Wenn das Objekt nil ist, dann wäre die Adresse eher 0x00000000. Ich kann mich aber auch täuschen. Nur kenne ich es nur so, dass die Adresse dann 0x00000000 wäre.

EDIT: @Delbor: Hast du meinen Post #40 gesehen. Dort habe ich mal ein Minimalbeispiel gemacht, wie so ein Event erstellt werden kann.