Pfad zu einer Datei herausfinden

[VizeTE]

Hallo,

unter Windows kann ich doch einfach eine Datei ohne Angabe des Pfades öffnen.
Windows sucht dann zunächst im Ausführungsverzeichnis, dann im den Verzeichnissen
in der Windwos-Path-Variabeln und was weiß ich wo noch alles.

Wenn ich auf dieser Weise eine Datei geöffnet habe gibt es dann einen Weg
den Pfad auf die Datei herauszubekommen?


Danke schon mal

[himitsu]

Zitat von VizeTE:

unter Windows kann ich doch einfach eine Datei ohne Angabe des Pfades öffnen.

ja

Zitat von VizeTE:

Windows sucht dann zunächst im Ausführungsverzeichnis, dann im den Verzeichnissen
in der Windwos-Path-Variabeln und was weiß ich wo noch alles.

nein

Es kommt drauf an, wie du die Datei öffnest.

DLLs via LoadLibrary werden z.B. so gesucht.
Aber z.B. AssignFile oder Stream.LoadFromFile öffnet dagegen immer nur im aktuellen Programmverzeichnis.

Zitat von VizeTE:

Wenn ich auf dieser Weise eine Datei geöffnet habe gibt es dann einen Weg
den Pfad auf die Datei herauszubekommen?

ich würde einfach das aktuelle Programmverzeichnis auslesen
> GetCurrentDir und Co.

[Muetze1]

Zitat von himitsu:

Zitat von VizeTE:

Windows sucht dann zunächst im Ausführungsverzeichnis, dann im den Verzeichnissen
in der Windwos-Path-Variabeln und was weiß ich wo noch alles.

nein

Es kommt drauf an, wie du die Datei öffnest.

DLLs via LoadLibrary werden z.B. so gesucht.
Aber z.B. AssignFile oder Stream.LoadFromFile öffnet dagegen immer nur im aktuellen Programmverzeichnis.

Bei DLLs kann man es explizit umstellen bzw. festlegen ob dieser Vorgang gemacht werden soll. Die Angabe irgendeines Pfades vor dem DLL Namen bei LoadLibrary() setzt die schon außer Kraft (also auch z.B. ein ".\").

Und Programmverzeichnis ist in diesem Falle falsch sondern einfach nur aktuelles Verzeichnis. Das Programmverzeichnis ist es schon nach dem nächsten Open- oder Savedialog nicht mehr, wenn der Nutzer das Verzeichnis und/oder Laufwerk wechselt.

[joachimd]

Zitat von VizeTE:

unter Windows kann ich doch einfach eine Datei ohne Angabe des Pfades öffnen.
Windows sucht dann zunächst im Ausführungsverzeichnis, dann im den Verzeichnissen
in der Windwos-Path-Variabeln und was weiß ich wo noch alles

SearchPath

[VizeTE]

Zitat von Muetze1:

Zitat von himitsu:

Zitat von VizeTE:

Windows sucht dann zunächst im Ausführungsverzeichnis, dann im den Verzeichnissen
in der Windwos-Path-Variabeln und was weiß ich wo noch alles.

nein

Es kommt drauf an, wie du die Datei öffnest.

DLLs via LoadLibrary werden z.B. so gesucht.
Aber z.B. AssignFile oder Stream.LoadFromFile öffnet dagegen immer nur im aktuellen Programmverzeichnis.

Bei DLLs kann man es explizit umstellen bzw. festlegen ob dieser Vorgang gemacht werden soll. Die Angabe irgendeines Pfades vor dem DLL Namen bei LoadLibrary() setzt die schon außer Kraft (also auch z.B. ein ".\").

Und Programmverzeichnis ist in diesem Falle falsch sondern einfach nur aktuelles Verzeichnis. Das Programmverzeichnis ist es schon nach dem nächsten Open- oder Savedialog nicht mehr, wenn der Nutzer das Verzeichnis und/oder Laufwerk wechselt.

Ok, das hätte ich dazuschreiben können: Es handelt sich nicht um eine dll sondern um eine ini. Wenn ich dort bei TIniFile.Create(...) als Parameter "myini.ini" angebe wird die Datei geöffnet auch wenn sie z.B. im Windows-Verzeichnis liegt.

Zitat von joachimd:

Zitat von VizeTE:

unter Windows kann ich doch einfach eine Datei ohne Angabe des Pfades öffnen.
Windows sucht dann zunächst im Ausführungsverzeichnis, dann im den Verzeichnissen
in der Windwos-Path-Variabeln und was weiß ich wo noch alles

SearchPath

Ja, genau das habe ich gesucht: Vollständiger Dateiname gemäss PATH
Danke!

[himitsu]

eine INI ohne Pfadangabe landet im Windows-Verzeichnis (z.B. "C:\Windows" und so)

Zitat:

If this parameter does not contain a full path to the file, the system searches for the file in the Windows directory.

> GetPrivateProfileString

[MarcoWarm]

Zitat von himitsu:

eine INI ohne Pfadangabe landet im Windows-Verzeichnis (z.B. "C:\Windows" und so

Das stimmt nur bedingt. Um die Sache komplizierter zu machen, gibts ab WinXP so genannte IniFileMappings (zu finden unter

Code:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\IniFileMapping

Wenn du also TIniFile.Create('Win.ini') sagst, landest du eigentlich in der Registry Die Datei ist (laut kommentar in selbiger) nur noch für 16 Bit zuständig.

Gruß
Marco

[himitsu]

IniFileMappings:
joar, wo man ab Vista ja eh keine Schreibrechte mehr im Windowsverzeichnis hat ....

aber virtuell liegen diese Daten dann dennoch in C:\Windows



nja, ich sagt'e ja: "es kommt drauf an was man wie speichert" und dann gibt es davon abhängig verschiedene Orte.

[MarcoWarm]

Zitat von himitsu:

aber virtuell liegen diese Daten dann dennoch in C:\Windows

Die Daten liegen weder virtuell noch real in C:\Windows, weil es einfach keine Ini Datei gibt.

edit... aber egal... das wird mir dann doch zu philosophisch...
edit2 ... himitsu hat ja recht

Zitat von msdn:

lpFileName [in]

The name of the initialization file. If this parameter does not contain a full path to the file, the system searches for the file in the Windows directory.