Filterfehler bei FileListBox

[KodeZwerg]

Zitat:

Zitat von Delphi.Narium (Beitrag 1485502)

Hab's gerade mal mit Delphi 7 ausprobiert.

Der "Fehler" liegt nicht in der TFileListBox, sondern im in der

Delphi-Quellcode:

procedure TFileListBox.ReadFileNames

genutzten FindFirst. Kann man mit 'ner einfachen Routine testen:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  sr : TSearchRec;
begin
  if FindFirst('c:\temp\*.mmp',faAnyFile,sr) = 0 then begin
    ShowMessage(sr.Name
             + #13#13
             + sr.FindData.cAlternateFileName
             + #13#13
             + sr.FindData.cFileName);
  end;
end;

Es werden auch die Dateien mit der Endung mmpz gefunden.

Dies gilt analog auch für beliebige andere Dateiendungen, sofern sie länger als drei Zeichen sind, das ist dann wohl der alten Namenskonvention aus DOS-Zeiten von 8.3 geschuldet.
Oder anders formuliert: FindFirst sucht nach den kurzen Dateinamen (TSeachRec.FindData.cAlternateFileName), wie man sie in der Kommandozeile z. B. mit

Delphi-Quellcode:

dir /x

angezeigt bekommt. zu dem so gefundenen werden dann die langen Dateinamen in

Delphi-Quellcode:

TSearchRec.Name

bzw.

Delphi-Quellcode:

TSearchRech.FindData.cFileName

geliefert.
Die Arbeitsweise ist also "korrekt", wenn auch nicht mehr unbedingt zeitgemäß ;-)

Danke für diese Erkenntnis!
Aufbauend auf diesen Gedanken hier ein neues Snippet.
Deklarationen:
edPath.Text = ein gültiger pfad mit \ am ende, beispielsweise "C:\Test\"
edMask.Text = volle Maske, Beispiel "*.mm"

Es wird komplett auf diese veralteten Win3.1 Komponenten verzichtet.

Delphi-Quellcode:

type
  TForm3 = class(TForm)
    edPath: TEdit;
    edMask: TEdit;
    lbFiles: TListBox;
    btnStart: TButton;
    procedure btnStartClick(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  Form3: TForm3;

implementation

{$R *.dfm}

procedure TForm3.btnStartClick(Sender: TObject);
const
  FIND_FIRST_EX_LARGE_FETCH = 2;
var
  SL: TStringList;
  hFile: THandle;
  FindData: WIN32_FIND_DATA;
begin
  SL := TStringList.Create;
  try
    hFile := FindFirstFileEx(PChar(edPath.Text + edMask.Text), FindExInfoBasic, @FindData, FindExSearchNameMatch, nil, FIND_FIRST_EX_LARGE_FETCH);
    if hFile <> INVALID_HANDLE_VALUE then
      begin
        repeat
          if (((FindData.dwFileAttributes and FILE_ATTRIBUTE_DIRECTORY) = 0) and (FindData.cFileName <> string('.')) and (FindData.cFileName <> string('..'))) then
            begin
              SL.Add(FindData.cFileName);
            end;
        until (not FindNextFile(hFile, FindData));
      end;
    Winapi.Windows.FindClose(hFile);
    lbFiles.Items.BeginUpdate;
    lbFiles.Clear;
    lbFiles.Items := SL;
    lbFiles.Items.EndUpdate;
  finally
    SL.Free;
  end;
end;

end.

Im Anhang ein Bild als Beweis was da raus kommt.

ggf PChar mit PWideChar ersetzen?

[himitsu]

Zitat:

Es wird komplett auf diese veralteten Win3.1 Komponenten verzichtet.

Es gibt auch noch den ShellListView
oder die Shell-Erweiterung für den VirtualTreeView.

[KodeZwerg]

Zitat:

Zitat von himitsu (Beitrag 1485518)

Es gibt auch noch den ShellListView
oder die Shell-Erweiterung für den VirtualTreeView.

Mir war nicht bewusst das es diese Komponenten für Delphi 3 / 5 gibt.
Ich mag es lieber unter voller Kontrolle zu haben.

[himitsu]

Die ShellListView war doch in den Delphi-Demos, wenn ich mich recht erinnere?
also OpenSource (auf Github)

Und es nutzt einfach nur irgendwelche Shell-WinAPIs, welche man auch in uralten Delphi-Versionen nutzen kann.

[Delfiano]

Danke, ihr lieben Menschen. Aber das ändert nichts dran, dass mir das alles nichts bringt.

Mag sein, dass es den DOS-Dateinamen geschuldet ist, aber bei vernünftiger Programmierung hätte eine entsprechende Prüfung enthalten sein müssen.

Ich weiss, dass Borland damals insgesamt sehr schludrig gearbeitet hat und musste entsprechend z.B. die fehlerhaften Units für Multimedia und Multimon für meine Zwecke umstricken und leider auch umbenennen. Für Multimon hatte ich sogar eine Lösung für Delphi 1, die immerhin 2 Monitore erkannt hat.

Aktuell kenne ich wirklich keine andere Möglichkeit, als die Ergebnisse der FileListBox entsprechend der gewünschten Endung(en) in eine normale ListBox umzukopieren. Ob ich mal den Aufwand betreibe, daraus ne Komponente zu machen, weiss ich nicht.

[KodeZwerg]

Was gibt es an meinen Snippets auszusetzen?
Beide Varianten funktionieren und machen das was Du wolltest.

Naja, dann eben nicht.

//edit
Ps: Wenn Du frustriert über Dein in die Jahre gekommenes Delphi bist, niemand hindert Dich auf eine aktuelle Version upzugraden. (Delphi CE = Delphi Rio Professional)
Eine Komponente wird Dir hier wahrscheinlich niemand schreiben. Wenn Dein Code keine Änderungen zulässt hast Du vielleicht was falsch gemacht?
Zu guter letzt, Intercepte doch einfach die original Unit und schon ist alles repariert ohne das Dein Code verändert werden muss.

[Harry Stahl]

Zitat:

Zitat von Delfiano (Beitrag 1485467)

Wenn ich bei der FileListBox (Delphi 5) als Mask '*.MMP' angebe, werden auch '*.MMPZ' gelistet.

Wie kann ich das vermeiden und bringe Delphi dazu, wirklich nur Dateien der gewünschten Endung zu zeigen und diese nicht eigenmächtig zu erweitern?

Ich hab jetzt keine Lust dazu, dafür extra eine neue Komponente programmieren zu müssen.

Also ich habe hier auch noch ein Delphi 5 (Update 1) laufen.

Dort zeigt die

Maske " *.MMP " alle .MMP Dateien an
Maske " *.MMPZ " alle .MMPZ UND alle .MMP Dateien an
Maske " *.MMP* " zeigt ALLE Dateien an.

Du kannst aber auch mit diesen Kompontenten das richtige Ergebnis erhalten, wenn Du in der Maske noch zusätzlich den Pfad angibst, also "D:\*.MMPZ" dann werden nur .MMPZ Dateien angezeigt, aber keine .MMP Dateien.

Sieh dir mal den anliegenden Screenshot an, da ist alles so wie es sein soll.

Übrigens: Im aktuellen Delphi 10.4.2 funktioniert diese (Steinzeit Win 3.1 -) Komponente übrigens von Anfang an, so wie es sein soll...

Delphi-Quellcode:

procedure TForm1.DirectoryListBox1Change(Sender: TObject);
begin
  FileListBox1.Directory := DirectoryListBox1.Directory ;
  FileListBox2.Directory := DirectoryListBox1.Directory;
  FileListBox3.Directory := DirectoryListBox1.Directory;

  FileListBox1.Mask := DirectoryListBox1.Directory + '\' + Edit1.text;
  FileListBox2.Mask := DirectoryListBox1.Directory + '\' + Edit2.text;
  FileListBox3.Mask := DirectoryListBox1.Directory + '\' + Edit3.text;
end;

[Uwe Raabe]

Zitat:

Zitat von Delfiano (Beitrag 1485566)

Mag sein, dass es den DOS-Dateinamen geschuldet ist, aber bei vernünftiger Programmierung hätte eine entsprechende Prüfung enthalten sein müssen.

Zumindest ist das Verhalten für Windows dokumentiert: https://docs.microsoft.com/en-us/win...findfirstfilea

Zitat:

The search includes the long and short file names.

Man kann Windows allerdings dazu bewegen, auf diese Short Names zu verzichten - gilt dann aber für alle Anwendungen.

1. Command Prompt als Admin starten
2. fsutil volume list listet die verfügbaren Volumes
3. fsutil 8dot3name query <volume> zeigt den Status des Volumes an
4. fsutil 8dot3name set <volume> 1 schaltet Dos 8.3 Namen ab
5. fsutil 8dot3name set <volume> 0 schaltet Dos 8.3 Namen ein

Zum Weiterlesen: https://docs.microsoft.com/de-de/win...util-8dot3name

[himitsu]

fsutils sagt 0 bei mir
aber wenn ich mich recht erinnere, dann werden seit 'ner Weile 8.3-Namen nur noch erstellt, wenn sie benötigt werden. (z.B. wenn man mit der ANSI-API auf ein Verzeichnis zugreift, oder so)

Das würde dann erklären, warum es zwar an ist, aber es nichts darüber findet.

[Delphi.Narium]

Man sollte bei der Diskussion vielleicht auch mal noch beachten, dass zu Zeiten von Delphi 5 (August 1999) die Dateinamenskonvention 8.3 noch der Normalfall war und die langen Dateinamen nur ein zusätzlicher Aufsatz darauf.

Damals (seit Windows 95) galt halt 8.3 als Default und alles andere war für die Software, die halt schon damit umgehen konnte.

Heute ist es wohl umgekehrt.

Wenn ich auch heute nach wie vor gerne mit Delphi 7 arbeite, so kann ich nicht erwarten, dass die Entwickler des damaligen Delphis bereits alle Erweiterungen korrekt "abarbeiten lassen", die von Microsoft, bei der Weiterentwicklung von Windows, in neueren Versionen implementiert wurden bzw. werden.

Und TFileListBox macht nunmal (bei Delphi 7 - und früher?) intern von den Windowsfunktionen für die Dateisuche gebrauch. (Es ist damit nicht auszuschließen, dass das Ergebnis von der genutzten Windowsversion abhängig ist. Der Versuch von Harry Stahl mit Delphi 5 auf seinem Windows und das abweichende Ergebnis meines Versuches mit Delphi 7 und Windows XP dazu, lassen jedenfalls darauf schließen.) Letztlich wird die Eingabe für die Dateisuchmaske an die Windows-API weitergereicht und das von dieser Gelieferte dann zur Anzeige gebracht (und zwar so, wie geliefert).

Und wenn es da zwischen den Windowsversionen Unterschiede gibt, so kann man das den Entwicklern von Delphi 5 ... nicht vorwerfen, zumal die Änderungen in Windows ja erst nach der Entwicklung von Delphi 5 eingeführt wurden.