Gleiche Variablen-Namen

[Delbor]

Hi zusammen

Zu Beginn: die bewusste Variable ist ein Feld vom Tip TStringlist und hat überall den selben Namen: FPathlist. Da (und solange) es sich dabei um ein privates Feld handelt, ist das im Grunde kein Problem.
Hier feuere ich einen Event und übergebe dabei unter anderem FPathlist:

Delphi-Quellcode:

procedure TPathFinderFrame.FileSearcher1ExecuteComplete(Sender: TObject);
  var LPathlist: TStringlist; LOrdner: String;
begin
  if Assigned(FCurrentNode) then
    FCurrentNode.Expand(false);
  if Assigned(FOnPathListEvent) then
  begin
//    LPathList := TStringlist.Create;
//    LPathList.AddStrings(LPathlist);
//    LOrdner := FOrdner;
    FOnPathListEvent(Sender, FOrdner, FPathlist);
  end;
end;

Die auskommentierten Zeilen zeigen schon meinen Lösungsansatz, indem ich vor dem Abfeuern lokale Variaben einführe. Das Problem zeigt sich beim Empfänger der FPathlist(wenn es denn wirklich eins ist):

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);
end;

Wie der Klassenname der Form schon sagt, handelt es sich hier um eine Testanwendung. Wobei noch sehr simpel ist, was hier geschieht - die übergebenen Werte werden einfach ausgegeben.
Weniger simpel ist (oder scheint mir), was eigentlich geschehen soll: Der Übergabeparameter FPathlist soll an ein privates Feld FPathlist der Form TSQLiteTestMain übergeben werden, also FPathlist wird an FPathlist übergeben. Mich würde erstaunen, wenn dies keine Probleme macht, auch wenn das eine eine Konstante ist, das andere nicht.
Im Gegensatz von Funktionsparametern müssen Eventparameter offenbar nicht nur an der selben Position stehen, sondern auch gleich heissen.
Meine Frage ist also:
Gibt oder kann es Probleme geben, wenn ein Eventparameter an ein gleichnamiges Feld übergeben wird, wie ich vermute?

Gruss
Delbor

[Uwe Raabe]

Probleme gibt es wohl mit der Ownership - sprich, wer gibt die Instanz frei.

Aber warum genau willst du denn den FPathList-Parameter an das lokale Feld übergeben? Was willst du damit bewirken?

[SneakyBagels]

Ich mache das in etwa so

Pseudocode

Delphi-Quellcode:

prozedur1
var
 Variableninstanz Typ
begin
 Variableninstanz erstellen
 prozedur2(variableninstanz)
end

prozedur2 (variableninstanz: Typ = nil)
var
 gebeinstanzfrei Boolean
begin
 gebeinstanzfrei := False
 if variableninstanz = nil 
  begin
   variableninstanz erstellen
   gebeinstanzfrei := True
  end

  .....

  if gebeinstanzfrei then
   variableninstanz.Free
end

Auf diese Art und Weise schicke ich eine bei Programmstart erstellte Variableninstanz von Ini bis an die Stelle an der das Programm komplett geladen ist.
Verwendet wird diese Instanz von einer Hand voll Prozeduren. Eine globale Instanz kommt nicht in Frage, das immer immer neu-erstellen in jeder Prozedur ebenfalls nicht.

[Delbor]

Hi Uwe Raabe

Zitat:

Aber warum genau willst du denn den FPathList-Parameter an das lokale Feld übergeben? Was willst du damit bewirken?

Ich habe mir einen eigenen FileOpenframe (TPathFinderFrame) geschrieben, und der füllt FPathList jeweils mit Dateipfaden, wenn ein Ordner geöffnet wird.
Verarbeitet wird diese Liste allerdings ausserhalb: aus den enthaltenen Pfaden sollen Bilddateien geladen werden und anschliessend in eine SQLite-DB geschrieben werden.

Zitat:

Probleme gibt es wohl mit der Ownership - sprich, wer gibt die Instanz frei.

Die FPathlist-Felder werden jeweils im Frame und in der Mainform erzeugt und auch da zerstört.

Gruss
Delbor

[hoika]

Hallo,

Zitat:

die FPathlist-Felder werden jeweils im Frame und in der Mainform erzeugt und auch da zerstört.

Warum nicht nur im Frame?

[Delbor]

Hi SneakyBagels

Tönt nicht schlecht - auf diese Weise hätte ich genau eine Instanz meiner FPathlist. Allerdings hat das in meinem Fall einen kleinen Haken:
FPathlist übernimmt in meinem PathfinderFrame die von DeddyH'sTFileSearch gefundenen Pfade:

Delphi-Quellcode:

procedure TPathFinderFrame.AddNewNode(ParentNode: TTreeNode; const aCaption,
  aRealName: string; CanGetChildren: Boolean);
var
  Node: TTreeNode;
  NameRec: PNameRec;
begin
  Node := TVPathExplorer.Items.AddChild(ParentNode, aCaption);
  if CanGetChildren then
    begin
      Node.ImageIndex := 1;
      Node.SelectedIndex := 1;
      (* Dummy-Knoten anlegen *)
      TVPathExplorer.Items.AddChild(Node, 'dummy');
    end
  else
    begin
      Node.ImageIndex := 2;
      Node.SelectedIndex := 2;
      FPathlist.Add(aRealName); //<==
    end;
  New(NameRec);
  NameRec^.RealName := aRealName;
  Node.Data := NameRec;
end;

AddNewNode wird das erste mal aus TPathFinderFrame.Create aus aufgerufen, um die Ordner der ersten Ebene darzustellen (Laufwerke). Danach erfolgen die Aufrufe immer aus den Expanding-Events des Treeviews. Denen kann ich die Liste nicht per Aufruf übergeben, da diese per Mousedown ausgelöst werden (wenn der User einen Ordner anklickt). Und bei jedem Klick eine neue Instanz erstellen, dürfte auch nicht wirklich das Wahre sein.

Gruss
Delbor

[SneakyBagels]

Danke für das Lob. Hätte eigentlich gedacht du erschlägst mich wegen dieser zusammengebastelten Lösung welche alles andere ist als OOP.

[Delbor]

Hi Hoika

Zitat:

Zitat:
die FPathlist-Felder werden jeweils im Frame und in der Mainform erzeugt und auch da zerstört.

Zitat:

Warum nicht nur im Frame?

Weil ich dann jeweils von der Mainform aus mit der Framepathlist arbeiten müsste. Da FPathlist ein privates Feld ist, ist dies nicht möglich, ausser ich mache das Feld zu einer Public-Variable.
Klar, ich könnte so aus jeder Unit mit der Framevariable arbeiten. Aber sobald sich in einem Projekt keine PathfinderFrame befindet, muss ich in allen Units, die darauf zugreifen, dies unterbinden - das heisst, ich müsste alle diese Units bearbeiten.

Nach dem Schichtenmodell kann zwar die GUI auf die Logikschicht, zum Beispiel ein Datenmoudul, zugreifen, aber nicht umgekehrt. Das erspart bei Änderungen eine Menge arbeit.

Gruss
Delbor

[DeddyH]

Wenn der FileSearcher und am besten auch die ihm zugewiesenen EventHandler zum Frame gehören, würde ich die Stringliste auch als privates Feld (und ggf. Public ReadOnly-Property) des Frames deklarieren, dann ist alles schön beisammen und man kommt nicht durcheinander.

[Delbor]

Hi SneakyBagels

Zitat:

...wegen dieser zusammengebastelten Lösung welche alles andere ist als OOP.

Grundsätzlich sind lokale Variablen, die mit Prozedur- oder Funktionsaufrufen übergeben werden, absolut OOP-Konform.
Allerdings habe ich deinen Beitrag nicht wirklich ganz verstanden.

Zitat:

Auf diese Art und Weise schicke ich eine bei Programmstart erstellte Variableninstanz von Ini bis an die Stelle an der das Programm komplett geladen ist.

Das heisst also, du deklarierst und erzeugst die Variable in der ProjektUnit noch bevor Mainform.Create aufgerufen wird? Das ist tatsächlich eher ungewöhnlich, aber meines Wissens noch kein Non-OOP.

Zitat:

Verwendet wird diese Instanz von einer Hand voll Prozeduren. Eine globale Instanz kommt nicht in Frage, das immer immer neu-erstellen in jeder Prozedur ebenfalls nicht.

Das habe ich nicht ganz verstanden. Ich verstand das erstmal so, dass du da einen äüsserst gut ausgeklügeltes Aufruf- und Übergabeschema benötigst und allenfalls die Instanz an Prozeduren übergibst, die damit nichts anderes machen, als sie selbst weiterzugeben. Aber auch das ist nicht Non-OOP.
Das Erstellen (und zerstören!) von lokalen Instanzen in einer Prozedur wird in vielen Beispielen angewendet und macht durchaus Sinn, ist aber nicht in jedem Fall Zielführend.

Gruss
Delbor