Parsen von EnvironmentPath

[Schokohase]

Nur so nebenbei erwähnt:

Also, wenn man bei '%HOMEDRIVE%%HOMEPATH%' den Split auf dem '%' 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 von Schokohase:

Nur so nebenbei erwähnt:

Also, wenn man bei '%HOMEDRIVE%%HOMEPATH%' den Split auf dem '%' 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 von 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.)

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 von 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;

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

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 string arbeiten, wo es die Windows-API nicht ausdrücklich anders vorschreibt.

[EWeiss]

Zitat von Uwe Raabe:

Zitat von EWeiss:

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 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 string nimmt man PChar und den API Aufruf ohne A oder W am Ende.

[EWeiss]

Zitat von Schokohase:

Nur so zur Info:

Bei string nimmt man 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]

string bei < D2009 ist AnsiString .
string bei >= D2009 ist UnicodeString .

PChar bei < D2009 ist PAnsiChar .
PChar bei >= D2009 ist 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 string auf jeden Fall nicht korrekt