Application Path

[Gutelo]

Wenn man keine relativen Pfade verwendet dann ist Programm so portabel wie der Eifelturm. Links unter Windows halte ich ehrlich gesagt fuer wenig sinnvoll, ausgenommen Verknuepfungen auf dem Desktop. Kann mir aber kaum vorstellen dass Delphi in dem Falle eines Aufrufs ueber einen Link den Pfad des Links zurueckgibt.

Ich werde mal testen wo der Pfad steht wenn ich das Programm im User Verzeichnis ausfuehre und dann bescheidgeben.

[Dalai]

Zitat von Gutelo:

Wenn man keine relativen Pfade verwendet dann ist Programm so portabel wie der Eifelturm.

Offensichtlich hast du etwas falsch verstanden. Es geht darum, dass du dir aus Variablen - ggf. unter Zuhilfenahme entsprechender API-Funktionen wie SHGetFolderPath, SHGetKnownFolderPath und Konsorten - absolute Pfade, die je nach System passen, zusammenbaust. Du sollst keine hartkodierten Pfade benutzen, die noch schlimmer sind als relative Pfade. Ich gebe dir Recht, dass der Hinweis auf hartkodierte Pfade in jaenickes Beitrag fehlt, denn da kommt man IMO sofort drauf, wenn von relativen Pfaden abgeraten wird.

MfG Dalai

[Der schöne Günther]

Kommen wir nochmal zu den "Datei öffnen"-Dialogen zurück. Die sind bislang aber auch die einzige Ausnahme, oder?

[himitsu]

Zitat von Der schöne Günther:

Kommen wir nochmal zu den "Datei öffnen"-Dialogen zurück. Die sind bislang aber auch die einzige Ausnahme, oder?

Nöö.
Auch die "Art" des Aufrufs/Starts des Programms ist entscheidend.


Im Prinzip kann einem das bei vielen (Fremd)Komponenten/-Codes passieren, welche mit Zugriffen auf die Festplatte arbeiten.

Grundsätzlich muß sollte man so sowieso immer davon ausgehen, daß "externe" Einstellung/Daten nicht als gegeben/konstant angesehen werden können.

[Gutelo]

hmm, irgendwie beisst sich die Katze doch in den eigenen Schwanz. Entweder verzichtet man auf die Verwendung des "hardkodierten Pfades" und kann das Programm ueberhaupt nicht mehr Verschieben nach der Installation, oder man verwendet Sie mit der Gefahr dass sich der Wert der Variablen aendert. Letzteres impliziert dass man jedes Mal oben angesprochene Sicherheitsabfragen durchfuehren muss und gegebenenfalls darauf angewiesen ist den gesammten Verzeichnisbaum des Laufwerks zu durchsuchen.

Es ist Aufgabe von Embacedero sicherzustellen dass diese Funktion macht was Sie machen soll. Ehrlichgesagt sollte es simpel sein das Verzeichnis bei Ausfuehren des Programms so zu speichern dass der Wert durch andere Operationen nicht veraendert wird. Klingt eher wie ein Major Bug in Delphi.

[himitsu]

Nein.

relative Pfade sind böse
und
hardcodierte Pfade genauso
(vorwie aus dem Grund, weil es bescheuerte Programmierer gab, welche Pfade hardcodierten, spricht das Verzeichnissystem nun englisch und der Benutzer sieht aber was Anderes)

Man fragt Windows nach den benötigten Verzeichnissen und verwendet diese für die Zugriffe mit den resulierenden absoluten Pfaden.


Es ist nicht die aufgabe von Embarcadero.
Ganz im Gegenteil.
Das ist ein normales Verhalten seitens des Betriebssystems.
Vorallem das Verhalten, daß bei Programmstart das Arbeitsverzeichnis nicht dem Programmverzeichnis entsprechen muß.

[jaenicke]

Zitat von Gutelo:

Es ist Aufgabe von Embacedero sicherzustellen dass diese Funktion macht was Sie machen soll. Ehrlichgesagt sollte es simpel sein das Verzeichnis bei Ausfuehren des Programms so zu speichern dass der Wert durch andere Operationen nicht veraendert wird.

Du hast einmal das Anwendungsverzeichnis (Application.ExeName oder ParamStr(0)) und du hast einmal das aktuelle Arbeitsverzeichnis (GetCurrentDir). Das ist nun einmal nicht das gleiche.

Der Fehler liegt nicht in Delphi oder bei Embarcadero, wenn diese Funktionen falsch benutzt werden...

// EDIT:

Zitat von Der schöne Günther:

Genau das wollte ich wissen Gibt es denn bekannte Fälle?

Datenbankzugriffskomponenten, Fremddialoge, ...
Da gibt es einige Möglichkeiten.

Zitat von Der schöne Günther:

Bislang habe hole mir oft dynamisch das Arbeitsverzeichnis (ohne es je selbst zu ändern) und bastele mir damit dann eine absolute Pfadangabe zusammen.

Solange du damit auch das aktuelle Arbeitsverzeichnis ansprechen willst und nicht das Verzeichnis der Anwendung ist doch alles in Ordnung.

[Perlsau]

Da bei einigen offenbar rege Begriffsverwirrung herrscht, möchte ich das bisher Gesagte noch einmal zusammenfassen:

Das Anwendungsverzeichnis ändert sich nicht, während das Programm läuft:

Delphi-Quellcode:

Anwendungsverzeichnis := SysUtils.ExtractFilePath(System.ParamStr(0));
Anwendungsverzeichnis := SysUtils.ExtractFilePath(Forms.Application.ExeName);

Das Arbeitsverzeichnis kann sich während des Programmlaufs jedoch ändern, z.B. durch einen Aufruf von OpenDialg oder SaveDialog:

Delphi-Quellcode:

Arbeitsverzeichnis := SysUtils.GetCurrentDir;

Wenn ich im Programm ein festes Verzeichnis benötige, das sich nicht ändern soll, dann lege ich dieses Verzeichnsi beim Programmstart fest, z.B. den Ort, an dem die benötigte Firebird-Datenbank zu finden ist:

Delphi-Quellcode:

Const
  DB_Datei = 'MeineDatenbank.FDB';
Var
  DB_DateiName,
  DB_DateiPfad : String;

Diesen Speicherort ermittle ich entweder durch einen OpenDialog oder lege ihn in einer Ini-Datei fest (das kann auch ein einfaches Ascii-File mit nur einer Zeile sein). Diese Ini-Datei speichere ich nur dann im Anwendungsverzeichnis, wenn

1. sie nicht vom Programm verändert zurückgeschrieben werden soll und/oder
2. es sich um eine portable Anwendung handelt, die sich nicht in einem der Windows-Systemordner befindet.

Ansonsten speichert man Ini-Dateien (und andere, die man benötigt) im Benutzer-Verzeichns, und zwar bei:

WinXP entweder unter \AllUsers\Anwendungsdaten oder \[CurrentUser]\Anwendungsdaten
Win7 entweder unter \Users\Public\Documents\MeineAnwendungsDaten\ oder entsprechend unter \Users\[CurrentUser]\
Win 8 weiß ich nicht, hab ich nicht ...

Oder man setzt entsprechende Registry-Einträge und erfährt dann aus der Registry alle notwendigen festen Verzeichnisse.

[Der schöne Günther]

Zitat von himitsu:

Auch die "Art" des Aufrufs/Starts des Programms ist entscheidend.

Das ist glaube ich jedem klar.

Aber:

Zitat von himitsu:

Im Prinzip kann einem das bei vielen (Fremd)Komponenten/-Codes passieren, welche mit Zugriffen auf die Festplatte arbeiten.

Genau das wollte ich wissen Gibt es denn bekannte Fälle?

Im Endeffekt bin ich nur faul und würde gerne wissen, ob ich weiterhin ruhig schlafen kann oder die Sache doch möglichst bald angehen sollte: Bislang habe hole mir oft dynamisch das Arbeitsverzeichnis (ohne es je selbst zu ändern) und bastele mir damit dann eine absolute Pfadangabe zusammen. Wenn mir nun irgendetwas ohne mein Wissen das Arbeitsverzeichnis ändert ist das natürlich nicht nett