AW: Gleiche Variablen-Namen
Hi DeddyH
Zitat:
So, wie ich Uwe Raabe aber verstanden habe, kann ich den FPathlist-Parameter des Frames problemlos an das private Feld FPathlist der Mainform zuweisen. Ein vorgehen, dass mich auch in späteren Zeiten beim lesen meines Codes wohl immer etwas irritieren wird. Von daher wäre die Lösung mit dem Property wohl etwas klarer. Gruss Delbor |
AW: Gleiche Variablen-Namen
Also gibt es auch im Mainform eine entsprechende Liste? Dann ist eine 2. Instanz vermutlich Quatsch, da Du mit einer Public (jetzt aber nicht mehr ReadOnly) Property dasselbe erreichen kannst. Ich tippe hier am Tablet, sonst hätte ich mal schnell etwas Beispielcode geschrieben, so ist mir das aber zu mühsam.
|
AW: Gleiche Variablen-Namen
Hallo,
Zitat:
dann bleiben wir beim OOP) die sowohl Main als auch der Frame benutzt. Ansonsten ist das hier mit Kanonen auf Spatzen schießen. Zitat:
|
AW: Gleiche Variablen-Namen
Das ist aber doch keine Raketentechnik.
Delphi-Quellcode:
Jetzt kann das Formular der Frame-Property eine TStrings-Instanz zuweisen, und der nutzt dann diese. Damit gibt es nur eine Instanz, aber beide haben Zugriff darauf.
type
TDingensFrame = class(TFrame) private FPathList: TStrings; ... public property PathList: TStrings read FPathList write FPathList; ... procedure TDingensFrame.SomeEvent(Param: string); begin if Assigned(FPathList) then FPathList.Add(Param); end; |
AW: Gleiche Variablen-Namen
Zitat:
Besser wäre es, du würdest immer nur die Inhalte von einer StringList in die andere kopieren. Dann hast du auch keine Probleme. Möglicherweise musst du dazu aber noch an deiner Programmstruktur basteln. |
AW: Gleiche Variablen-Namen
Hi DeddyH
Zitat:
Diese Procedure wird ausgeführt, wenn der Filesearcher einen Pfad gefunden hat:
Delphi-Quellcode:
Das da gefeuerte Event wird im PathfinderFrame abgefangen:
procedure TSearchThread.DoOnMatchFound;
begin if Assigned(FOnMatchFound) then begin Lock; try FOnMatchFound(self, FPath, FSearchRec); finally UnLock; end; end; end;
Delphi-Quellcode:
Und AddNewNode fügt dem Treeview einen neuen Knoten hinzu sowie FPathlist einen neuen String:
procedure TPathFinderFrame.FileSearcher1MatchFound(Sender: TObject;
const Path: string; const FileInfo: TSearchRec); var Complettpath, J: String; begin if Assigned(FCurrentNode) then begin Complettpath := IncludeTrailingPathDelimiter(Path) + FileInfo.Name; AddNewNode(FCurrentNode, FileInfo.Name, Complettpath,TSearchRecAnalyzer.IsDirectory(FileInfo)); end; end;
Delphi-Quellcode:
In FPathlist stehen abschliessend alle in einem bestimmten Ordner gefundenen Dateien. Ausgelöst wird dder Event, wenn der Filesearcher seine Suche beendet hat:
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;
Delphi-Quellcode:
Der Eventtyp:
procedure TPathFinderFrame.FileSearcher1ExecuteComplete(Sender: TObject);
var LPathlist: TStringlist; LOrdner: String; begin if Assigned(FCurrentNode) then FCurrentNode.Expand(false); if Assigned(FOnPathListEvent) then FOnPathListEvent(Sender, FOrdner, FPathlist); end;
Delphi-Quellcode:
Wenn ich das richtig verstanden habe, müsste ich diesen Event jedesmal, wenn ein Pfad gefunden wird, feuern:
TPathListEvent = procedure(Sender:TObject; const FOrdner: String; const FPathlist: TStringList) of Object;
Delphi-Quellcode:
Dieser Beispielcode erinnert mich allerdings sehr an diese Diskussion.
procedure TDingensFrame.SomeEvent(Param: string);
begin if Assigned(FPathList) then FPathList.Add(Param); end; Damals hatte ich MapRules für eine normale Stringliste gehalten; reichlich spät kam ich dahinter, dass MapRules ene TCollection-Object ist und Add ein TCollectionitem-Objekt zurückliefert. Im Gegensatz dazu ist nun FPathlist wirklich ein TStringlist-Objekt und Add die Methode, die der Liste einen Eintrag hinzufügt. Die Procedur müsste also so ausehen:
Delphi-Quellcode:
Und in TDingensMainForm:
procedure TDingensFrame.SomeEvent(Pfad: string);
begin if Assigned(FPfad) then FPfad(Pfad); end; procedure TDingensMainForm.DoSomeEvent(Pfad: string); begin Self.FPathlist.Add(Pfad); end; Das Problem, das ich da sehe, ist: woher weiss ich nun, wann der TDingensframe keine Pfade mehr sendet? Einfach nur zuzuwarten, ob innerhab einer gewissen Zeit noch was kommt, scheint mir sehr zweifelhaft. Gruss Delbor |
AW: Gleiche Variablen-Namen
Hi Uwe Raabe
Zitat:
Genau das hat aber meine Frage veranlasst. Zur Erinnerung: Meine bisherige Prozedur gibt die Liste direkt aus, ohne sie in einem Feld zwischenzuspeichern:
Delphi-Quellcode:
Stattdessen soll nun der übergebene KonstantenParameter FPathlist an das private Feld TSQLiteTestMain.FPathlist übergeben werden. Das würde nach meinen bisherigen Vorstellungen etwa so ausehen:
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;
Delphi-Quellcode:
Und genau das dürfte unmöglich sein. Es sei denn...:
procedure TSQLiteTestMain.DoPathListEvent(Sender: TObject;
const FOrdner: String; const FPathlist: TStringList); begin FPathlist.AddStrings(FPathlist); end;
Delphi-Quellcode:
Allerdings müsste so auch der Eventtyp angepasst werden: Statt
procedure TSQLiteTestMain.DoPathListEvent(Sender: TObject;
const FOrdner: String; const FPathlist: TStringList); begin Self.FPathlist.AddStrings(PathFinderFrame.FPathlist); end;
Delphi-Quellcode:
müsste dies heissen:
TPathListEvent = procedure(Sender:TObject; const FOrdner: String; const FPathlist: TStringList) of Object;
Delphi-Quellcode:
Allerdings - ob sowas überhaupt möglich ist, ist mir nicht bekannt; ich denke eher nicht.
TPathListEvent = procedure(Sender:TObject; const FOrdner: String; const PathFinderFrame.FPathlist: TStringList) of Object;
Wobei dann tatsächlich mein erster ansatz übrig bliebe:
Delphi-Quellcode:
und in der Mainform:
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; try LPathList.AddStrings(FPathlist); LOrdner := FOrdner; FOnPathListEvent(Sender, FOrdner, LPathlist); finally LPathList.Free; end; end; end;
Delphi-Quellcode:
Gruss
procedure TSQLiteTestMain.DoPathListEvent(Sender: TObject;
const FOrdner: String; const LPathlist: TStringList); begin FPathlist.AddStrings(LPathlist); end; Delbor |
AW: Gleiche Variablen-Namen
Und was spricht gegen dies?
Delphi-Quellcode:
procedure TSQLiteTestMain.DoPathListEvent(Sender: TObject;
const FOrdner: String; const FPathlist: TStringList); begin Self.FPathlist.Assign(FPathlist); end; |
AW: Gleiche Variablen-Namen
Jetzt muss ich aber mal nachhaken: wo genau wird diese Liste benötigt/angezeigt?
|
AW: Gleiche Variablen-Namen
So wie ich das verstehe, wird die Liste im Mainform angzeigt.
Ich würde das so lösen (Code frei getippt):
Delphi-Quellcode:
Bei der Suche selbst, innerhalb des Frames, wird die Stringliste erweitert. Beim Complete wird einfach das Event gefeuert und so dem Hauptformular bescheid gegeben, das die Liste neu ist. Anhand der Liste kann dann der Treeview entsprechend angezeigt werden.
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; Eine Instanz der Stringliste und eine Übergabe ist nicht notwendig. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 23:35 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz