Warum bei Dateinamen der Pfad mit angegeben werden muss[meta]Verzeichnis[/meta][meta]absolut[/meta][meta]relativ[/meta][meta]Schreibrechte[/meta][meta]Administratorrechte[/meta]
Da es ein sehr häufiger Fehler ist, dass die Angabe eines Verzeichnisses fehlt, wenn auf Dateien zugegriffen wird, schreibe ich dazu einmal eine Erklärung warum es notwendig ist ein Verzeichnis immer anzugeben.
Dazu gibt es eine Demonstration wie einfach dabei ein Fehler auftritt, wenn man das Verzeichnis weglässt. Wer es einfach nur kurz sehen möchte, der lädt bitte einfach mal das Demoprojekt aus dem Anhang herunter und testet es.
Hinweis:
Die beste Lösung ist aber gar nicht, das Verzeichnis zu benutzen, in dem das eigene Programm liegt, denn nicht immer kann man es beschreiben. Unter XP ohne Adminrechte und unter Vista immer kann man unter c:\programme nicht schreiben.
Mehr dazu (fehlende Schreibrechte im Verzeichnis des eigenen Programms) in diesem Beitrag:
www.delphi-library.d...ewtopic.php?p=548600
Aber weiter im Text:
Worum es bei der fehlenden Angabe eines Verzeichnisses geht ist folgendes. Angenommen, man möchte die Konfigurationsdatei im selben Verzeichnis wie das Programm auslesen:
Falsch:
Delphi-Quelltext
1:
| Memo1.Lines.LoadFromFile('config.ini'); |
Richtig:
Delphi-Quelltext
1:
| Memo1.Lines.LoadFromFile(ExtractFilePath(ParamStr(0)) + 'config.ini'); |
Um zu verstehen, warum der erste Quelltext nicht immer das gewünschte macht (das wäre ja im Anwendungsverzeichnis die Datei suchen), muss man verstehen, was dabei passiert. Wenn ihr in die Eigenschaften einer Verknüpfung schaut, dann findet ihr dort u.a. "Ausführen in:". Dort kann man das
Arbeitsverzeichnis angeben, das die Anwendung beim Start haben soll. Auch bei ShellExecute u.ä. kann man dieses angeben.
Dieses wird benutzt, wenn man keinen kompletten Pfad sondern nur einen Dateinamen oder einen relativen Pfad angibt und nicht das Verzeichnis, in dem das Programm sich befindet.
Jetzt fragt ihr bestimmt, warum der erste Quelltext trotzdem oft funktioniert. Ganz einfach: Ist kein anderes Arbeitsverzeichnis angegeben, ist dieses beim Start das in dem die Exe liegt.
Und jetzt kommt bestimmt: Wo ist das Problem?
Nun ja, das Arbeitsverzeichnis ist nicht fest. Schon der Aufruf eines Öffnen-Dialogs ändert dieses...
Dazu habe ich eine kleine Demo-Anwendung geschrieben, die ihr im Anhang findet. Dort wird im Grunde diese Befehlssequenz ausgeführt: (der Inhalt des Memos wird in test.txt gespeichert, das Memo geleert, die Datei wieder geladen, dann ein Öffnen-Dialog angezeigt, wo man eine Datei in einem anderen Verzeichnis auswählen muss, und dann wieder versucht mit dem selben Quelltext die Datei test.txt wieder zu laden)
Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
| memTestDisplay.Lines.SaveToFile('test.txt');
memTestDisplay.Lines.Clear;
memTestDisplay.Lines.LoadFromFile('test.txt');
if dlgOpenFile.Execute then
memTestDisplay.Lines.LoadFromFile(dlgOpenFile.FileName);
memTestDisplay.Lines.Clear;
memTestDisplay.Lines.LoadFromFile('test.txt'); |
Das erste LoadFromFile wird funktionieren, denn das Arbeitsverzeichnis hat sich nicht geändert. Nach dem Ausführen des Dialogs
ist das Arbeitsverzeichnis aber ein anderes (vorausgesetzt man wählt nicht gerade das Verzeichnis des Demoprojekts selbst aus, was im echten Quelltext aber auch geprüft wird^^).
Das zweite LoadFromFile wird nicht mehr funktionieren, obwohl der Quelltext der selbe ist, denn es wird jetzt in dem Verzeichnis gesucht, den man mit dem Öffnen-Dialog ausgewählt hat...
Fazit: Immer, wirklich immer, absolute Pfadangaben verwenden.
Im zweiten Teil zeige ich jetzt noch die saubere Lösung für Programmeinstellungen, die auch unter Vista und unter XP ohne Administratorrechte funktioniert.
![Antworten [gesperrt]](./graphics/navbar/reply.png)
