Hallo Martin,
Zitat von
marteng57:
das Problem ist gelöst, auch wenn ich nicht mehr ganz genau sagen kann, auf welchem Wege.
Es war wohl eine Kombination aus benötigtem passive Modus, firewall und ....
Das freut mich, siehste: War doch nicht das
Indy FTP.List
Zitat von
marteng57:
idfp.list funktioniert im Übrigen sowohl mit TStrings als auch mit Tstringlist.
Nur wenn das Ergebnis über ListResult abgeholt wird ist TStrings zwingend.
Dafür scheint die überladene Definition von List mit Filter und Details nicht zu greifen, es kommt immer das Gesamtergebnis. Aber das ist nicht schlimm, ich kann es ja nachher filtern.
Das verstehe ich nicht.
IdFTP.List() gibt es in 3 Varianten:
1) procedure TIdFTP.List;
2) procedure TIdFTP.List(const ASpecifier: string; ADetails: Boolean);
3) procedure TIdFTP.List(ADest: TStrings; const ASpecifier: string = ''; ADetails: Boolean = True);
bei 1) und 2) laden die Resultate in IdFTP.ListResult und bei 3) in Deinem eigenen TStrings-Nachfahren. ADetails steuert nur, ob z.B. die Verzeichnis/Gruppenrechte ausgelesen werden.
Wenn hier trotzdem Details kommen, muß da von uns geprüft werden. Das könnte ein Bug sein.
Für das korrekte Parsing der Liste (es gibt ja viele
FTP Server die beim Listenresult abweichen) immer wie oben erwähnt die IdAllFTPListParsers einbinden. Dann werden entsprechende Behandlungen für VMS & Co eingebunden.
Zu den TStrings/StringList, aus der englischen D2009
OH:
Zitat:
Derive a class from TStrings to store and manipulate a list of strings. TStrings contains abstract or, in C++ terminology, pure virtual methods and should not be directly instantiated.
Wir verwenden also - wie eigentlich alle Komponentenentwickler - TStrings, damit der Benutzer die Rückgabe mit TStringList und anderen Nachfahren nutzen kann.
Roter Kasten: SirThornberry war schneller
Gruß Assertor