TDirectory.GetLogicalDrives

[Willie1]

Hallo Leute,
das

Delphi-Quellcode:

procedure TForm1.Button5Click(Sender: TObject);
var
  drives: TStringDynArray;
  drive: string;
begin
  lbDrives.Items.Clear;
  drives:=TDirectory.GetLogicalDrives;
  for drive in drives do lbDrives.Items.Add(drive);
end;

liefert die logischen Laufwerke. Um die Lw besser unterscheiden zu könen will ich noch die Laufwerksnamen hinzufügen Gibt es da bei den schönenn IOUtils oder sonst wo eine Funktion oder muss ich da auf die alte Tipp-Sammlung von Michael Puff zurückgreifen?
Gruß Willie.

[FriedrichAT]

Hallo Willie!
Habe etwas in meinem "Fundus" gefunden...

Delphi-Quellcode:

uses DDsnippets;

procedure TForm1.Button1Click(Sender: TObject);
var SL: TStrings;
begin
  SL:= TStringList.Create;
  try
    DriveDisplayNames(SL);
    ComboBox1.Items.Assign(SL);
    ComboBox1.ItemIndex:= 0;
  finally
    SL.Free;
  end;
end;

Hoffe es hilft!!!

[Willie1]

Hallo Friedrich,
prima, es hilft. Danke.

Vorschlag an die Delphi-Macher: TDirectory.GetDriveLabel(drive: char) wäre nützlich und leicht zu implementieren.
Gruß Willie.

[dummzeuch]

Zitat:

Zitat von Willie1 (Beitrag 1477224)

Vorschlag an die Delphi-Macher: TDirectory.GetDriveLabel(drive: char) wäre nützlich und leicht zu implementieren.

Da die "Delphi Macher" hier nicht mitlesen, wäre ein Quality Portal Eintrag sinnvoll.

[Willie1]

Es funktioniert leider nicht.
Es knallt beim Beenden des Programms.
Ist nicht so schlimm, ich benutze die Tipp-Sammlung von Michael Puff.
Schönes Wochenende Willie.

[FriedrichAT]

Hallo Willie!

Hätte Dir den Tipp nicht ungeteste angeboten...
Würde mich selbst interesieren warum es "knallt".
Etwas QC deiner Abfrage zu sehen um den "Es knallt beim Beenden des Programms" - Fehler
einzugreisen wäre nicht schlecht.

Gruß Friedrich

[Delphi.Narium]

Würde nicht ein

Delphi-Quellcode:

uses DDsnippets;

procedure TForm1.Button1Click(Sender: TObject);
begin
  DriveDisplayNames(ComboBox1.Items);
  ComboBox1.ItemIndex := 0;
end;

reichen?

[Willie1]

Hallo Friedrich,
ich habe deine Quelltexte zunächst unverändert übernommen. DDSnippets.pas habe ich nie geändert.

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  SL: TStringList;
begin
   SL:=TStringList.Create;
   try
     DriveDisplayNames(SL);
     ComboBox1.Items.Assign(SL);
     ComboBox1.ItemIndex:=0;
   finally
     SL.Free;
   end;
end;

Ich habe es jetzt so geschrieben.
Beim ersten Durchlauf funktioniert es, bei weiteren gibt es eine Fehlermeldung, probiere es bitte selbst aus. (du brauchst es ja nur zu kopieren)
Gruß Willie.

[Dalai]

@Willie1:
Du solltest den Debugger häufiger und intensiver benutzen. Setze einen Breakpoint an der Stelle, an der die AV auftritt. Schau dir an, in welcher Routine das passiert und setze ggf. an den Anfang selbiger einen weiteren Breakpoint. Dann gehe Schritt für Schritt (F7) durch den Code und schau dir im Debugger den Inhalt der Variablen an, ob die einen plausiblen Inhalt haben.

Ich hab den Code grade ausprobiert, und kann da kein Problem feststellen, weder im Delphi 5 noch im XE2. Andererseits hab ich natürlich auch nicht die Laufwerke in deinem Rechner.

Wenn ich eine Vermutung anstellen darf: Es ist sehr gut denkbar, dass die Benutzung dieser Unit Fehler in deinem Code offenbart, die bisher nicht aufgefallen sind, verdeckt geblieben sind.

[EDIT]
Auf meinem Host knallt es auch beim dritten Aufruf der Funktion, in den VMs hingegen gar nicht.
[/EDIT]

Grüße
Dalai

[FriedrichAT]

Hallo willie!

Wie Dalai schon schrieb gibt es eventuell Probleme mit deinen vorhandenen Laufwerken.
Habe Dir eine PN geschrieben in der ich Dir den Debugger empfohlen habe, um so den Fehler
einzugreisen.
Was war das ergebnis?
Würde mich persönlich interesieren.

[FriedrichAT]

:thumb:@Delphi.Narium
Natürlich würde das reichen...8-)
Habe es aber SO geschrieben um es "Sichtbar" zu machen was passiert...

Delphi-Quellcode:

uses DDsnippets;

procedure TForm1.Button1Click(Sender: TObject);
begin
  ComboBox1.Items.Clear;  // wäre auch nicht schlecht! oder?
  DriveDisplayNames(ComboBox1.Items);
  ComboBox1.ItemIndex := 0;
end;

[Delphi.Narium]

Zitat:

Zitat von FriedrichAT (Beitrag 1477336)

:thumb:@Delphi.Narium
Natürlich würde das reichen...8-)
Habe es aber SO geschrieben um es "Sichtbar" zu machen was passiert...

Delphi-Quellcode:

uses DDsnippets;

procedure TForm1.Button1Click(Sender: TObject);
begin
  ComboBox1.Items.Clear;  // wäre auch nicht schlecht! oder?
  DriveDisplayNames(ComboBox1.Items);
  ComboBox1.ItemIndex := 0;
end;

Ja aber:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  SL: TStringList;
begin
   SL:=TStringList.Create; // wird erstellt
   try
     DriveDisplayNames(SL); // wird gefüllt
     ComboBox1.Items.Assign(SL); // wird zugewiesen - die Stringliste, nicht der Inhalt - Items zeigt also auf SL
     ComboBox1.ItemIndex:=0;
   finally
     SL.Free; // wird weggeworfen, obwohl oben zugewiesen.
   end;
end;

Und diese Abfolge kann "irgendwann" zu 'ner Schutzverletzung führen.

Zitat:

Zitat von FriedrichAT (Beitrag 1477336)

Delphi-Quellcode:

uses DDsnippets;

procedure TForm1.Button1Click(Sender: TObject);
begin
  ComboBox1.Items.Clear;  // wäre auch nicht schlecht! oder?
  DriveDisplayNames(ComboBox1.Items);
  ComboBox1.ItemIndex := 0;
end;

Das Clear täte ich jetzt nicht hier schreiben, da ich davon ausgehe, dass eine Methode, die die Aufgabe hat eine Stringliste zu befüllen, gefälligst selbst dafür sorgt, dass anschließend nur der von ihr erwartete Inhalt in der Stringliste enthalten ist. Daher gehört das Clear für meine Begriffe in die Methode DriveDisplayNames. Wenn dem nicht so wäre und ich sie in 1000den Programmen nutze, müsste ich 1000de Male das Clear schreiben (und alle Nutzer darüber informieren, dass sie vor dem Aufruf der Methode gefälligst ein Clear zu schreiben haben), so aber nur einmal. Bin halt faul ;-)

Enthielte die Methode DriveDisplayNames kein Clear, hieße sie bei mir AddDriveDisplayNames, damit man am Namen bereits erkennt, dass sie was hinzufügt. Hier müsste dann der Nutzer selbst für das Clear sorgen ;-) Ist aber alles irgenwie auch ein bisserl Geschmackssache.

[Dalai]

Soweit ich weiß, ist die Methode Assign genau dazu da, damit hinterher beide Objekte nicht auf dieselbe Adresse zeigen, aber trotzdem denselben Inhalt haben. Die Adresse von ComboBox1.Items wird durch

Delphi-Quellcode:

ComboBox1.Items.Assign(SL);

nicht geändert, und SL kann bedenkenlos freigegeben werden. Gleiches gilt für die Methode AssignTo in die andere Richtung. Würden beide Objekte auf dieselbe Adresse zeigen, wäre die Methode Assign ziemlich sinnlos, weil man dasselbe durch

Delphi-Quellcode:

ComboBox1.Items := SL;

erreichen könnte.

TStrings.Assign sagt auch:

Zitat:

Use Assign to set the value of the TStrings object from another object.

Grüße
Dalai

[HeZa]

Zitat:

Zitat von Dalai (Beitrag 1477357)

Würden beide Objekte auf dieselbe Adresse zeigen, wäre die Methode Assign ziemlich sinnlos, weil man dasselbe durch

Delphi-Quellcode:

ComboBox1.Items := SL;

erreichen könnte.

Das ist nicht richtig.

Delphi-Quellcode:

ComboBox1.Items := SL;

führ via Setter zu Items (SetItems) auch ein

Delphi-Quellcode:

Items.Assign

aus. Und ein [DELPHI]ComboBox1.Items.Free[DELPHI] führt nur zu einer leeren Items-Liste (auch wenn es nicht dieselbe wie vorher ist).

[Willie1]

Hallo Freunde, (oder *innen)
wg. Augen hab' ich übersehen, dass wir schon auf Seite 2 sind.
Eure Diskussion hat nichts mit dem Fehler zu tun. Assign habe ichschon oft benutzt und das ursprüngliche Objekt mit Free frei gegeben und das läuft!

Delphi-Quellcode:

procedure MultiSzToStrings(const MultiSz: PChar;
  const Strings: Classes.TStrings);
  {Splits out individual strings from given 'MultiSz' strings buffer and adds
  each string to the given string list. A MultiSz string is a sequence of #0
  delimited strings terminated by an extra #0 character. Does nothing if string
  list or MultiSz buffer are nil.}
var
  P: PChar;   // pointer to strings in buffer
begin
  // Do nothing in MultiSz is nil
  if not Assigned(MultiSz) then
    Exit;
  // Scan thru #0 delimited strings until #0#0 found
  P := MultiSz;
  while P^ <> #0 do
  begin
    // add string to list
    Strings.Add(P);
    // move pointer to start of next string if any
    Inc(P, SysUtils.StrLen(P) + 1);  //hier kracht es bei Durchlauf >= 2.
  end;
end;

Die Schleife wird falsch beendet. Siehe Screenshots. Den gesamten Source hat Friedrich ja hoch geladen.
Willie.

[himitsu]

Auf den ersten Blick sieht deine Schleife nicht so aus, als wenn sie nicht gehen sollte.
Ein Problem mit ANSI <-> Unicode hast du nicht zufällig?

Per se:
ein #0 = String-Ende
zwei #0#0 = Listen-Ende

bzw. ist eigentlich ein leerer String '' ist das Ende (nichts zwischen zwei #0) und natürlich auch ein NIL (komplett leere Liste)


noch ein paar mögliche Varianten:

Delphi-Quellcode:

while P^ <> #0 do begin
  Strings.Add(P);
  P := StrEnd(P) + 1;
end;

while P <> '' do begin
  S := P;
  Strings.Add(S);
  Inc(P, Length(S) + 1);
end;

while True do begin
  S := P;
  if S = '' then
    Break;
  Strings.Add(S);
  Inc(P, Length(S) + 1);
end;

[Dalai]

Inzwischen kann ich die AV an sich nachvollziehen. Ab dem dritten Durchlauf der Funktion DriveDisplayNames bekomme ich folgende AV, reproduzierbar:

Code:

---------------------------
Project1
---------------------------
Access violation at address 004030B5 in module 'Project1.exe'. Read of address 00000054.
---------------------------
OK   
---------------------------

Keine der von himitsu gebotenen Varianten für MultiSzToStrings ändert daran etwas.

Die AV tritt nicht auf, wenn ich eines der folgenden Dinge tue:

• Die Liste wird direkt an ComboBox1.Items zugewiesen statt über den Umweg einer weiteren lokalen Stringliste
• Die Funktion DriveDisplayNames so modifiziert, dass sie DriveDisplayName nicht aufruft (so dass nur die Laufwerksbuchstaben in der Liste stehen)
• eine mit D5 kompilierte Anwendung nutze.

Leider tritt das Problem bei mir nur auf dem Host auf, wo ich kein Delphi habe (und ich keinen Remotedebugger installieren will), so dass eine genauere Untersuchung extrem erschwert wird. Mir ist auch nach x-fachem Durchkauen des Codes der Unit und dem Testen kleinerer Änderungen schleierhaft, wo das Problem stecken soll :?.

Bemerkenswert ist noch Folgendes: Mein System hat die Laufwerke B: bis Y: (mit einigen Lücken). Bei den ersten beiden Aufrufen werden alle angezeigt, ab dem dritten geht's nur noch bis einschließlich H: - es fehlt die Hälfte aller Laufwerke.

Grüße
Dalai

[Delphi.Narium]

Zitat:

Zitat von Dalai (Beitrag 1477401)

Die AV tritt nicht auf, wenn ich eines der folgenden Dinge tue:

• Die Liste wird direkt an ComboBox1.Items zugewiesen statt über den Umweg einer weiteren lokalen Stringliste

Deshalb schrieb ich ja auch:

Zitat:

Und diese Abfolge kann "irgendwann" zu 'ner Schutzverletzung führen.

Und nicht, dass es zwingend eine Schutzverletzung geben muss oder dass das gemachte grundsätzlich falsch ist.

Es ist mir im Laufe der Jahre immer wieder mal in Programmen sporadisch passiert, das so ein Effekt auftrat, auch wenn er bei genauer Betrachtung des Quelltextes, einschließlich dem aller aufgerufenen Methoden, nicht auftreten darf.

Da ist "irgendwo innendrinnen in den Tiefen des Genutzten" was nicht in Ordnung, aber keine Ahnung wo und warum und wieso und weshalb.

Weiß halt nur aus Erfahrung: Es kann zu einem Problem führen, es muss nicht.

Und: Eigentlich darf es zu keinem Problem führen.

Die schleierhaft verkürzte Liste ist auch ein Hinweis auf das Problem, nur das dort halt nicht alles Weg ist (= Schutzverletzung) sondern nur eine Teilmenge.

Hab' solche Probleme schon häufiger gehabt, die, soweit ich mich erinnere, immer irgendwo auch mit dem Aufruf von Windowsfunktionen im Zusammenhang standen.

Aus purer Delphisicht ist da nichts falsch, egal ob mit oder ohne zusätzlicher Stringliste. Grundsätzlich sind das Assign(Stringliste) und der Free dahinter vollkommen in Ordnung, aber leider manchmal doch irgendwie unergründbar falsch.

[Delfiano]

Delphi-Quellcode:

  while P^ <> #0 do
  begin
    // add string to list
    Strings.Add(P);
    // move pointer to start of next string if any
    Inc(P, SysUtils.StrLen(P) + 1); //hier kracht es bei Durchlauf >= 2.
  end;

Liegt der Fehler vielleicht daran, dass +1 hinzugezählt wird, auch wenn P^ bereits #0 ist?

Muss es nicht heissen "while P^ > #0 do" oder so ähnlich?

Kürzlich hatte ich nämlich einen ähnlichen Fehler. Der hier ist schwieriger erkennbar, weil mit Pointern gearbeitet wird. Sowas ist doch bei Sachen, die so wenig Speicher belegen irgendwie absurd.

[Dalai]

Wenn P^ #0 wäre, wäre die Schleife bereits verlassen worden.

Es muss +1 addiert werden, um auf den Beginn des folgenden (Teil)Strings zu kommen. Am Ende des Gesamtstrings ist sowieso ein Doppelnullbyte. Grundsätzlich ist der Code schon richtig. Addiert man die +1 nicht, bricht die Schleife nach dem ersten Laufwerk ab (weil der Pointer auf dem Nullbyte nach dem ersten Laufwerk steht).

Ich hab sogar eine ähnliche Variante aus einem anderen Projekt probiert:

Delphi-Quellcode:

procedure SplitMultiSZToStringList(AStr: PChar; const sl: TStringList);
begin
    if Assigned(AStr) then begin
        sl.Clear;
        while AStr[0] <> #0 do begin
            if AStr <> '' then
                sl.Add(AStr);
            Inc(AStr, StrLen(AStr) + 1)
        end;
    end;
end;

Aber auch das ändert nichts.

Interessant auch: Nutzt man die ANSI-Funktion GetLogicalDriveStringsA und passt die Variablentypen entsprechend an, knallt es auch nicht mehr. Verstehe das, wer will.

Grüße
Dalai

[Willie1]

Hallo Freunde,
ich finde den Fehler nicht. Manchmal crasht es auch erst nach dem 3. Mal!
Dann ist es besser, wenn man ganz von vorne anfängt.

Delphi-Quellcode:

implementation
uses ShellAPI, System.IOUtils;

{$R *.dfm}

function GetOneDrive(const Drive: string): string;
  {Returns the display name for the drive with the given root path.}
var
  FI: TSHFileInfo; // info about drive
begin
  if ShellAPI.SHGetFileInfo(
    PChar(Drive),
    0,
    FI,
    SizeOf(FI),
    ShellAPI.SHGFI_DISPLAYNAME
  ) = 0 then
    RaiseLastOSError;
  Result := FI.szDisplayName;
end;

function GetAllDrives: TStringDynArray;
var
  i: Integer;
begin
  Result := TDirectory.GetLogicalDrives;
  for i:=Low(Result) to High(Result) do
    Result[i] := GetOneDrive(Result[i]);
end;

So geht es auch 100x. Ich gehe davon aus, dass TDirectory.GetLogicalDrives ALLE (außer Netz-) Laufwerke findet also auch z.B. C:,D:,E:,G: und Z: . Es dürfte also eigentlich kein Fehler auftreten, ein Lw gibt es immer.
Ich finde es interessant und gut, dass der Autor den Weg über GetFileInfo statt GetVolumeInfo gewählt hat, weil dann auch ein CD-Lw richtig angezeigt wird.
Nach der langen Diskussion, was haltet ihr von meinem Ansatz?
Gruß Willie.

[Delfiano]

Oh, ich hatte die falsche Stelle erwischt und dadurch kam auch mein Denkfehler.

Es ist tatsächlich egal, ob <>#0 oder >#0, aber es fehlt etwas.

Delphi-Quellcode:

while P^ <> #0 do
  begin
    // add string to list
    Strings.Add(P);
    // move pointer to start of next string if any
    Inc(P, SysUtils.StrLen(P) + 1); //hier kracht es bei Durchlauf >= 2.
  end;

Was ich eigentlich meinte, wäre es könnte entweder heissen:
IF P^<> #0 THEN Inc(P, SysUtils.StrLen(P) + 1);
oder nach "end;" müsste die in dem Fall zuvlel addierte 1 wieder abgezogen werden.

Irgendwie muss ich bei sowas an StringGrids denken, die man mit Daten füttert und immer 1 addiert, am Schluss dann aber eine leere Zeile zuviel vorhanden ist, wenn die nicht wieder abgezogen wird.

[himitsu]

Man könnte natürlich auch erstmal schauen was in dem Puffer drin ist.
Es wäre zwar eienartig, aber kann natürlich auch sein, dass die Daten "ungülig" raus kommen.

Und ja, das +1 ist richtig, denn es muß nunmal inkl. dem einem #0 weitergezählt werden, um auf dem nächsten Item weiterzumachen.



PS: Via WMI käme man auch an diese Daten.

[hoika]

Halo,
ich poste hier mal den JEDI-Code.

Delphi-Quellcode:

procedure MultiSzToStrings(const Dest: TAnsiStrings; const Source: PMultiSz);
var
  P: PMultiSz;
begin
  Assert(Dest <> nil);
  Dest.BeginUpdate;
  try
    Dest.Clear;
    if Source <> nil then
    begin
      P := Source;
      while P^ <> #0 do
      begin
        Dest.Add(string(AnsiString(P))); // OF AnsiString to TStrings
        P := StrEnd(P);
        Inc(P);
      end;
    end;
  finally
    Dest.EndUpdate;
  end;
end;

Vielleicht ist das StrLen ja falsch.

Wenn die JEDI auch abschmiert, hat dein Puffer nicht die #0#0 am Ende oder der letzte String nicht das #0.

[himitsu]

Funktionell stimmt es ja, aber TAnsiStrings und Dest.Add(string(...)) passt ja garnicht
und soeinen sinnlosen Fehler hätte ich nicht von den JEDI erwartet, vor allem da der Compiler das eigentlich auch bemängeln sollte. (diese String-Zuweisung an einen AnsiString-Parameter, seit D2009+)


Da hier das Problem eh nur bei der Unicode-Version passieren sollte:
Das ANSI und die string(AnsiString(-Casts weg, schon ergibt das eine PChar-Version. (ab D2009 somit Unicode)

[hoika]

Hallo,
mir ging es eher um das StrEnd statt StrLen.
Ich glaube der Buffer entspricht nicht Vorgaben.
Aber mit einer lokalen Variable für StrLen ähnlich dem JEDI-Code sollte das rauszufinden sein.
Und wenn das noch schön reproduzierbar ist, sollte der Fehler schnell zu finden sein.

PS: Mein JEDI ist schon ziemlich alt.
Viell. wurdeder String-TypeCastbschon gefixt, falls es ein Fehler ist.

[Dalai]

Zitat:

Zitat von hoika (Beitrag 1477445)

mir ging es eher um das StrEnd statt StrLen.

himitsu hatte ja eine Variante mit StrEnd gepostet - es ändert nichts.

Da die Unit ja ein paar zusätzliche Funktionen bereitstellt, kann man kann die Funktion DriveDisplayNames auch so schreiben:

Delphi-Quellcode:

procedure DriveDisplayNames(const List: TStrings);
  {Gets list of display names for all the system's drives and stores in a given
  string list.}
var i: byte;
begin
    for i:= 0 to 25 do begin
        if IsValidDriveNum(i) then
            List.Add(DriveDisplayName(DriveRootPath(i)));
    end;
end;

Das funktioniert bei mir zuverlässig und ohne AV nach dem x-ten Aufruf.

@Willie1:
Such dir einen Weg aus, es sind ja bereits genügend Varianten gepostet worden.

Grüße
Dalai

[Willie1]

Hallo,
da hat sich mein Thema verselbständigt. Die Methode hat einen tief versteckten Fehler.
Warum soll ich mich damit herumschlagen. Ich habe eine Lösung siehe # 21.
Willie.

[Dalai]

Es ist zwar nicht auszuschließen, dass die Funktion MultiSzToStrings einen Fehler hat, aber andererseits haben jetzt mehrere kundige Leute drübergeschaut, rumprobiert und diskutiert und keiner hat ein grundlegendes Problem erkennen können.

Aber meine Variante benutzt diese Funktion eben nicht, um dem Problem aus dem Weg zu gehen. Letztlich ist deine Lösung sehr ähnlich, nur eben gekapselt in der Klasse TDirectory und als Rückgabe TStringDynArray statt TStringList.

Von "Herumschlagen" kann da also keine Rede sein.

Grüße
Dalai

[Willie1]

Zitat:

Zitat von Dalai (Beitrag 1477493)

Aber meine Variante benutzt diese Funktion eben nicht, um dem Problem aus dem Weg zu gehen. Letztlich ist deine Lösung sehr ähnlich, nur eben gekapselt in der Klasse TDirectory und als Rückgabe TStringDynArray statt TStringList.

Hallo Dalai, ich wollte eure Kompetenz absolut nicht in Frage stellen.
Du hast Recht, man kan auch TStringList nehmen. Das Abfragen der Lw hab' ich schon mit Delphi 6 unternommen nur die Volume-Namen nicht.

Bleibt gesund und schönen Abend
Willie.

[Frickler]

Zitat:

Zitat von hoika (Beitrag 1477445)

PS: Mein JEDI ist schon ziemlich alt.
Viell. wurdeder String-TypeCastbschon gefixt, falls es ein Fehler ist.

Ja. Jetzt gibt es in 3 Funktionen in 3 Units:
In JclAnsiStrings.pas steht procedure MultiSzToStrings(const Dest: TJclAnsiStrings; const Source: PAnsiMultiSz);
In JclWideStrings.pas steht procedure MultiSzToStrings(const Dest: TJclWideStrings; const Source: PWideMultiSz);
In JclStrings.pas steht procedure MultiSzToStrings(const Dest: TStrings; const Source: PMultiSz);

Und in keiner der Varianten werden Strings gecastet.