TDirectory.GetLogicalDrives

[Delphi.Narium]

Zitat von Dalai:

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)