ExpandFileName gibt "falsches" Ergebnis aus

[Ykcim]

Hallo Zusammen,

die Funktion ExpandFileName gibt ein unerwartetes Ergebnis aus, welches ich nicht verstehe.

Ich habe in dem Ordner, in welcher die Exe-Datei liegt weitere Ordner, unter anderem den Ordner RES. Aus diesem Ordner soll eine Datei geladen werden, die auch vorhanden ist.

Pfad der Exe-Datei

Code:

'D:\Software_Entwicklung\VersandApp\VersandApp\BD_VersandClient\Win32\Debug\BD_DHL.exe'

Jetzt möchte ich folgende Datei laden:

Code:

'D:\Software_Entwicklung\VersandApp\VersandApp\BD_VersandClient\Win32\Debug\Res\PDF_View.fr3'

Dazu verwende ich die ExpandFileName Funktion:
Report.LoadFromFile(ExpandFileName('.\Res\PDF_View.fr3'));
Und dann gibt ExpandFileName den Pfad

Code:

'D:\XML\Res\PDF_View.fr3'

aus. Diesen Pfad gibt es gar nicht, den im Ordner D:\XML gibt es keine weiteren Unterordner...

Ich hatte diesen Pfad erwartet:

Code:

'D:\Software_Entwicklung\VersandApp\VersandApp\BD_VersandClient\Win32\Debug\Res\PDF_View.fr3'

Habe ich die Funktion falsch verstanden - ich verwende sie öfters, ohne je Probleme gehabt zu haben...

NACHTRAG:
Es ist verrückt, aber ich arbeite gerade an einer Client Server App. Das Problem, dass ich hier beschrieben habe, entsteht in der ClientApp. Ich hatte in der Liste der überwachten Ausdrücke einen Ausdruck ExpandFileName('./Res/PDF_View.fr3'), also hardgecodet und nicht mit Variablenamen. Und in der ServerApp gibt er den richtigen Wert zurück:

Code:

'D:\Software_Entwicklung\VersandApp\VersandApp\BD_VersandServer\Win32\Debug\Res\PDF_View.fr3'

Den Ordner gibt es in der ServerApp nicht, sondern nur in der ClientApp, aber der Pfadaufbau ist der richtige.

Beide Funktionen greifen auf die System.SYSUtils zu, also da gibt es keinen Unterschied...

Ich bin verwirrt....

Vielen Dank
Patrick

[himitsu]

Das Ding müsste vom "aktuellen Arbeitsverzeichnis" ausgehn (jeweils für den aktuellen Thread).

Meistens Oft das Verzeichnis der EXE,
außer man startet die EXE nicht von ihrem Verzeichnis aus,
oder man wechselt es ... PS: rate mal, was der böse Datei-Öffnen/Speichern-Dialog standardmäßig macht.

Fazit: vorher in das Verzeichnis wechseln.

ChDir
SetCurrentDir
TDirectory.SetCurrentDirectory
SetCurrentDirectory


Falls du Angst hast, dass irgendwo was bei kaputt geht ...

Delphi-Quellcode:

var CurPath := TDirectory.GetCurrentDirectory;
TDirectory.SetCurrentDirectory(TPath.GetLibraryPath);  //TDirectory.SetCurrentDirectory(TPath.GetDirectoryName(Application.ExeName));
deinGewünschterPfad := TPath.GetFullPath('.\Res\PDF_View.fr3');
TDirectory.SetCurrentDirectory(CurPath);

Ich hätte dir noch eine Alternative anbieten wollen, aber die ist "kaputt" und es wird sie auch nie geben.
https://embt.atlassian.net/servicede...tal/1/RSS-2138
[edit] Ups, falscher Link.
https://embt.atlassian.net/servicede...tal/1/RSS-2139

Und dort erwähnte GetFullPath macht das Gleiche, wie ExpandFileName, nur noch schlimmer.

[Olli73]

Da gehe ich Mal davon aus, dass dein aktuelles Arbeitsverzeichnis (GetCurrrentDir) "D:\XML" ist ...

[Dalai]

Das ist gar nicht verwunderlich, denn

Zitat von https://docwiki.embarcadero.com/Libraries/Athens/de/System.SysUtils.ExpandFileName:

ExpandFileName konvertiert einen relativen Dateinamen in einen vollständigen Pfadnamen, indem dem Dateinamen das aktuelle Verzeichnis und das aktuelle Laufwerk hinzugefügt werden. ExpandFileName prüft nicht, ob der Rückgabewert auf eine vorhandene Datei verweist.

[Ykcim]

Hallo Zusammen,

vielen Dank für Eure Antworten!

Der Fehler tritt beim Debuggen auf. Ich habe die Client und die Server App in einer Projektgruppe. Wenn ich in der Server App GetCurrentDir im Haltepunkt abfrage ist das Ergebnis:
'D:\Software_Entwicklung\VersandApp\VersandApp\BD_ VersandServer\Win32\Debug' "KORREKT"

Wenn ich GetCurrentDir in der Client App (auch beim debuggen) abfrage ist das Ergebnis:
'D:\XML' "FALSCH"

Wovon hängt denn das "aktuelle Arbeitsverzeichnis" ab? Und worauf bezieht sich das Arbeitsverzeichnis. Es kann ja nicht der Rechner sein, denn beide Apps werden in der gleichen Delphi-Sesson gerade gedebugged...

NACHTRAG:
ich habe eine Idee: Ich habe in der ClientApp tatsächlich einen OpenDialog, der sich auf dieses Verzeichnis bezieht. Kann es sein, dass dadurch CurrentDir gesetzt wird. Dann würde ich die Funktion lieber nicht mehr verwenden wollen, man weiß ja nie, ob irgendwann ein solcher Dialog ins Programm kommt. Verwendet Ihr die Funktion? und wenn ja, wie?

LG Patrick

[TomyN]

Hi,
Ich würde mir das exe Verzeichnis holen und darauf aufbauend den Pfad erzeugen. Das mit dem ExpandFileName ist mehr oder weniger ein Glücksspiel.
Nach meinem Verständnis würden solche Daten auch eher in andere Verzeichnisse (Dokumente, App Data o.ä. ) gehören, gerade auch weil windows immer strenger über die Programmverzeichnisse wacht.

[Ykcim]

Vielen Dank für die Hilfe und Erklärungen!

Ich habe es jetzt so gelöst, wie himitsu es eigentlich schon erklärt - ich nur übersehen hatte...

Delphi-Quellcode:

SetCurrentDir(ExtractFilePath(Application.Exename));
   Report.LoadFromFile(ExpandFileName(Report_Path));

Damit funktioniert es.

Aber richtig toll finde ich es nicht und überlege mir, die Pfade tatsächlich auf dem Programmpfad aufbauend zu gestalten. Nur muss ich dann das "\" am Ende überprüfen und ich kann nicht den gleichen Code verwenden, wenn in der Config-Datei mal ein Pfad \\Server\Ordner\Datei.igw und manchmal .\Ordner\Datei.igw angegeben wird...

Das wäre mit ExpandFileName so schön einfach gewesen...

LG Patrick

[himitsu]

Wie gesagt, der FileDialog macht es standardmäßig gern.
Kann man (oftmals) deaktivieren, indem man in dessen Optionen den Filetest deaktiviert .... aber sicher ist das nicht.

Und es kann durch vieles passieren.
z.B. wie und von du das Programm startest.

* siehe Delphi -> Start -> Parameter (Arbeitsverzeichnis)

* oder bei einem Link im Windows (siehe "Ausführen in")

* oder aus einer Batch
CMD:

Code:

cd /d D:\XML
D:\Software_Entwicklung\VersandApp\VersandApp\BD_VersandClient\Win32\Debug\BD_DHL.exe

cd /d D:\Software_Entwicklung\VersandApp\VersandApp\BD_VersandClient
Win32\Debug\BD_DHL.exe

.\Win32\Debug\BD_DHL.exe

versus

Code:

cd /d D:\Software_Entwicklung\VersandApp\VersandApp\BD_VersandClient\Win32\Debug
BD_DHL.exe

cd /d D:\Software_Entwicklung\VersandApp\VersandApp\BD_VersandClient\Win32\Debug
D:\Software_Entwicklung\VersandApp\VersandApp\BD_VersandClient\Win32\Debug\BD_DHL.exe

oder
oder
oder

Du weißt z.B. auch nie, was eine Fremdkomponente in deinem Programm jetzt/irgendwann macht.

z.B. Acrobat via ActiveX in der eigenen Anwendung ... sowas ergibt immer wieder sehr viel Spaß



Darum wird auch immer wieder von abgeraten, dass man mit relativen Pfaden arbeitet.
Und genau genommen nutzt du hier einen relativen Pfad, abhängig ausgehend von dem "zufälligen" Arbeitsverzeichnis.

[Dalai]

Zitat von Ykcim:

Nur muss ich dann das "\" am Ende überprüfen und ich kann nicht den gleichen Code verwenden, wenn in der Config-Datei mal ein Pfad \\Server\Ordner\Datei.igw und manchmal .\Ordner\Datei.igw angegeben wird...

IncludeTrailingPathDelimiter bzw. ExcludeTrailingPathDelimiter?

[Ykcim]

Vielen Dank,
IncludeTrailingPathDelimiter vereinfact das sehr, ersetzt aber nicht die schöne Funktion ExpandFileName.

Wäre cool, wenn man ExpandFileName einen optionalen Parameter mit dem Start-Verzeichnis mitgeben könnte. Standardmäßig das Arbeitsverzeichnis, oder ein Beliebiges, wie ExtractFilePath(ParamStr(0)), dann wäre sie sicher einsetzbar...

ExpandFileName(relativePfadVariable, ExtractFilePath(ParamStr(0)));

Spinnerei...

Vielen Dank und lieben Gruß - ich habe wieder etwas gelernt.

Patrick