![]() |
Re: WorkingDirectory festlegen
Zitat:
Anscheinend sind die Fachleute in diesem Thread seltsamerweise anderer Meinung :mrgreen: Wird man durch die Schweinegrippe denn wirklich sofort ... |
Re: WorkingDirectory festlegen
Vielleicht ist Deine Definition von relativen und absoluten Pfadangaben zu unserer einfach nur inkompatibel ;)
|
Re: WorkingDirectory festlegen
Zitat:
Der Rest von uns programmiert für 100-99,99 :mrgreen: LG und gute Nacht für's heutige Mitlesen :love: |
Re: WorkingDirectory festlegen
Zitat:
Delphi-Quellcode:
Und wenn du einen String brauchst, dann einfach nur mit +, dann brauchst du das PChar() nicht.
PChar(DeinString + DeinPChar)
|
Re: WorkingDirectory festlegen
Ich verwende ausschließlich relative Pfadangaben in Stringkonstanten, und zwar relativ zu einem benutzerdefinierten Stammverzeichnis. Absolute Pfadangaben in einer Anwendung sind irgendwie unflexibel. Allerdings ist jede Pfadangabe letztendlich ja eine Absolute, auch wenn sie implizit auf einem per SetCurrentDir gesetzten Standardverzeichnis aufbaut.
Auf jeden Fall steht dieses Stammverzeichnis in der Registry oder in einer INI-Datei im Benutzerpfad für Applikationsdaten. Wenn das Zielsystem es erfordert, schmeisse ich die INI-Datei in das Verzeichnis der EXE oder definiere einfach, das das Stammverzeichnis identisch mit dem Verzeichnis der EXE ist. Dann hat der Anwender eben keine Wahl. Ja ja, letzteres soll man ja angeblich nie machen, aber bei embedded Maschinenanwendungen fällt man auf die Schnautze, wenn der Techniker eine neue Flashcard einbaut und nur das Programmvezeichnis gesichtert hat, nicht jedoch die Applikationsdaten bzw. die Registry. Das Stammverzeichnis und alle anderen Verzeichnisse widerum sind öffentliche Eigenschaften eines Applikationsdatenmoduls. Jede meiner Anwendungen hat mindestens so ein Ding. Dort sind alle Einstellungen und daraus ableitbare Daten enthalten, die das Verhalten und Aussehen meiner Anwendung steuern. Dazu gehören neben den Verzeichnissen auch Optionen, Farben usw. usw. Ich würde niemals auf die Idee kommen, mit SetCurrentDir zu arbeiten, dafür ist mir mein AppDataModule einfach zu übersichtlich. Ich weiss immer genau, wo meine Daten stehen. Ein Applikationsdatenmodul könnte so aussehen:
Delphi-Quellcode:
Type
TAppData = Class private fStammverzeichnis : String; Public Procedure Load; Constructor Create; Function Stammverzeichnis : String; Function Datenverzeichnis : String; End; Implementation Const DATENUNTERVERZEICHNIS = 'Daten'; Procedure TAppData.Load; Begin fStammverzeichnis := ExtractFilePath(ParamStr(0)); // Und falls das Stammverzeichnis in einer INI-Datei oder der Registry liegt, lese ich es eben von da aus. // Und falls das Stammverzeichnis doch knallhart auf 'D:\Programmdaten' gesetzt werden soll (Himmel hilf!), setze ich das eben hier End; Constructor TAppData.Create; Begin Load; End; Function TAppData.Stammverzeichnis : String;; Begin Result := IncludeTrailingPathDelimiter (fStammverzeichnis); End; Function TAppData.Datenverzeichnis : String; Begin Result := IncludeTrailingPathDelimiter (Stammverzeichnis+DATENUNTERVERZEICHNIS); End; ... |
Re: WorkingDirectory festlegen
Und wenn es fast ganz ohne eigenen Aufwand sein soll:
![]() Die Klasse verwaltet Einstellungen oder andere Daten automatisch, man kann entweder fest festlegen, dass es z.B. das Anwendungsdatenverzeichnis sein soll oder dem Benutzer die Wahl lassen, usw. Zitat:
Das meinte ich als Abgrenzung gegen den von dir auch genannten impliziten Bezug auf das aktuelle Arbeitsverzeichnis, das ja schon ein simpler Dateidialog ändert, nicht als festen Pfad wie "c:\...". |
Re: WorkingDirectory festlegen
Danke, jetzt gehts......... :D
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 01:46 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz