![]() |
AW: TDirectory.GetLogicalDrives
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:
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.
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; 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. |
AW: TDirectory.GetLogicalDrives
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:
Was ich eigentlich meinte, wäre es könnte entweder heissen:
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; 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. |
AW: TDirectory.GetLogicalDrives
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. |
AW: TDirectory.GetLogicalDrives
Halo,
ich poste hier mal den JEDI-Code.
Delphi-Quellcode:
Vielleicht ist das StrLen ja falsch.
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; Wenn die JEDI auch abschmiert, hat dein Puffer nicht die #0#0 am Ende oder der letzte String nicht das #0. |
AW: TDirectory.GetLogicalDrives
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) |
AW: TDirectory.GetLogicalDrives
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. |
AW: TDirectory.GetLogicalDrives
Zitat:
Da die Unit ja ein paar zusätzliche Funktionen bereitstellt, kann man kann die Funktion DriveDisplayNames auch so schreiben:
Delphi-Quellcode:
Das funktioniert bei mir zuverlässig und ohne AV nach dem x-ten Aufruf.
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; @Willie1: Such dir einen Weg aus, es sind ja bereits genügend Varianten gepostet worden. Grüße Dalai |
AW: TDirectory.GetLogicalDrives
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. |
AW: TDirectory.GetLogicalDrives
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 |
AW: TDirectory.GetLogicalDrives
Zitat:
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. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:20 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz