Sledge_Hammer - Do 03.10.02 21:09
Titel: Feststellen, in welchem Verzeichnis das Programm liegt

---

Moin
eigentlich sagt der Titel ja schon alles.... Also ich möchte feststellen, in welchem Verzeichnis das Programm liegt, um in dieses Verzeichnis die zum Programm gehörige DLL zu schreiben.
THX Benni

Arakis - Do 03.10.02 21:13

---

Hi Sledge_Hammer ,

dass sollte das sein, was du suchst:ExtractFilePath(Application.ExeName)
Bis dann

DeCodeGuru - Do 03.10.02 21:36

---

Hi Arakis,

ich würde noch folgenden Code "preisgeben":



Warum ist das schreibe? Weil ich im Moment an einem Projekt hänge, in dem es kein Objekt vom Typ TApplication gibt :wink:

Außerdem kann man noch ExtractFileDir verwenden. Der unterschied zwischen beiden:

ExtrcatFilePath gibt das Verzeichnis mit einem Backslash am Ende zurück, was ExtractFileDir nicht macht.

Achja, das Posting soll nicht heißen, dass deine Antwort (Arakis) falsch war. :mrgreen:

Arakis - Do 03.10.02 22:18

---

Hi DeCodeGuru,
wie heißt es doch gleich: Alle Wege führen nach Rom :mrgreen:
Aber ich finde dass mit dem Applicaton.ExeName ein weinig logischer, vor allem finde ich eins an ParamStr unlogisch: ParamCount zählt null, wenn kein Parameter übergeben wurde, aber ParamStr(0) ist immer vorhanden. Ist zwar kein Array, aber es verwirrt. Zudem habe ich mir angewönt, Verzeinisse IMMER mit einem Backslash anzuschließen, damit ich nicht jedes Mal schauen muss, ob denn jetzt zwischen Verzeichniss + Dateiname noch ein \ hin muss oder nicht. Zwar gibt es da noch die Funktion IncludeTrailingBackSlash(const APath: string): string; aber wer merkt die sich schon :wink:

Und wenn wir schon mal dabei sind, alle Möglichkeiten aufzuzählen, GetCurrentDir() würde zur Not auch tun, ist nur ein bisschen unsicher.

Bis dann

DeCodeGuru - Do 03.10.02 22:24

---

Hi Arakis,

ich wollte nicht sagen, dass deine Antwort nicht kompetent war. Aber ich denke, dass die Infos möglichst "vollständig" sein sollten und dass möglichst viele Wege dargestellt werden. Daher habe ich noch die anderen Möglichkeiten gepostet :wink:

Arakis - Do 03.10.02 22:28

---

Ich wollte nur die Vor- und Nachteile nennen, weil du das Posting so auf mich bezogen hast :wink:

Bis dann

DeCodeGuru - Do 03.10.02 22:29

---

Zitat:

Ich wollte nur die Vor- und Nachteile nennen, weil du das Posting so auf mich bezogen hast :wink:

Habe ich, oh ja stimmt. Na ja, hauptsache ist doch, dass wir jetzt alles gesagt haben :mrgreen: Na ja alles sicher noch nicht, aber es reicht.

Arakis - Do 03.10.02 22:44

---

Hmm, man könnte ja noch die Windows API nach dem Pfad fragen, oder man macht es sich noch umständlicher:
Soll man jetzt aber nicht all zu ernst nehmen :wink:

Bis dann

Delete - Do 03.10.02 23:06

---

Arakis hat folgendes geschrieben:

Und wenn wir schon mal dabei sind, alle Möglichkeiten aufzuzählen, GetCurrentDir() würde zur Not auch tun, ist nur ein bisschen unsicher.

Nicht nur unsicher, sondern schlicht und ergreifend falsch. :!:

Arakis - Do 03.10.02 23:10

---

Warum? Bei mir funzt es. Beim starten des Programmes ist das aktuelle Arbeitsverzeichniss das selbe, wo die Application liegt. Unsicher deshalb, weil es sich ja ändern lässt. Es ist also nicht schlicht und ergreifend falsch :wink:

Bis dann

Delete - Do 03.10.02 23:18

---

Zufall. Stell mal bei einem Link zu der Exe ein anderes Arbeitsverzeichnis ein. Dann dürfte das nicht mehr klappen. Genauso verhält es sich, wenn du den aktuellen Pfad mit einen Öffnen- oder Speicherndialog änderst, schon läufst du ins Leere.

Zitat:

GetCurrentDirectory The GetCurrentDirectory function retrieves the current directory for the current process.

GetCurrentDirectory liefert das aktuelle Verzeichnis nicht mehr und nicht weniger.

Der einzig richtige Weg ist GetModuleFile oder alle Routinen, die das kapseln, wie ParamStr(0) oder Application.Exename.

Arakis - Do 03.10.02 23:24

---

Luckie, wie waren dabei alle Möglichkeiten aufzuzählen, die gingen, um an den Pfad der Applikation heranzukommen. Außerdem hab ich ja auch beigeschrieben, dass das unsicher ist :evil:

Selbstverständlich würde man GetCurrentDirectory nie für diesen Zweck verwenden. :wink:

Bis dann

Delete - Do 03.10.02 23:27

---

Arakis hat folgendes geschrieben:

alle Möglichkeiten aufzuzählen, die gingen, um an den Pfad der Applikation heranzukommen.

Eben, und GetCurrentDirectory geht eben nicht.

Arakis - Do 03.10.02 23:33

---

Du kannst nicht einfach sagen, "get nicht" :o
Geht schon, aber nur unter gewissen Umständen :!:

Bis dann

DeCodeGuru - Do 03.10.02 23:49

---

Zitat:

Geht schon, aber nur unter gewissen Umständen

Wo er recht hat, hat er recht :wink:

Delete - Fr 04.10.02 10:39

---

Arakis hat folgendes geschrieben:

Du kannst nicht einfach sagen, "get nicht" :o Geht schon, aber nur unter gewissen Umständen :!:

Sorry, Arakis, aber da du als Entwickler nicht garantieren kannst, dass diese "gewissen Umstände" immer eingehalten werden (manuelle Veränderung des Arbeitsverzeichnisses usw.) geht die Möglichkeit eben nicht.

Zitat:

Aber ich finde dass mit dem Applicaton.ExeName ein weinig logischer,

Solange du ein VCL-Projekt hast, warum nicht ...

Zitat:

vor allem finde ich eins an ParamStr unlogisch: ParamCount zählt null, wenn kein Parameter übergeben wurde, aber ParamStr(0) ist immer vorhanden

Natürlich. Weil "paramstr(0)" das Programm selbst ist, inkl. Pfad. Dass das immer vorhanden ist, ist doch logisch. Und "paramcount" liefert Null zurück, wenn du keinen der üblichen Kommandozeilenparameter angegeben hast. Ich sehe da also nichts Unlogisches.

Arakis - Fr 04.10.02 16:07

---