Application Path

[xthing]

Hi Leute,

wie kann ich den Applikationspfad meiner Anwendung in Delphi herausfinden? Irgendwie mit extractpath, oder so ähnlich?

Könnt ihr mir helfen?

Vielen Dank im voraus.

Gruss
xthing

[Klaus01]

das ist:

Zitat:

Returns the drive and directory portions of a file name.

Unit

SysUtils

Category

file name utilities

function ExtractFilePath(const FileName: string): string;

Description

The resulting string is the leftmost characters of FileName, up to and including the colon or backslash that separates the path information from the name and extension. The resulting string is empty if FileName contains no drive and directory parts.

Note: This function works for multi-byte character systems (MBCS).

ist aber auch in der Hilfe zu finden.

Grüße
Klaus

[Gollum]

Hallo,

Delphi-Quellcode:

ExtractFilePath(Application.ExeName)

oder

Delphi-Quellcode:

ExtractFilePath(ParamStr(0))

[Gutelo]

Dazu haette ich noch eine Frage

Bei mir klappt das mit dem Pfad so lange ich in der Entwicklungsumgebung bin. Kopiere ich jedoch das kompilierte Programm Main.exe mitsamt einem Unterverzeichnis (im gleichen Ordner wie Main.exe) in irgendein anderes Verzeichnis und fuehre es aus, dann findet das Programm den Unterordner nicht mehr. Das heisst ExtractFilePath(Application.ExeName) entspricht dann nicht mehr dem Pfad zur Main.exe.

Wieso ist das so? Ich dachte ExtractFilePath(Application.ExeName) gibt immer den Pfad zur Main.exe zurueck auch wenn ich Main.exe an beliebige Orte auf der Platte kopiere.

Gutelo

[jaenicke]

Das ist auch so. Wo liegt denn dein Programm und was wird dort zurück gegeben?

Ein Beispiel:
c:\programme ist ab Vista nur eine Umleitung auf c:\program files, so dass du letzteres zurück bekommst.

[Perlsau]

Kommt drauf an: Wenn du dein Release-Verzeichnis z.B. in C:\Program Files\ kopierst, hast du dort in der Regel keine Schreibrechte. Deshalb "biegen" neuere Windows-Versionen den Programmpfad um und schreiben in Wirklichkeit in einen öffentlichen Pfad. Das ist natürlich falsch! Jaenicke hat es oben korrekt dargestellt ...

Eine portable Anwendung sollte allerdings, da sie ja nicht in einem der System-Ordner liegt, durchaus in ihr Programmverzeichnis schreiben dürfen.

Dazu hat Jaenicke bereits vor 5 Jahren etwas in der Entwicklerecke geschrieben:

Eine Anwendung - gleichzeitig portabel UND installierbar
Nicht in den Ordner der Exe schreiben

[Gutelo]

Hallo ich habs gerade nochmal ausprobiert.

Wenn ich es unter C:\users\userxyz\Downloads\Unterordner\ packe dann geht es nicht. Wenn ich es irgendwo auf D:\ packe dann geht es. Anscheinend gibt es in den User Ordnern Probleme.

[DeddyH]

Was heißt "geht nicht"? Was steht denn in Application.Exename bzw. ParamStr(0)?

[generic]

Liegt es nur an den Ordner "Downloads". Dieses ist im Explorer nicht direkt ein Ordner sondern eine Weiterleitung auf einen beliebigen Ordner.

Sag uns doch mal bitte die Fehlercodes oder die Exception.

[himitsu]

Da es hier danach klingt.

KEINE relativen Pfade verwenden, denn das Arbeitsverzeichnis muß nicht dem Programmverzeichnis entsprechen (z.B. wenn das Programm über einen Link oder in einem umgeleiteten Vertzeichnis im Explorer, über aufgerufen mit relativen Pfaden und über Suchpfade gefunden)
und das arbeitsverzeichnis kann sich auch während Laufzeit des Programms leicht mal verändern (daür reicht schon ein TOpenDialog aus).

[Der schöne Günther]

Hoppla, wirklich? :shock:
Das Arbeitsverzeichnis kann sich ändern, ohne dass ich es selbst, z.B. mit

Delphi-Quellcode:

SetCurrentDir(..)

ändere?

[p80286]

Jo, ist schon passiert, darum immer mit vollqualifizierten Namen arbeiten
oder sich erst vergewissern wo man ist und dann gleich schreiben/lesen.

Gruß
K-H

[jaenicke]

Dazu gibt es von mir auch eine genauere Erklärung inkl. Demo:
http://www.entwickler-ecke.de/topic_...uss_82952.html

[musicman56]

Zitat:

Zitat von jaenicke (Beitrag 1231016)

Dazu gibt es von mir auch eine genauere Erklärung inkl. Demo:
http://www.entwickler-ecke.de/topic_...uss_82952.html

:thumb: dem ist nichts hinzuzufügen, ausser dem Hinweis, dass man beim Standard-Open-Dialog die Option "ofNoChangeDir" aktivieren kann, um das Arbeitsverzeichnis unverändert zu lassen.

[dk404]

Zitat:

Zitat von musicman56 (Beitrag 1231030)

Zitat:

Zitat von jaenicke (Beitrag 1231016)

Dazu gibt es von mir auch eine genauere Erklärung inkl. Demo:
http://www.entwickler-ecke.de/topic_...uss_82952.html

:thumb: dem ist nichts hinzuzufügen, ausser dem Hinweis, dass man beim Standard-Open-Dialog die Option "ofNoChangeDir" aktivieren kann, um das Arbeitsverzeichnis unverändert zu lassen.

Doch, dem ist noch was hinzuzufügen!

Was ist denn so schwer an einem

MessageBox(Handle,PChar(Paramstr(0)),'Info',mb_Ok or mb_IconInformation or mb_DefButton1);
oder
MessageBox(0,PChar(Paramstr(0)),'Info',mb_Ok or mb_IconInformation or mb_DefButton1);
im
Procedure TFormSonstwas.FormCreate(Sender: TObject);
um den Pfad der Echse herauszukriegen?

???:oops::twisted:

[DeddyH]

MB_OK or MB_DEFBUTTON1? :mrgreen:

[dk404]

Zitat:

Zitat von DeddyH (Beitrag 1231049)

MB_OK or MB_DEFBUTTON1? :mrgreen:

MessageBox(Handle, PChar(Paramstr(0)), 'Info', mb_AbortRetryIgnore or
mb_IconInformation or mb_DefButton1);

Leck' Dich doch selbst grün :thumb:

[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:

Zitat von Gutelo (Beitrag 1231057)

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:

Zitat von Der schöne Günther (Beitrag 1231071)

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ß.

[Der schöne Günther]

Zitat:

Zitat von himitsu (Beitrag 1231074)

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

Das ist glaube ich jedem klar.

Aber:

Zitat:

Zitat von himitsu (Beitrag 1231074)

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 :pale:

[jaenicke]

Zitat:

Zitat von Gutelo (Beitrag 1231079)

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:

Zitat von Der schöne Günther (Beitrag 1231089)

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

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

Zitat:

Zitat von Der schöne Günther (Beitrag 1231089)

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.

[hathor]

WIN 8:

Delphi-Quellcode:

uses
  ActiveX, ShlObj;

function SpecialDirectory(const iID: Integer): string;
var aPath  : array[0..MAX_PATH] of Char; pilTemp: PItemIDList;
begin
   try
      if SHGetSpecialFolderLocation(0, iID, pilTemp)=S_OK then begin
         if SHGetPathFromIDList(pilTemp, aPath) then begin
            Result := string(aPath);
         end else Result := ''; CoTaskMemFree(pilTemp);
      end else Result := '';
   except Result := '';
   end;
end;

function GetConfigPath: String;
var AppDir: String;
begin
  AppDir := SpecialDirectory(CSIDL_APPDATA)+'\ProgName';
  if DirectoryExists(AppDir) = false then mkdir(AppDir);
    result := AppDir+'\';
end;

//ergibt: C:\Users\HATHOR\AppData\Roaming\ProgName\

Hinweis:
Über den WIN8-Explorer kommt man nur hin, wenn man
C:\Users\HATHOR\AppData\Roaming\ProgName\
direkt in die Adresszeile eingibt.

Alternativ: Im Explorer - Ansicht - Häkchen bei Ausgeblendete Elemente

[Furtbichler]

Und davor (rausgeschnibbelt aus einer größeren Unit)

Delphi-Quellcode:

unit SettingsPaths;

interface
Function LocalUserFilesPath: String;
Function LocalAppDataPath(AppName: String): String;
Function AppDataPath(AppName: String): String;
implementation
Uses sysutils,windows,ShlObj, ActiveX;
Function GetSpecialFolderLocation(csidl: integer): String;
Var
  pMalloc: IMalloc;
  pidl: PItemIDList;
  path: Array[0..MAX_PATH] Of Char;
Begin
  Result := '?';
  If SHGetMalloc(pMalloc) = S_OK Then Begin
    SHGetSpecialFolderLocation(0, csidl, pidl);
    SHGetPathFromIDList(pidl, path);
    Result := IncludeTrailingPathDelimiter(Path);
    pMalloc.Free(pidl);
  End;
End;

Function LocalUserFilesPath: String;
Begin
  Result := IncludeTrailingPathDelimiter(GetSpecialFolderLocation(CSIDL_PERSONAL));
End;

Function LocalAppDataPath(AppName: String): String;
Begin
  Result := IncludeTrailingPathDelimiter(GetSpecialFolderLocation(CSIDL_LOCAL_APPDATA));
  Result := IncludeTrailingPathDelimiter(Result + AppName);
  ForceDirectories(Result)
End;

Function AppDataPath(AppName: String): String;
Begin
  Result := IncludeTrailingPathDelimiter(GetSpecialFolderLocation(CSIDL_APPDATA));
  Result := IncludeTrailingPathDelimiter(Result + AppName);
  ForceDirectories(Result)
End;
end.

So, und wer jetzt seine INI ins Programmverzeichnis schmeißt, wird geteert und gefeedert (mit Doppel-E!). :mrgreen:

[DeddyH]

SHGetSpecialFolderLocation

Zitat:

[SHGetSpecialFolderLocation is not supported and may be altered or unavailable in the future. Instead, use SHGetFolderLocation.]

Das führt dann zu SHGetFolderLocation

Zitat:

Deprecated. Retrieves the path of a folder as an ITEMIDLIST structure.

Alternativ kann man dann auf SHGetFolderPath zurückgreifen, aber

Zitat:

Deprecated. Gets the path of a folder identified by a CSIDL value.

Was einen dann letztendlich zu SHGetKnownFolderPath führt.
Einziger Haken:

Zitat:

Minimum supported client
Windows Vista [desktop apps only]

Daher greife ich persönlich derzeit auf SHGetFolderPath zurück, dazu braucht man nur die Unit SHFolder, und einfacher zu handhaben (und nicht ganz so veraltet wie die erstgenannten) ist sie auch noch.

[Furtbichler]

Oh, nie drauf geachtet.

[Gutelo]

Zitat:

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

@Perlsau: und genau die Werte dieser Anwendungsverzeichnisse aendern sich wenn das Programm in bestimmten Verzeichnissen liegt. Und das ist wohl ein Delphi-Problem.

[himitsu]

Zitat:

Zitat von Gutelo (Beitrag 1231148)

@Perlsau: und genau die Werte dieser Anwendungsverzeichnisse aendern sich wenn das Programm in bestimmten Verzeichnissen liegt. Und das ist wohl ein Delphi-Problem.

Ich würde wetten, daß das auch bei Lazarus, .net, C#, C++, ... passiert.

[hathor]

Ergebnis des untenstehenden Codes:
C:\Users\HATHOR\AppData\Roaming\MyProg

Delphi-Quellcode:

function GetMyPath: string;
var LStr: array[0 .. MAX_PATH] of Char; 
s, AppDir : String;
begin
Result:='';
  Application.Name:='MyProg';
  s:= PathDelim + Application.Name;
  SetLastError(ERROR_SUCCESS);
  if SHGetFolderPath(0, CSIDL_APPDATA, 0, 0, @LStr) = S_OK then
      AppDir:= LStr +s;
    Result := AppDir;
  if not DirectoryExists(AppDir) then mkdir(AppDir);
end;

[DeddyH]

Was ändert sich, und was soll daran ein Delphi-Problem sein? ParamStr(0) bzw. Application.Exename enthalten den vollen Pfad zum Programm, und zwar da, wo es tatsächlich liegt. Dass dieses Verzeichnis ggf. anders heißt als vom Windows-Explorer dargestellt, liegt nicht an Delphi, sondern an der Virtualisierung bestimmter Ordner seitens Microsoft.

[jaenicke]

Zitat:

Zitat von Gutelo (Beitrag 1231148)

@Perlsau: und genau die Werte dieser Anwendungsverzeichnisse aendern sich wenn das Programm in bestimmten Verzeichnissen liegt. Und das ist wohl ein Delphi-Problem.

Du hast bis jetzt noch kein konkretes Beispiel genannt.

Es könnte durchaus Möglichkeiten geben das von dir gewünschte Ergebnis dem Benutzer anzuzeigen. Intern darfst du mit dem was der Windows Explorer (und dann ggf. du) dem Benutzer anzeigt, aber nicht arbeiten, da die Verzeichnisse so gar nicht immer existieren.

[himitsu]

Welche Verzeichnisse betrifft denn das nochmal?

Ach ja:
- Programm in ein Unterverzeichnis legen
und dann in einer Batchdatei oder in der Konsole,
vom übergeordnetem Verzeichnis aus

Delphi-Quellcode:

"Unterverzeichnis\Project19.exe"

aufrufen
- oder in einer Verknüpfung mal bei "Ausführen in" ein anderes Arbeitsverzeichnis angeben
- oder bei ShellExecute und Co. bei lpFile die EXE aufrufen, samt vollständigem Pfad, und bei lpDirectory ein anderes Arbeitsverzeichnis angeben

Die Unterscheidung zwischen Arbeitsvereichnis und Programmverzeichnis gibt es schon seit DOS
So konnte man z.B. ein Programm da ablegen und z.B. dem Packprogramm sagen, daß es "hier" (im Arbeitsverzeichnis) alle Dateien packen soll

Code:

pack.exe -p *.* a.zip

(über Suchpfade die EXE suchen lassen)
oder

Code:

c:\program\myprog\pack.exe -p *.* a.zip

Und das Programm holte sich "seine" Dateien aus seinem Programmverzeichnis (wenn es ordentlich programmiert ist), aber arbeitet mit den Dateien im Arbeitsverzeichnis.

[bcvs]

Zitat:

Zitat von Gutelo (Beitrag 1231148)

Zitat:

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

@Perlsau: und genau die Werte dieser Anwendungsverzeichnisse aendern sich wenn das Programm in bestimmten Verzeichnissen liegt. Und das ist wohl ein Delphi-Problem.

Bevor du uns nicht verrätst, in welche Verzeichnisse Du deine Exe kopiert hast, und insbesondere, was das nach den obigen Befehlen in "Anwendungsverzeichnis" drin steht, glaubt dir das hier niemand.

Analog zu deinem Beitrag #7 habe ich mal ein Testprogramm gemacht. (Nur eine Form mit einem Label drauf). Im OnShow dann

Delphi-Quellcode:

LabelDir.Caption:=ExtractFilePath(Application.ExeName);

Egal, ob ich das nach C:\Users\Userx\Downloads\Irgendwas oder sonst irgendwohin kopiere, es wird erwartungsgemäß immer das Verzeichnis angezeigt, in dem die Exe liegt.

<DummeFrage>
Hast du vielleicht nicht die Exe kopiert, sondern nur eine Verknüpfung angelegt?
</DummeFrage>

[Dalai]

Zitat:

Zitat von Gutelo (Beitrag 1231148)

und genau die Werte dieser Anwendungsverzeichnisse aendern sich wenn das Programm in bestimmten Verzeichnissen liegt.

Ändern sich inwiefern? Wenn man die Echse verschiebt? Ja, sicher, aber inwiefern ist das ein Problem?

Zitat:

Und das ist wohl ein Delphi-Problem.

Das ist es mit 110%-iger Sicherheit nicht. Die Pendants für ParamStr(0) geben auch in anderen Programmiersprachen genau dasselbe zurück: das Verzeichnis, in dem die Echse liegt.

MfG Dalai

[arnof]

Gibt es hier eigentlich einen Ersatz mit TPATH.GET meinen Programmpath :?:

[himitsu]

Zitat:

Zitat von DeddyH (Beitrag 1231131)

Einziger Haken:

Zitat:

Minimum supported client
Windows Vista [desktop apps only]

Inzwischen egal, da XP/Vista/7 nun offiziell endgültig tot sind
und sogar bereits die ersten Windows10-Versionen End-of-Life.

(bei Amazon kann ich noch Win7 kaufen, aber die "günstigen" Windows 10 gibt es schon nicht mehr ... mußte letzten Freitag zu eBay gehn)