Gleiche Variablen-Namen

[Delbor]

Hi zusammen
@DeddyH:

Zitat:

Vielleicht wäre es zielführender, Delphi erstmal links liegen zu lassen, Dich mit Bleistift und Papier hinzusetzen und einmal genau zu planen, wer was erzeugen/freigeben soll und wer worauf Zugriff haben muss. Ansonsten verschlimmbesserst Du Dein Programm am Ende immer weiter, bis gar nichts mehr funktioniert.

Sorry, aber Papier und Bleistift meckern nicht. Wenn ich also was ungewöhnliches umsetzen will, schreibe ich kleine Testprogramme, die einen Bruchteil dessen tun,was im eigentlichen Programm getan werden soll. Auf diese Weise merke ich dann relativ schnell, ob etwas geht oder nicht.
Klar, ich hätte von Anfang an sehen können: Da sind zwei gleichnamige Variablen, die einander zugewiesen werden sollen. Mein Ansatz war ja, vor dem Abfeuern des Events eine weitere Stringliste anderen Namens zu erzeugen und die dann an die Datenmodul.Stringliste zuzuweisen.
Nur hätte ich dann für den gleichen Inhalt nicht nur 2 Instanzen der Liste gehabt, sondern temporär deren drei.

@bra:

Zitat:

Du solltest dir angewöhnen, Funktionsparamater anders zu benennen, die gängige Konvention ist "AName". Dann brauchst du auch den Self-Mist nicht.

Muss ich nicht, da ich es schon mache. Nur: bei Events ist das nicht möglich. Da muss der im Empfänger übergebene Parameter auch genau so heissen, wie der des Senders. Also:
Der Sender:

Delphi-Quellcode:

  if Assigned(FOnPathListEvent) then
    FOnPathListEvent(Sender, FOrdner, FPathlist);

und der Empfänger:

Delphi-Quellcode:

procedure TSQLiteTestMain.DoPathListEvent(Sender: TObject;
  const FOrdner: String; const FPathlist: TStringList);
begin
  Self.EdiFolder.Clear;
  Self.EdiFolder.Text := FOrdner;
  Self.LBxPathlist.Clear;
  Self.LBxPathlist.Items.AddStrings(FPathlist);
//  Self.FPathlist.Assign(FPathlist);
end;

Das erste, was ich versucht habe, war eben hier den Konstantenparameter anders zu benennen. Delphi meckerte das als unterschiedliche Deklaration an. Während ich dies schreibe, fällt mir auf, dass ich nicht versucht habe, die Liste nicht als Konstante zu übergeben. Aber das ändert an der Unterschiedlichen Deklaration nichts.
Wobei FPathList im PathfinderFrame zum Bleistift FFileList sein könnte. So sollte sich eine Kollision bei der Übergabe vermeiden lassen.

Gruss
Delbor

[Uwe Raabe]

Zitat von Delbor:

Nur: bei Events ist das nicht möglich. Da muss der im Empfänger übergebene Parameter auch genau so heissen, wie der des Senders.

Entschuldige, aber das ist Blödsinn! Die Deklaration eines Events ist die Stelle, an der die Parameternamen festgelegt werden. Da ist es vollkommen egal, ob der Parameter nun FPathList, APathList oder Hurz heißt. Wenn dir das FPathList nicht gefällt, dann benenne ihn einfach um. Das muss natürlich synchron im interface und implementation Teil geschehen.

Da die F-Notation schon von Feldern besetzt ist, bietet sich bei Parametern die A-Notation an - ist aber immer noch Geschmackssache.

[Jumpy]

Zitat von Delbor:

Das erste, was ich versucht habe, war eben hier den Konstantenparameter anders zu benennen. Delphi meckerte das als unterschiedliche Deklaration an.

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

[Sherlock]

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

Sherlock

[haentschman]

[OT]

Patient: Alle ignorieren mich! Arzt: Der nächste bitte...

Willkommen im Club.
[/OT]

Zitat:

Und wozu brauchst Du dann eine 2. Instanz? Ich habe immer öfter den Eindruck, Du machst es Dir unnötig schwer.

...das denke auch.

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

[Aviator]

Zitat von Delbor:

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

Damit das jetzt nicht missverstanden wird, mache ich mal ein etwas ausführlicheres Beispiel:

Delphi-Quellcode:

type
  // Deklaration des Events
  TMyEvent = procedure(Street: string; Country: string) of object;
  
  TMyClass = class
  private
    FOnReport: TMyEvent;
  public
    procedure DoSomethingAndReport();
    property OnReport: TMyEvent read FOnReport write FOnReport;
  end;
  
  TForm1 = class(TForm)
  private
    procedure ReportHandler(Street: string; Country: string);
  end;
  
  
 implementation
 
 procedure TMyClass.DoSomethingAndReport();
 var
   tmpStreet, tmpCountry: string;
 begin
   tmpStreet := GetStreet();  // Irgendeine Methode ausführen
   tmpStreet := GetCountry(); // Irgendeine Methode ausführen
   
   if Assigned(FOnReport) then
     FOnReport(tmpStreet, tmpCountry);  // Hier wird das Event ausgelöst
 end;
 
 
 // EventHandler für TMyClass.OnReport
 // Hier könnten die Parameter Bezeichner sogar schon von der Event-Deklaration abweichen
 // Wichtig sind die Datentypen. Die müssen in Reihenfolge und Typ mit der Event-Deklaration übereinstimmen
 procedure TForm1.ReportHandler(Street: string; Country: string);
 begin
   ShowMessage(Street + sLineBreak + Country);
 end;