Gleiche Variablen-Namen

[Delbor]

Hi zusammen

Vielen Dank, Uwe Raabe. An sowas habe ich weniger gedacht, da es mir zu wenig klar erschien. Aber klar - Self.FPathlist kann unmöglich der Parameter sein, womit klar wäre, welche der beiden Variablen an welche zugewiesen und von wem gelöscht wird.
Ohne die klare Adressierung mindestens der einen Variablen ist ja auch nicht wirklich klar, wer wem zugewiesen wird.

@DeddyH: FPathlist sammelt im PathfinderFrame die vom Filesearcher gefundenen Pfade. Hier im Test wird diese Liste von der Mainform abgearbeitet, soll aber in einem Datenmodul eingesetzt werden, um Daten - in diesem Fall Bilder - von der Festplatte in eine DB zu schreiben.

Den Pathfinderframe hatte ich ursrünglich unter dem Namen OpenfileDialog, bzw. OpenFileFrame entwickelt. Dieses Ding hat nur den grossen Fehler, dass es ausser gefundene Files anzuzeigen, auch noch andere, programmspezifische, Aufgaben erledigt. Allgemein sind da ddie Zugriffe des Frames und anderer Projektteile nicht sauber geregelt.
Na ja, das Ding hat schon einige Jährchen auf dem Buckel...

Gruss
Delbor

[DeddyH]

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

[Ghostwalker]

@DeddyH

Jap...deshalb ja auch mein Lösungsansatz.

[Sherlock]

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

Ansonsten, schließe ich mich immer Uwe Raabes Meinung an...

Sherlock

[Delbor]

Hi Ghostwalker
Ja, danke. Daran habe ich auch schon gedacht, mich dann aber für dieses Vorgehen entschieden, da ich ja auch noch ein Feld FOrdner habe, in dem der Name des Parentfolders enthält.

Zitat:

Die Sache mit dem Property habe ich mir auch überlegt. Einen Event müsste ich vom Frame aus aber so oder so abfeuern, da die Mainform ja nicht wissen kann, wann der PathfinderFrame die Liste (und damit das Listenproperty) neu bestückt. Das würde dann heissen, dass ich vom Frame aus einen TNotifierEvent abfeuere, den die Mainform empfängt und dabei dann das Listen-Property des Frames ausliest.

Klar könnte dieser Name aus einem Dateipfad herausgefiltert werden. Für die jetzige Vorgehensweise habe ich mich entschieden, weil Teile dieses Namens als DBName verwendet werden sollen. Und um nun alle Klarheiten zu beseitigen:
Ziel ist es, eine eingebettete SQLite-DB zu erstellen, die gerade mal eine Tabelle enthält,die ihrerseits nur einige wenige Felder aufweist. Die Aufgabe dieser DB wird es sein, RAWBild-Dateien und davon erstellte Bitmaps zu speichern. Diese DB soll auch Auskunft darüber geben, ob das Bitmap schon bearbeitet wurde.
Im Produktiveinsatz werden aus den RAW-Bildern nebst Bitmaps auch Thumbnails erstellt. Diese werden in meiner BilderDB (12 Tabellen, MySQL) gespeichert.

Gruss
Delbor

[Delbor]

Hi zusammen

@DeddyH:

Zitat:

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

@Ghostwalker:

Zitat:

@DeddyH

Jap...deshalb ja auch mein Lösungsansatz.

Wenn Mainform (oder Datenmodul) einerseits und der Pathfinderframe andrerseits ihre eigene Instanz haben, sind die beiden voneinander unabhängig - sollte sich irgendwas in einer der beiden ändern, muss ich nicht mehrere Stellen bearbeiten, sondern nur diejenige, in der ein Event abgefangen wird.
Aber jetzt fällt mir auf:

Delphi-Quellcode:

   TOnComplete = TNotifyEvent;

   TPathfinderframe = Class...
   private
      fpathlist : TStringlist;
      fonComplete : TOnComplete;
     :
   published
     Property Pathlist : TStringlist read fpathlist write fpathlist;
     Property onComplete: TOnComplete read fonComplete write foncomplete;
     :
   end;

Durch das Property Pathlist lässt sich in einer Mainform oder einem Datenmodul genauso iterieren wie durch eine private Liste. Das widerspricht einzig etwas dem Schichtenmodell, wonach zwar die GUI (PathFinderFrame, Mainform) nach unten (Datenmodul) zugreifen sollen, nicht aber umgekehrt. Technisch ist es durchaus möglich.

Gruss
Delbor

[Delbor]

Hi zusammen

Eben hab ich versucht, Uwe Raabes Vorschlag umzusetzen. Der Empfänger des Events befindet sich bislang in der Mainform, und so wolllte ich ihn ins Datenmodul verlegen. Dazu kopierte ich die Prozedur in der Mainform, fügte sie im Datenmodul ein und liess sie per Shift/Control/C deklarieren. Anschliessend versuchte ich, die Variable FPathlist per Refactoring als privates Feld deklarieren zu lassen.
Da hat Delphi aber ganz schön gemeckert! Wie, das zeigt der Anhang.

Ich habe dann mal versucht, das Feld von Hand zu deklarieren. Das schien OK. So hab ich in der Empfängerprozedur einen Haltepunkt gesetzt. Aber als ich von da weitersteppen wollte, meckerte Delphi Gleich zweimal:

Zitat:

---------------------------
Im Projekt SQLiteTestProject.exe ist eine Exception der Klasse $C0000005 mit der Meldung 'access violation at 0x007e007d: read of address 0x0000007c' aufgetreten.
---------------------------

Und das 2. Mal beim weitersteppen mit F8:

Zitat:

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

FPathlist des Datenmoduls kann die AV nicht auslösen - die wird bei Datenmodul.Create erstellt. Und der Konstantenparameter FPathlist ist auch gut gefüllt. Weitere Objekte werden in der Prozedur nicht angesprochen:

Delphi-Quellcode:

procedure TDMLSQLite.DoPathListEvent(Sender: TObject;
  const FOrdner: String; const FPathlist: TStringList);
begin

  Self.FPathlist.Assign(FPathlist);
end;

So, wie ich das jetzt sehe, bleiben also 2 Lösungen:

• Ich erstelle kurz vor dem Abfeuern des Events eine lokale Stringliste, gebe die dem Event mit und zerstöre sie bei Rückkehr wieder oder
• Ich setze die Propertylösung ein und feuere einen TNotifier, wenn die Liste frisch gefüllt worden ist.

Gruss
Delbor

[bra]

Zitat von Delbor:

Delphi-Quellcode:

procedure TDMLSQLite.DoPathListEvent(Sender: TObject;
  const FOrdner: String; const FPathlist: TStringList);
begin

  Self.FPathlist.Assign(FPathlist);
end;

Private Variablen und Parameter mit demselben Namen, so etwas ist tückisch ohne Ende (wie auch schon erwähnt). Du solltest dir angewöhnen, Funktionsparamater anders zu benennen, die gängige Konvention ist "AName". Dann brauchst du auch den Self-Mist nicht.

Delphi-Quellcode:

class TDMLSQLite = ...
 private
   FPathlist: TStringList;
end;

procedure TDMLSQLite.DoPathListEvent(Sender: TObject; const AOrdner: String; const APathlist: TStringList);
var
  Pathlist: TStringList
begin
  FPathlist.Assign(APathlist);
end;

[DeddyH]

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.

[Uwe Raabe]

Zitat von DeddyH:

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.

Du sprichst mir aus der Seele.