Parsen von EnvironmentPath

[EWeiss]

Wie würdet ihr vorgehen um den EnvironmentPath zu parsen..?

bsp.
IExplorer setzt seinen Arbeitspfad mit %HOMEDRIVE%%HOMEPATH%..
Den Path stelle ich dann so zur Verfügung.
@%HOMEDRIVE%@%HOMEPATH%

Danach parse ich es auf diese weise.

Delphi-Quellcode:

function TShortCut.ExpandEnvironment(EnvironmentPath: PWideChar): PWideChar;
var
  lpDest: array [0 .. 32768] of WideChar;
begin

  result := '';
  FillChar(lpDest, SizeOf(lpDest), 0);
  if ExpandEnvironmentStrings(PWideChar(EnvironmentPath), lpDest, 32767) <> 0 then
    result := lpDest;
end;

Delphi-Quellcode:

var
  SplitID: TSplitStrArray;
  sTmpWork: WideString;
begin
  sWorkDir := GetExePath(Trim(ParseThis(sBF, ',', 3)), ExtractFilePath(sShellTo));
  SplitID := Split(sWorkDir, '@');
  if (Length(SplitID) > 1) then
  begin
    if (MidStr(SplitID[1], 0, 1) = '%') then
    begin
      sTmpWork := SplitID[1];
      sWorkDir := ExpandEnvironment(PWideChar(sTmpWork));
      if Length(SplitID) > 1 then
      begin
        sTmpWork :=  SplitID[2];
        sWorkDir := sWorkDir + ExpandEnvironment(PWideChar(sTmpWork)) + '\';
      end;
    end;
  end;
end;

Das scheint mir irgendwie zu unsicher..
Könnte ja theoretisch auch nur %HOMEDRIVE% bzw. 3 aneinanderhängende enthalten sein.

Um was es mir geht, suche eine bessere\sichere Lösung den EnvironmentPath zu parsen.
Vielleicht hat ja jemand eine bessere Lösung.
Eventuell über eine schleife oder TStringListe?

gruss

[KodeZwerg]

Ich nutze eine Unit von Delphidabbler für Environment Parsing.
Wenn Dich das Interessieren sollte, hier ist der Link dahin.

[Jasocul]

Ich nutze überhaupt nicht die Environment-Variablen, sondern die API-Funktion SHGetSpecialFolderLocation.
Meine Funktion sieht so aus (irgendwo mal aus dem Internet gefischt und angepasst):

Delphi-Quellcode:

function GetSpecialPath(aCSIDL : Integer) : String;
var
  shellMalloc: IMalloc;
  ppidl: PItemIdList;
begin
  ppidl := nil;
  try
    if SHGetMalloc(shellMalloc) = NOERROR then
    begin
      SHGetSpecialFolderLocation(Application.Handle, aCSIDL, ppidl);
      SetLength(Result, MAX_PATH);
      if not SHGetPathFromIDList(ppidl, PChar(Result)) then
      begin
        Result := '';
      end
      else
      begin
        SetLength(Result, lStrLen(PChar(Result)));
      end;
    end;
  finally
    if ppidl <> nil then
    begin
      shellMalloc.free(ppidl);
    end;
  end;
end;

Eine Liste der CSIDL-Werte ist hier zu finden:
https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx
In deinem Fall müsste es wohl CSIDL_PROFILE sein.

[Schokohase]

Warum so kompliziert? Laut der Doku MSDN: ExpandEnvironmentStrings gilt für den lpSrc Parameter

Zitat:

A buffer that contains one or more environment-variable strings in the form: %variableName%. For each such reference, the %variableName% portion is replaced with the current value of that environment variable.

Also kann man sich das Ganze Aufsplitten sparen und

Delphi-Quellcode:

'%HOMEDRIVE%%HOMEPATH%'

in einem übergeben.

BTW:

Wer mit PWideChar arbeitet sollte auch konsequenterweise mit ExpandEnvironmentStringsW arbeiten, sonst ist bei der nächsten Umstellung (wie bei ANSI auf Unicode) das Geschrei wieder riesengross.

PS:

So würde diese Funktion bei mir aussehen:

Delphi-Quellcode:

function ExpandEnvironment( const AInput: string ): string;
var
  lResult: Cardinal;
begin
  lResult := Winapi.Windows.ExpandEnvironmentStrings( PChar(AInput), nil, 0 );

  if lResult = 0 then
    RaiseLastOSError( );

  SetLength( Result, lResult );
  lResult := Winapi.Windows.ExpandEnvironmentStrings( PChar(AInput), PChar( Result ), lResult );

  if lResult = 0 then
    RaiseLastOSError( );

  SetLength( Result, lResult - 1 );
end;

[KodeZwerg]

Ein wenig gekürzt bei gleicher funktionsweise abgesehen vom Errorcheck

Delphi-Quellcode:

function ExpandEnvironment(const AInput: string): string;
const
  MAXSIZE = 32768;
begin
  SetLength(Result, MAXSIZE);
  SetLength(Result, ExpandEnvironmentStrings(PChar(AInput), @Result[1], Length(Result)) - 1);
end;

edit
Wobei mir Jasoculs Vorschlag in diesen Zusammenhang auch besser gefällt.

[EWeiss]

Zitat:

sollte auch konsequenterweise mit ExpandEnvironmentStringsW arbeiten

Das Macht der Compiler btw. (Delphi) selbst wenn man mit WideChar arbeitet ;)

Danke an alle werde es mal umsetzen..

Zitat:

Wobei mir Jasoculs Vorschlag in diesen Zusammenhang auch besser gefällt.

Die ist aber in dem Kontext nicht anwendbar.

Die übergabe des Arbeitspfad ist nun mal von MS festgelegt die da lautet %HOMEDRIVE%%HOMEPATH% und hat nichts mit einer CSIDL zu tun.
Es geht nicht darum was ich gern möchte sondern was vorgegeben ist.

Code:

"c:\program files (x86)\internet explorer\iexplore.exe, IExplorer, @PATH@UserIcon\48x48\IExplorer.png, @PATH@, , 1"

zu

Code:

"c:\program files (x86)\internet explorer\iexplore.exe, IExplorer, @PATH@UserIcon\48x48\IExplorer.png, %HOMEDRIVE%%HOMEPATH%, , 1"

gruss

[Uwe Raabe]

Zitat:

Zitat von EWeiss (Beitrag 1410539)

IExplorer setzt seinen Arbeitspfad mit %HOMEDRIVE%%HOMEPATH%..
Den Path stelle ich dann so zur Verfügung.
@%HOMEDRIVE%@%HOMEPATH%

Vielleicht eine blöde Frage, aber warum die zusätzlichen @-Zeichen?

Wenn man ExpandEnvironmentStrings('%HOMEDRIVE%%HOMEPATH%') aufruft, bekommt man doch schon direkt das richtige Ergebnis (bei Bedarf vielleicht noch einen Backslash anhängen).

[Jasocul]

Zitat:

Zitat von EWeiss (Beitrag 1410577)

Die ist aber in dem Kontext nicht anwendbar.

Ah, du hast nur die die Environment-Variablen und willst deren Inhalt ermitteln. Dann hast du natürlich recht.

[EWeiss]

Zitat:

Zitat von Uwe Raabe (Beitrag 1410582)

Zitat:

Zitat von EWeiss (Beitrag 1410539)

IExplorer setzt seinen Arbeitspfad mit %HOMEDRIVE%%HOMEPATH%..
Den Path stelle ich dann so zur Verfügung.
@%HOMEDRIVE%@%HOMEPATH%

Vielleicht eine blöde Frage, aber warum die zusätzlichen @-Zeichen?

Wenn man ExpandEnvironmentStrings('%HOMEDRIVE%%HOMEPATH%') aufruft, bekommt man doch schon direkt das richtige Ergebnis (bei Bedarf vielleicht noch einen Backslash anhängen).

Kein blöde frage ;)

Ich habe "@" angehängt um '%HOMEDRIVE%%HOMEPATH%' besser parsen zu können.
Bei split wären das 3 einträge die da wären 0 = "", 1 = "C:" 2 = User\Name.

Ich habe vorher nicht gewusst das man die Environment komplett übergeben kann bei mir kam da Kauderwelsch zu Stande deshalb der Umweg über Split.
Wenn ich über "%" gesplittet hätte wäre das noch umständlicher weil mir dann "%" in den Strings gefehlt hätte.

Zitat:

Ah, du hast nur die die Environment-Variablen und willst deren Inhalt ermitteln. Dann hast du natürlich recht.

Jo in der Verknüpfung steht ja nicht "CSIDL_PROFILE" (C:\Users\username) sondern "%HOMEDRIVE%%HOMEPATH%" (C:\Users\username) ;)

gruss

[EWeiss]

So geht's jetzt!

Delphi-Quellcode:

function TShortCut.ExpandEnvironment(EnvironmentPath: PWideChar): PWideChar;
var
  lpDest: array [0 .. 32768] of WideChar;
begin

  result := '';
  FillChar(lpDest, SizeOf(lpDest), 0);
  if ExpandEnvironmentStringsW(PWideChar(EnvironmentPath), lpDest, 32767) <> 0 then
    result := lpDest;
end;

Delphi-Quellcode:

sTmpWork := GetExePath(Trim(ParseThis(sBF, ',', 3)), ExtractFilePath(sShellTo));
if sTmpWork > '' then
begin
  SplitID := Split(sTmpWork, '\');

  if LeftStr(SplitID[High(SplitID)], 1) = '%' then
    sWorkDir := ExpandEnvironment(PWideChar(SplitID[High(SplitID)] + '\'))
  else
  sWorkDir := sTmpWork;
end else
sWorkDir := sTmpWork;

Danke für die Hilfe

gruss

[Schokohase]

Nur so nebenbei erwähnt:

Also, wenn man bei

Delphi-Quellcode:

'%HOMEDRIVE%%HOMEPATH%'

den Split auf dem

Delphi-Quellcode:

'%'

ausgeführt hätte, dann würde man folgendes erhalten:

Code:

0: ''
1: 'HOMEDRIVE'
2: ''
3: 'HOMEPATH'

Die Variablen-Namen (natürlich ohne die umschließenden %-Zeichen) findet man also an den ungeraden Positionen wieder.

Diese hätte man also auch leicht durchlaufen können und wieder zusammenbauen können.

[EWeiss]

Zitat:

Zitat von Schokohase (Beitrag 1410589)

Nur so nebenbei erwähnt:

Also, wenn man bei

Delphi-Quellcode:

'%HOMEDRIVE%%HOMEPATH%'

den Split auf dem

Delphi-Quellcode:

'%'

ausgeführt hätte, dann würde man folgendes erhalten:

Code:

0: ''
1: 'HOMEDRIVE'
2: ''
3: 'HOMEPATH'

Die Variablen-Namen (natürlich ohne die umschließenden %-Zeichen) findet man also an den ungeraden Positionen wieder.

Diese hätte man also auch leicht durchlaufen können und wieder zusammenbauen können.

Richtig ;)
Habe meine alte Version nicht gegengeprüft.
Das ist dann natürlich falsch!

Zitat:

Bei split wären das 3 einträge die da wären 0 = "", 1 = "C:" 2 = User\Name.

Und genau deshalb weil die %-Zeichen gefehlt haben, habe ich als Delemiter "@" addiert.

Aber gut mir der neuen Version geht es jetzt ohne Probleme.
Muss hier zwar auch parsen aber das ist so sicherer wie vorher. (High(Array))

Falls diese frage noch aufkommt was ist "@PATH@"
@PATH@ ist immer der Arbeitspfad (WorkDir) in dem die Exe liegt wenn nichts anderes angegeben wurde.
Ist also eine globale variable für alle Verknüpfungen.

gruss und Danke nochmals

[Uwe Raabe]

Mag sein, daß es hier nicht relevant ist, weil der Rückgabewert gleich weiterverarbeitet wird, aber zeigt der Result von ExpandEnvironment nicht auf eventuell ungültigen Stackspeicher? lpDest liegt doch als lokale Variable auf dem Stack und der wird beim Verlassen der Methode freigegeben. (Mal abgesehen davon, daß der Methodenaufruf mal eben so 64k vom Stack abzwackt.)

Delphi-Quellcode:

function TShortCut.ExpandEnvironment(EnvironmentPath: PWideChar): PWideChar;
var
  lpDest: array [0 .. 32768] of WideChar;
begin

  result := '';
  FillChar(lpDest, SizeOf(lpDest), 0);
  if ExpandEnvironmentStringsW(PWideChar(EnvironmentPath), lpDest, 32767) <> 0 then
    result := lpDest;
end;

[Fritzew]

Zitat:

Zitat von Uwe Raabe (Beitrag 1410596)

Mag sein, daß es hier nicht relevant ist, weil der Rückgabewert gleich weiterverarbeitet wird, aber zeigt der Result von ExpandEnvironment nicht auf eventuell ungültigen Stackspeicher? lpDest liegt doch als lokale Variable auf dem Stack und der wird beim Verlassen der Methode freigegeben. (Mal abgesehen davon, daß der Methodenaufruf mal eben so 64k vom Stack abzwackt.)

Sowas kann Dir immer um die Ohren fliegen, je nachdem wie es weiterverarbeitet wird. Das wird bei uns als schwerer Fehler gewichtet und wenn man das öfter produziert steht wohl ein ernsthaftes Gespräch an. :-)

[EWeiss]

Zitat:

Zitat von Uwe Raabe (Beitrag 1410596)

Mag sein, daß es hier nicht relevant ist, weil der Rückgabewert gleich weiterverarbeitet wird, aber zeigt der Result von ExpandEnvironment nicht auf eventuell ungültigen Stackspeicher? lpDest liegt doch als lokale Variable auf dem Stack und der wird beim Verlassen der Methode freigegeben. (Mal abgesehen davon, daß der Methodenaufruf mal eben so 64k vom Stack abzwackt.)

Delphi-Quellcode:

function TShortCut.ExpandEnvironment(EnvironmentPath: PWideChar): PWideChar;
var
  lpDest: array [0 .. 32768] of WideChar;
begin

  result := '';
  FillChar(lpDest, SizeOf(lpDest), 0);
  if ExpandEnvironmentStringsW(PWideChar(EnvironmentPath), lpDest, 32767) <> 0 then
    result := lpDest;
end;

Hmmm nun wie geht's besser ?
Mal davon abgesehen das mein Array schon immens definiert ist.
Könnte das Array dynamisch machen so wie von @Schokohase vorgeschlagen.

gruss

[Uwe Raabe]

Zitat:

Zitat von EWeiss (Beitrag 1410605)

Hmmm nun wie geht's besser ?
Mal davon abgesehen das mein Array schon immens definiert ist.
Könnte das Array dynamisch machen so wie von @Schokohase vorgeschlagen.

Das hätte den Nachteil, daß du den Speicher in der aufrufenden Methode wieder freigeben musst.

Ich würde es mir da ganz einfach machen und statt dessen überall mit

Delphi-Quellcode:

string

arbeiten, wo es die Windows-API nicht ausdrücklich anders vorschreibt.

[EWeiss]

Zitat:

Zitat von Uwe Raabe (Beitrag 1410612)

Zitat:

Zitat von EWeiss (Beitrag 1410605)

Hmmm nun wie geht's besser ?
Mal davon abgesehen das mein Array schon immens definiert ist.
Könnte das Array dynamisch machen so wie von @Schokohase vorgeschlagen.

Das hätte den Nachteil, daß du den Speicher in der aufrufenden Methode wieder freigeben musst.

Ich würde es mir da ganz einfach machen und statt dessen überall mit

Delphi-Quellcode:

string

arbeiten, wo es die Windows-API nicht ausdrücklich anders vorschreibt.

Ok Danke werde es ändern.

Delphi-Quellcode:

function TShortCut.ExpandEnvironment(const EnvironmentPath: string): string;
var
  lpDest: array [0 .. 32768] of WideChar;
begin

  result := '';
  FillChar(lpDest, SizeOf(lpDest), 0);
  if ExpandEnvironmentStringsW(PWideChar(EnvironmentPath), lpDest, 32767) <> 0 then
    result := lpDest;
end;

gruss

[Schokohase]

Nur so zur Info:

Bei

Delphi-Quellcode:

string

nimmt man

Delphi-Quellcode:

PChar

und den API Aufruf ohne A oder W am Ende.

[EWeiss]

Zitat:

Zitat von Schokohase (Beitrag 1410660)

Nur so zur Info:

Bei

Delphi-Quellcode:

string

nimmt man

Delphi-Quellcode:

PChar

und den API Aufruf ohne A oder W am Ende.

Das geht hier leider nicht unter D7 Ja!
Wenn ich PChar in D2010 verwende wird PChar automatisch nach PWideChar gecastet.
Also gebe ich direkt den richtigen Typ an ;)

gruss

[Schokohase]

Delphi-Quellcode:

string

bei < D2009 ist

Delphi-Quellcode:

AnsiString

.

Delphi-Quellcode:

string

bei >= D2009 ist

Delphi-Quellcode:

UnicodeString

.

Delphi-Quellcode:

PChar

bei < D2009 ist

Delphi-Quellcode:

PAnsiChar

.

Delphi-Quellcode:

PChar

bei >= D2009 ist

Delphi-Quellcode:

PWideChar

.

Es wird also automatisch umgeschaltet, je nach Version (kann man im Source auch nachlesen).

Nur wenn du immer Ansi/Unicode habe willst, aber dann ist

Delphi-Quellcode:

string

auf jeden Fall nicht korrekt

[EWeiss]

Zitat:

Zitat von Schokohase (Beitrag 1410667)

Delphi-Quellcode:

string

bei < D2009 ist

Delphi-Quellcode:

AnsiString

.

Delphi-Quellcode:

string

bei >= D2009 ist

Delphi-Quellcode:

UnicodeString

.

Delphi-Quellcode:

PChar

bei < D2009 ist

Delphi-Quellcode:

PAnsiChar

.

Delphi-Quellcode:

PChar

bei >= D2009 ist

Delphi-Quellcode:

PWideChar

.

Es wird also automatisch umgeschaltet, je nach Version (kann man im Source auch nachlesen).

Nur wenn du immer Ansi/Unicode habe willst, aber dann ist

Delphi-Quellcode:

string

auf jeden Fall nicht korrekt

Ja deshalb ja auch mein Einwand.. (Es wird also automatisch umgeschaltet)
Warum soll ich es umschalten lassen wenn ich den Typ bereits kenne dann übergeben ich den richtigen direkt.

Nun mit dem string!
Die Api erwartet nun mal PWideChar von daher muss ich auch hier konvertieren.. Uwe meinte das wäre korrekt so :)

gruss

[Uwe Raabe]

Zitat:

Zitat von Schokohase (Beitrag 1410667)

Nur wenn du immer Ansi/Unicode habe willst, aber dann ist

Delphi-Quellcode:

string

auf jeden Fall nicht korrekt

Das ist richtig! Wenn der Code auch unter D2007 und kleiner laufen muss, dann ist

Delphi-Quellcode:

string

nicht die richtige Lösung. Da in deinem Profil D2010 steht, bin ich natürlich auch davon ausgegangen.

Wenn es denn auch in diesen alten Versionen immer

Delphi-Quellcode:

WideChar

sein soll, dann muss die Speicherverwaltung dafür eben auch selbst programmiert werden. In D7 gibt es halt keinen Unicode fähigen string-Typ. Da muss man dann alles selbst von Hand machen.

[EWeiss]

Zitat:

Da in deinem Profil D2010 steht, bin ich natürlich auch davon ausgegangen.

Ja ich verwende D2010 und gehe davon aus das dein Tip so korrekt ist.
Ab D2010 ist ein String ein mächtiges Werkzeug von daher ist das schon IO..
Unter D2010 den Quelltext zu kompilieren ist nicht sinnvoll da ich Generics verwende die gibt es auch erst ab dieser Version.

gruss