Parsen von EnvironmentPath

[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