TDirectory.GetLogicalDrives

[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 von hoika:

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 von Dalai:

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.