findFirst systemabhängig??

[negaH]

*.* ist absolut richtig gewesen. Ein * für den Dateinamen, ein Komma . zur Trennung zur Extension, und ein * für die Extenstion/Erweiterung einer Datei.

Gruß Hagen

[Martin K]

Zitat:

Zitat von negaH

*.* ist absolut richtig gewesen. Ein * für den Dateinamen, ein Komma . zur Trennung zur Extension, und ein * für die Extenstion/Erweiterung einer Datei.

Gruß Hagen

Ja, aber hier geht es doch um Ordner :shock: , nicht um Dateinamen.
Theoretisch dürfte er dann nur nach Ordnern suchen, die einen . Punkt im Namen enthalten.
Aber praktisch erhält man so trotzdem alle Ordner...

[negaH]

Die Trennung eines Dateinamens, egal ob Datei oder Ordner, ist immer Name.Extension

Ich sagte ja schon das dein ehemaliger Source absolut sauber und perfekt ist, dh. eine Suchschleife für FindFirst(), FindNext() und FindClose() sollte exakt so aufgebaut sein wie dein Source.

1.) FindClose() in try finally
2.) FindClose() nur dann wenn FindFirst() was findet -> wichtig! für ältere Delphi RTLs
3.) die Abfrage auf Directory zuerst Attr per and auswerten, danach SR.Name <> '.' und danach erst SR.Name <> '..' das erzeugt den effizientesten Code, diese Reihenfolge der Auswertung ist also entscheidend und so wie du das gemacht hast ist es am effizientesten.

Sehr oft sieht man Auswertungen wie SR.Name[1] <> '.' oder Pos('.', SR.Name) > 0, diese sind jedoch defakto falsch. Odner könnten auch ".Name" oder "Name.Name" benannt sein. Oder man sieht sowas wie SR.Attr <> faDirectory was ebenfalls falsch ist. Denn damit würde man Directories mit Attr = faDirectory or faHidden, also versteckte Ordner eben nicht ausfiltern. Auch sehr oft zu sehen SR.Attr < 0, das geht weil faDirectory glaube ich das Signbit darstellt, ist aber denoch falsch da diese Auswertung vom Datentyp SR.Attr abhängig ist. Sollte dies ein Word/Cardinal sein so wäre SR.Attr < 0 ebenfalls absolut falsch. Wie gesagt, so wie du das gemacht hast ist es die beste Lösung.


Gruß Hagen

[Martin K]

Also erstmal Danke für Deine Komplimente, aber ich habe den Code mir irgendwann auch mal aus versch. Beiträgen hier im Forum zusammengebastelt.

Zitat:

Zitat von negaH

Die Trennung eines Dateinamens, egal ob Datei oder Ordner, ist immer Name.Extension

Das kann ich nicht so stehen lassen, da ein Ordner keine Extension hat.
Es gibt sogar Dateien, die keine haben
:arrow: also kein . im Dateinamen / Ordnernamen!
Wieso deshalb nach einem . suchen?
Aber dazu hat ja SirThornberry schon was geschrieben...

Zitat:

Zitat von negaH

Sehr oft sieht man Auswertungen wie SR.Name[1] <> '.' oder Pos('.', SR.Name) > 0, diese sind jedoch defakto falsch. Odner könnten auch ".Name" oder "Name.Name" benannt sein.

Genau wie hier (erster Beitrag):

Zitat:

Zitat von hackyie

Delphi-Quellcode:

if pos('.',SearchRec.Name) = 0 then

Deshalt schrieb ich ja auch:

Zitat:

Zitat von Martin K

Ein Ordner kann auch einen Punkt im Namen enthalten!

:wink:

[sakura]

Zitat:

Zitat von Martin K

Das kann ich nicht so stehen lassen, da ein Ordner keine Extension hat.

Oh, da merkt man wie alt man ist :mrgreen: Windows unterstütz auch heute noch das 8.3 Namesprinzip, FindFirst & Co. auch und im 8.3 System hatte jede Datei und jeder Ordner 8 Zeichen für den Namen und 3 für die Erweiterung. Fakt ist jedoch, dass gerade bei Ordner meistens auf eine Angabe für die Erweiterung verzichtet wurde.

Wenn eine Datei bzw. ein Ordner nicht alle 8 bzw. 3 Zeichen genutzt hatte, so hat das OS die betreffenden Stellen in der FAT mit #32 aufgefüllt und "unterstützte" somit auch Datei-/Ordnernamen mit weniger als 8 Zeichen vorn bzw. 3 hinten.

Zitat:

Zitat von Martin K

Es gibt sogar Dateien, die keine haben

So gibt es auch Ordner die eine Erweiterung haben ;)

Zitat:

Zitat von Martin K

:arrow: also kein . im Dateinamen / Ordnernamen!

Die Suche von FindNext findet auch Dateien/Ordner ohne Erweiterung, wenn man nach *.* sucht, da dieses die feste Maske für alles ist. Egal ob mit oder ohne Erweiterung.

...:cat:...

[Martin K]

Zitat:

Zitat von sakura

Die Suche von FindNext findet auch Dateien/Ordner ohne Erweiterung, wenn man nach *.* sucht, da dieses die feste Maske für alles ist. Egal ob mit oder ohne Erweiterung.

Trotzdem ist es irgnedwie logischer, nur nach * zu suchen, v.a. wenn es sich um Ordner handelt.
...außerdem ist es weniger Schreibarbeit und die pas wird 2 Byte kleiner :zwinker:

Mir ist allerdings nicht klar, was Ordner für Extensions haben könnten...
Hab grad in meinem Windows-Verzeichnis einen Ordner gefunden, der Microsoft.NET heißt.
Aber ist deswegen jetzt die Extension .NET ???

[fwsp]

es gibt doch das märchen, dass ordner die endung ".dir" hätten...

[sakura]

Zitat:

Zitat von fwsp

es gibt doch das märchen, dass ordner die endung ".dir" hätten...

Es ist halt ein Märchen ;)

...:cat:...

[sakura]

Zitat:

Zitat von Martin K

Mir ist allerdings nicht klar, was Ordner für Extensions haben könnten...
Hab grad in meinem Windows-Verzeichnis einen Ordner gefunden, der Microsoft.NET heißt.
Aber ist deswegen jetzt die Extension .NET ???

Wie auch bei Dateien, wird nach der 8.3 Konvention wie folgend für die Extension vorgegangen: die ersten drei legalen Zeichen nach dem letzten Punkt werden zur Extension. Also wird aus dem Ordner Microsoft.NET sehr wahrscheinlich MICROS~1.NET, wobei "~1" auch andere Werte annehmen kann, um Namenskollisionen zu vermeiden.

...:cat:...

[negaH]

Zitat:

Zitat:

negaH hat folgendes geschrieben:
Die Trennung eines Dateinamens, egal ob Datei oder Ordner, ist immer Name.Extension

Das kann ich nicht so stehen lassen, da ein Ordner keine Extension hat.

Du musst es so stehen lassen, weil es richtig ist. Ein Ordner kann eine Extension besitzen, punkt.

Öffne die Eingabeaufforderung->DOS Box und geben ein "md Test.XYZ" und schaue dir im Explorer den erzeugten Ornder an. Nun suchst du mit deinem Source -> FindFirst('*.XYZ', faDirectory, SR) und wirst diesen Ordner auch finden.

Gruß Hagen