Filterfehler bei FileListBox

[Delfiano]

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.

[himitsu]

Seit vielen Jahren funktioniert es.
FindFirst bekommt den Filter und liefert nur Passendes.


Aber keine Ahnung wie vor 22 Jahren der Quellcode dieser Komponente aussah.
Da kannst du nur selbst nachsehen.
FileCtrl.pas und vermutlich TFileListBox.ReadFileNames

[KodeZwerg]

Die Ergebnis-Liste dann nochmal filtern wäre mein erster Gedanke. (Also simple string fileextension comparision.)

[Delfiano]

Sorry, aber wieso "FindFirst" und nochmal filtern?

FindFirst ist was für SearchRec, aber ich benutze die Komponente TFileListBox und da kann ich den Filter nur auf die ganze FileListBox setzen. Da lässt sich nichts ein zweites Mal filtern, ausser wenn ich's vielleicht in ne normale Listbox kopieren würde.

Das Problem ist, dass Delphi sich nen Dreck drum kümmert, dass man keine Dateien haben will, deren Endung die gewünschte Selektion zwar enthält, aber unerwünscht kackfrech auf mögliche nachfolgende Buchstaben erweitert.

Vergleichbar wäre wohl, wenn ich NUR htm haben will (egal weshalb) und zusätzlich html gezeigt wird. Naja, werd ich wohl nicht drum rum kommen, es doch mit SearchRec (und einer normalen ListBox) machen zu müssen.

Aber Danke für die Rückmeldungen.

Vielleicht stell ich das Projekt für das ich das brauche (falls ich's irgendwie hinbekomme) mal irgendwann rein.

Es geht drum, die komprimierten Dateien mmpz des Musikprogramms LMMS ins lesbare Format mmp zu konvertieren und danach diese Dateien laden und editieren zu können, um z.B. nötigenfalls die Pfade für enthaltene Soundfonts anzupassen. Es gibt nämlich Probleme, sobald man die Musik auf nem anderen Copmputer mit anderen Pfaden abspielen will.

Ich muss also für mein Prog die beiden Endungen sauber unterscheiden (filtern) können.

[KodeZwerg]

Nur so eine Idee, ich kann es nicht testen da mein Delphi zu aktuell ist.
Der Filter-Mask ein #0 ranbaumeln.
(also per runtime filter auf

Delphi-Quellcode:

mask := '*.ext' + #0

)

(sorry hab keine Ahnung wie die genaue bezeichnung ist, aber das wäre mein ansatz)

[Delfiano]

Leider nein. Ich hatte es zuvor auch schon mit nachgestelltem Semikolon u.a. probiert.

Derselbe Fehler tritt übrigens auch bei Delphi 7 (die letzte Version die ich habe) immer noch auf und
selbst wenn ich tatsächlich mit FindFirst etc. arbeite, ist es nicht anders.

Wenn ich gezielt versuche, dann dabei aus den Ergebnissen nur MMP (statt auch MMPZ) rauszufiltern, wird gar nichts in die (dann benutzte) ListBox kopiert. Also die von Dir vorgschlagene Doppelfilterung (die eigentlich an dieser Stelle passen würde) nutzt leider auch nix.

Warum ich (nicht nur bei Delphi) immer versuche, etwas mit möglichst alten Programmen zu ermöglichen, hat mehrere Gründe: nue kann ich mir nicht leisten, was Kaufprogramme betrifft und ausserdem möchte ich eine weitgehende Kompatibilität. Die neuen Windowsversionen sind mir ein Gräuel mit all ihren Einschränkungen, wo selbt dann vieles nicht funktioniert, wenn man sich volle Adminrechte zuweist.

Danke nochmal für Deine Hilfe. Aber ich werd wohl versuchen müssen, mir was ganz anderes auszudenken.

[Delfiano]

Ich habe eine Lösung gefunden, die zwar funktioniert, mir aber programmiertechnisch mißfällt.

Dazu schalte ich FileListbox.visible auf FALSE, und kopiere (je nachdem ob ich auf die Endung MMP oder MMPZ zugreifen will) die anhand der Auswertung der Endung die passenden Dateien in eine normale ListBox. Die Umschaltung ob MMP oder MMPZ muss dann eben z.B. durch Buttons erfolgen.

Das ist dann auch schon ab Delphi 3 möglich.

Sobald ich das Zielprojekt (wie erwähnt) funktionsfähig bekomme (was bestimmt noch eine ganze Weile dauern wird) werde ich es im Forum einstellen.

[KodeZwerg]

Hier wäre meine Lösung zu Post #3, soeben getestet.

Was man hier nicht sieht:
FileListBox1.Mask auf "*.*" gesetzt.
DriveComboBox1 hat Bezug zu DirectoryListBox1.
DirectoryListBox1 hat keinen Bezug zu FileListBox1.
DirectoryListBox1 ein OnChange Event zugewiesen was man hier dem Code entnehmen kann um die FileListBox1 zu füllen.
Edit1.Text ist mit ".Extension" gefüllt.
Beispielsweise ".mm" um wirklich nur Dateien mit Endung ".mm" zu haben, auch wenn ".mm1" ".mmXyz" usw existiert.
Kannst Du logischerweise entfernen und hardcoded reinpacken.

Delphi-Quellcode:

type
  TForm2 = class(TForm)
    DriveComboBox1: TDriveComboBox;
    DirectoryListBox1: TDirectoryListBox;
    FileListBox1: TFileListBox;
    Edit1: TEdit;
    procedure DirectoryListBox1Change(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  Form2: TForm2;

implementation

{$R *.dfm}

procedure TForm2.DirectoryListBox1Change(Sender: TObject);
var
  i: Integer;
  SL: TStringList;
begin
  FileListBox1.Directory := DirectoryListBox1.Directory;
  SL := TStringList.Create;
  try
    FileListBox1.Items.BeginUpdate;
    for i := 0 to FileListBox1.Items.Count - 1 do
      if LowerCase(ExtractFileExt(FileListBox1.Items[i])) = LowerCase(Edit1.Text) then
        SL.Add(FileListBox1.Items[i]);
    FileListBox1.Clear;
    FileListBox1.Items := SL;
    FileListBox1.Items.EndUpdate;
  finally
    SL.Free;
  end;
end;

end.

Vielleicht ist das ein Ansatz für Dich?

//edit
Vielleicht wäre es klug der Mask ein vorfilterung anzubieten.

Delphi-Quellcode:

procedure TForm2.DirectoryListBox1Change(Sender: TObject);
var
  i: Integer;
  SL: TStringList;
begin
  FileListBox1.Mask := '*' + Edit1.Text;
//  ...dann der Rest aus obigen listing

[Delphi.Narium]

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äß ;-)

[himitsu]

Zitat:

Zitat von KodeZwerg (Beitrag 1485476)

Nur so eine Idee, ich kann es nicht testen da mein Delphi zu aktuell ist.
Der Filter-Mask ein #0 ranbaumeln.
(also per runtime filter auf

Delphi-Quellcode:

mask := '*.ext' + #0

)

(sorry hab keine Ahnung wie die genaue bezeichnung ist, aber das wäre mein ansatz)

Das machen die schon intern.
Die FileListBox nimmt den Filter, ersetzt die ; durch #0 und lässt sich dann nacheinander über FindFirst/FindNext mit den filtern die Dateien geben.

Man kann somit auch Verzeichnisse in diesen Filter einbauen. (auch wenn es so eigetnlich garnicht geplant war)

Delphi-Quellcode:

*.*;..\*.*

liefert alle Dateien von dem Verzeichnis und des Übergeordneten.

Zitat:

Es werden auch die Dateien mit der Endung mmpz gefunden.

Bei mir nicht. *.dpr zeigte nur dpr und keine dproj
Zumindestens in im aktuellen Windows 10. Die Delphiversion spielt bei FindFirst keine große Rolle. (der einzige Unterschied ist ANSI und Unicode, aber da die ANSI-API den aufruf an die UnicodeAPI nur durchreichet, kommt da vermutlich das Gleiche bei raus)

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

[Delfiano]

@KodeZwerg

Zitat:

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.

Ich finde das ziemlich frech. Ich habe nie verlangt, dass mir jemand ne Komponente schreibt. Und ich bin auch nicht über alte Delphi-Versionen frustiert, sondern will gar keine neuen.

Warum Deine Vorschläge (und die von anderen) NICHT funktionieren, ist mittlerweile klar geworden.

Ich entwickle nach wie vor gerne unter XP, denn je neuer die Windows-Version, desto aufgeblähter und fehlerträchtiger ist sie. Mit neuen Windows-Versionen gibt es das von mir geschilderte Problem tatsächlich nicht, sondern da gibt es saubere Trennungen.

[KodeZwerg]

Zitat:

Zitat von Delfiano

Danke, ihr lieben Menschen. Aber das ändert nichts dran, dass mir das alles nichts bringt.
...
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.

Zitat:

Zitat von KodeZwerg (Beitrag 1485568)

Was gibt es an meinen Snippets auszusetzen?

Zitat:

Zitat von Delfiano (Beitrag 1485903)

Warum Deine Vorschläge (und die von anderen) NICHT funktionieren, ist mittlerweile klar geworden.

Wenn Du doch nur mal sagen würdest was nicht funktioniert... so kann man nicht helfen selbst wenn man es nur gut meint.

Die Vcl Version von mir sollte mit deinem Delphi und auch mit Windows XP klar kommen, ich finde da gerade nichts auffälliges.
Die Winapi Version sollte auch laufen wenn ich Microsoft korrekt interpretiere

Delphi-Quellcode:

Minimum supported client = Windows XP [desktop apps | UWP apps]

(Nachzulesen hier.)
Man muss halt nur für Dein altes Delphi alles noch an UniCode anpassen oder halt Ansiversionen nutzen und sich wundern das manche Namen merkwürdig aussehen.

Es tut mir leid was auch immer Dich an meiner Aussage aufgewühlt hat.

[Delfiano]

Wie soll ich denn beschreiben, was nicht funktioniert?

In der Regel bedeutet es, dass es als Ergebnis die gewünschte Unterscheidung nicht gibt. Dass es schon standardmässig u.a. an der jeweiligen Windows-Version liegt, hatte ich doch mittlerweile heraugefunden.

Allerdings kann ich Dein letztes Beispiel gar nicht erst kompilieren:

Code:

[Fehler] Unit1.pas(40): Undefinierter Bezeichner: 'FindExInfoBasic'
[Fehler] Unit1.pas(40): Inkompatible Typen: 'Cardinal' und 'LongBool'
[Fehler] Unit1.pas(50): Undefinierter Bezeichner: 'Winapi'
[Fataler Fehler] Project1.dpr(5): Verwendete Unit 'Unit1.pas' kann nicht compiliert werden

40: hFile := FindFirstFileEx(PChar(edPath.Text + edMask.Text), FindExInfoBasic, @FindData, FindExSearchNameMatch, nil, FIND_FIRST_EX_LARGE_FETCH);
50: Winapi.Windows.FindClose(hFile);

Und was mich aufgeregt habt, lieber Kodezwerg, sind Dein "Naja, dann eben nicht." und Deine Unterstellungen im "//edit"-Teil.

Und wie das hier von Harry Stahl bei ihm unterschiedliche Ergebnisse bringen soll, ist mir unklar.

Code:

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;

Ich hab wirklich extra nochmal den Aufwand betrieben, die Vorschläge genau umzusetzen, obwohl ich gar keine umständlichen Edit-Felder benutze, sondern die Auswertung, wonach gesucht werden soll, viel einfacher vornehme, also entweder in den Click-Anweisungen von Buttons oder Radiobuttons.

[KodeZwerg]

Zitat:

Zitat von Delfiano (Beitrag 1485914)

Wie soll ich denn beschreiben, was nicht funktioniert?

Genau so wie Du es nun getan hast!!!!
Woher soll denn einer Wissen der nicht Deine Delphi Version zur Verfügung hat was da schiefläuft ?

Zitat:

Zitat von Delfiano (Beitrag 1485914)

Allerdings kann ich Dein letztes Beispiel gar nicht erst kompilieren

Da nun klar ist woran es liegt, hier ein neuer Versuch.

Zitat:

Zitat von Delfiano (Beitrag 1485914)

Und was mich aufgeregt habt, lieber Kodezwerg, sind Dein "Naja, dann eben nicht." und Deine Unterstellungen im "//edit"-Teil.

Hiermit reiche ich Dir nochmal die Hand in der Hoffnung das Du es mir nicht mehr böse nimmst, Frieden zwischen uns okay?

Delphi-Quellcode:

{$IF CompilerVersion >= 23}
{$DEFINE NameSpace}
{$ELSE CompilerVersion}
{$UNDEF NameSpace}
{$IFEND CompilerVersion}
unit Unit4;

interface

uses
{$IFDEF NameSpace}
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls;
{$ELSE NameSpace}
  Windows, Messages, SysUtils, Variants, Classes, Graphics,
  Controls, Forms, Dialogs, StdCtrls;
{$ENDIF NameSpace}

const
  kernelbase = 'kernel32.dll';
  FIND_FIRST_EX_LARGE_FETCH = 2;
  MAX_PATH = 260;

type
  LPWSTR = PWideChar;
  _WIN32_FIND_DATAW = record
    dwFileAttributes: DWORD;
    ftCreationTime: TFileTime;
    ftLastAccessTime: TFileTime;
    ftLastWriteTime: TFileTime;
    nFileSizeHigh: DWORD;
    nFileSizeLow: DWORD;
    dwReserved0: DWORD;
    dwReserved1: DWORD;
    cFileName: array[0..MAX_PATH - 1] of WideChar;
    cAlternateFileName: array[0..13] of WideChar;
  end;
  WIN32_FIND_DATAW = _WIN32_FIND_DATAW;
  TWin32FindDataW = _WIN32_FIND_DATAW;

  _FINDEX_INFO_LEVELS = (FindExInfoStandard, FindExInfoBasic, FindExInfoMaxInfoLevel);
  TFindexInfoLevels = _FINDEX_INFO_LEVELS;
  _FINDEX_SEARCH_OPS = (FindExSearchNameMatch, FindExSearchLimitToDirectories,
    FindExSearchLimitToDevices);
  TFindexSearchOps = _FINDEX_SEARCH_OPS;

function FindFirstFileExW(lpFileName: LPWSTR; fInfoLevelId: TFindexInfoLevels;
  lpFindFileData: Pointer; fSearchOp: TFindexSearchOps; lpSearchFilter: Pointer;
  dwAdditionalFlags: DWORD): THandle; stdcall;
function FindNextFileW(hFindFile: THandle; var lpFindFileData: TWIN32FindDataW): BOOL; stdcall;

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

var
  Form4: TForm4;

implementation

{$R *.dfm}

function FindFirstFileExW; external kernelbase name 'FindFirstFileExW';
function FindNextFileW; external kernelbase name 'FindNextFileW';

procedure TForm4.btnStartClick(Sender: TObject);
var
  SL: TStringList;
  hFile: THandle;
  FindDataW: TWIN32FindDataW;
begin
  SL := TStringList.Create;
  try
    hFile := FindFirstFileExW(PWideChar(edPath.Text + edMask.Text), FindExInfoBasic, @FindDataW, FindExSearchNameMatch, nil, FIND_FIRST_EX_LARGE_FETCH);
    if hFile <> INVALID_HANDLE_VALUE then
      begin
        repeat
          if (((FindDataW.dwFileAttributes and FILE_ATTRIBUTE_DIRECTORY) = 0) and (FindDataW.cFileName <> WideString('.')) and (FindDataW.cFileName <> WideString('..'))) then
            begin
              SL.Add(WideString(FindDataW.cFileName));
            end;
        until (not FindNextFileW(hFile, FindDataW));
      end;
    {$IFDEF NameSpace}Winapi.{$ENDIF NameSpace}Windows.FindClose(hFile);
    lbFiles.Items.BeginUpdate;
    lbFiles.Clear;
    lbFiles.Items := SL;
    lbFiles.Items.EndUpdate;
  finally
    SL.Free;
  end;
end;

end.

Im Anhang ist das Projekt als Quelltext sowie in kompilierter Form.
Es kann sein das Dein Delphi mit der .dfm Datei nicht klarkommt (Align und AlignWithMargins). Diese Fehler ignorieren und selbst das Design anpassen.
Es kann sein das Dein Delphi mit der .res Datei nicht klarkommt, einfach löschen und Delphi eine Eigene erstellen lassen, da ist nur das Icon drinnen.

Wenn es wieder nicht funktionieren sollte, gebe wieder Bescheid in der Form wie Du es nun gemacht hast. (Benenne Fehler, sag nicht einfach nur "klappt nicht")


//edit
Mir ist noch ein Fehler unterlaufen für Deine Delphi Version an den ich vorher nicht gedacht hatte.
Bitte die .dpr Datei anpassen bevor Du das Projekt in Delphi reinlädst. Das hatte ich vorhin noch nicht auf dem Schirm gehabt.

Delphi-Quellcode:

{$IF CompilerVersion >= 23}
{$DEFINE NameSpace}
{$ELSE CompilerVersion}
{$UNDEF NameSpace}
{$IFEND CompilerVersion}
program Project8;

uses
{$IFDEF NameSpace}
  Vcl.Forms,
{$ELSE NameSpace}
  Forms,
{$ENDIF NameSpace}
  Unit4 in 'Unit4.pas' {Form4};

{$R *.res}

begin
  Application.Initialize;
  Application.MainFormOnTaskbar := True; // ich weiß nicht ob Dein Delphi das kennt, Zeile löschen wenn nötig.
  Application.CreateForm(TForm4, Form4);
  Application.Run;
end.

[KodeZwerg]

@Delfiano
Ich möchte nicht aufdringlich sein oder nerven, lediglich nachfragen ob es nun geklappt hat und das Problem gelöst ist.

[Delfiano]

Sorry, wegen anderer Sachen bin ich erst heute dazu gekommen, mich mal wieder hier einzuloggen.

Nein.

Das Problem ist dadurch leider nicht gelöst. Wenn ich nach *.mmp suche, wird weiter auch *.mmpz angezeigt.

Es hat auch überhaupt nichts mit der Länge der Endung (also 8+3) zu tun, denn unter XP funktioniert die Standardfunktion korrekt, und da gab es längst lange Dateinamen.

Nein, es liegt eindeutig an Microsofts Schlampigkeit.

Ich hatte mir ja vor mehreren Monaten angetan, einige meiner Computer mit Windows 8.1 und 10 auszustatten und hatte vor ein paar Tagen vor, es mit einem weiteren zu tun. Aber gleich nach der Installation habe ich mich schon wieder geärgert, was ich da alles machen muss, um diesen ganzen Müll loszuwerden, den ich nicht haben möchte, angefangen mit den "Apps" ...

Ich hab's dann wiwder gelöscht. Microsoft entwickelt nur noch unzumutbaren Schrott. Wenn ich also hier in diesem Forum noch mal Projektansätze veröffentliche, kann ich nicht garantieren, dass diese mit Widowsversionen nach XP funktionieren.

An dieser Stelle aber noch mal recht vielen Dank an alle, die sich dieses seltsamen Delphi-Verhaltens angenommen haben, und ganz besonders an den KodeZwerg !

Ach so, noch was: Die Original-Exe-Datei vom KodeZwerg liefert unter XP gar kein Ergebnis und der Quelltext lässt sich (auch nach Entfernen der ungültigen Compileranweisungen) bei mir nicht kompilieren.

"Access violation at adress 0547487B in module RLINK32.DLL. Read of address 060600E2" (wenn ich mich beim abschreiben vertippt habe)...